Subject: RE: a suggestion for super-wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 08:11:26 -0700

> [mailto:[email-masked]] On Behalf Of Roy Arends

> Stephane Bortzmeyer wrote on 07/26/2006 09:44:21 AM:
> 
> > On Tue, Jul 25, 2006 at 02:25:45PM -0400,  Edward Lewis 
> > <[email-masked]> wrote  a message of 33 lines which said:
> > 
> > > >This is then processed by a preprocessor to produce the 
> actual DNS
> zone:
> > > >
> > > >**.example.com      PTR  _default.example.com
> > > >a.example.com       A    10.0.0.1
> > > >a.example.com       PTR  _default.example.com
> > > >_dkim.example.com   TXT  "dkim record"
> > > 
> > > E.g., BIND's $GENERATE directive, on steroids.
> > 
> > I'm always puzzled by proposal to add in the DNS things that could 
> > otherwise be implemented by any preprocessor. The only 
> advantage is to 
> > make the transferred zone smaller (but it forces all the 
> secondaries 
> > to upgrade to a version supporting the new syntax).
> > 
> > Unless I missed another advantage, I suggest to dismiss all these 
> > proposals with a "Learn cpp or m4 or Perl or anything". 
> (And I'm not 
> > sure it was a good idea to specify the file format, anyway. IETF 
> > should be about protocols, not about file formats.)

Which is of course exactly how I would expect legacy resolvers to handle the scheme. This part of the scheme is the same as

If it was not for zone transfers and for DNSSEC there would be no reason to have wildcards mentioned in the protocol spec at all. That is why the ambiguity could enter the system and create the need for clarification decades later.

In the context of DKIM there is a need to demonstrate that the wildcard problem can be solved by a script. Note that this wildcard problem, the fact that wildcards don't have the exact semantics you would want is an issue regardless of how the records are encoded (TXT, new record, prefixed, not).

The alternatives on offer here are 
	1) The existing heuristic search 
	2) The macro-wildcard mechanism proposed here plus a new RR
	3) The macro-wildcard mechanism plus the pointer scheme 'super-wildcards' 
		with either a new RR or a prefix label

I think that most of us here would agree that (1) is not a satisfactory solution.

> Okay, it can be preprocessed, but that is going to be a 
> helluva big zone

The expansion factor for super-wildcards is similar to the expansion factor for DNSSEC, i.e the number of new records is proportional to the number of nodes plus the number of protocol policy declarations.

The expansion factor for macro-wildcards plus a new RR is the proportional to the number of nodes MULTIPLIED BY the number of protocol policy declarations.

If we believe that DKIM is the only protocol policy record we will need then both schemes result in the same expansion of the zone.

My belief is that we are about to see a dramatic expansion in the number of Internet protocols as a result of Web services. The key here is that the variation in services for human consumption is rather small because people need consistency in their user interfaces. I don't expect there to be many new human interface protocols, the exceptions to this rule are mostly games. Machine/Machine interfaces are not constrained in that way, I expect we will have hundreds of Web Services in regular use and SOAP is sufficiently complex that a policy layer is essential for configuration.

We could develop something like UDDI or XRI. I don't like the idea of yet another registry. We could use LDAP but today LDAP stops at the firewall and that is going to be the case tommorow as well and I don't expect that to change. LDAP is too powerful and too complex for border directories to be something people get comfortable with.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Roy Arends <[email-masked]>
Date: Wed, 26 Jul 2006 17:23:36 +0200

"Hallam-Baker, Phillip" <[email-masked]> wrote on 07/26/2006 05:11:26 
PM:

> The expansion factor for super-wildcards is similar to the expansion
> factor for DNSSEC, i.e the number of new records is proportional to 
> the number of nodes plus the number of protocol policy declarations.

Note that I was referring to preprocessing non-existant names. 
Wilder-cards (to coin yet another term) is about a directive which 
instructs a process to generate certain types at _existing_ names 
(including non-terminals).

Roy