Subject: RE: Non-terminal-wildcards Re: SRV records considered dubious

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 29 Nov 2006 08:11:03 -0800

> From: Olaf M. Kolkman [mailto:[email-masked]] 

One point to make at the start here, this discussion does not have any
relevance to the last call on DKIM BASE. It does have an important
bearing on DKIM policy but that has not yet been designed.

The architectural issue here is whether DKIM is a 'one off' or an
architectural template for others to follow. I am proposing an
architecture where SRV records and policy records essentially replace
port numbers. So I am anticipating a few hundred entry points being
defined each year.

> I did try to say that the design of the DNS extension 
> mechanism should be specified so that it can stand on it own. 
> Application neutral, so to speak.

I am trying to get the document released. Unfortunately I have to make
sure that if there are any novel ideas there that the IP gets locked
down first. I am pretty sure that there is prior art in the Grid Forum
and earlier work. But it takes considerably greater inginuity to work
out the anteceedents than to solve the problem in the first place.

The reason for this is not because we are under any idiotic notion that
it would be possible for VeriSign to profit from a patent but because
others might imagine that they could. And yes there are folk who read
IETF mailing lists and then file patents on other people's ideas, I call
them perjurers, the USPTO calls them inventors.

The DNS was originally conceived as a means of providing an indirection
layer so that people could address a HOST by name rather than address.
MX changed that model. The name now identifies a SERVICE rather than a
HOST.

All I am proposing to do is to take this concept to its logical
conclusion in a way that does not violate the core constraints on DNS
(update times, bandwidth, transactions).

On the topic of 'wildcards'

There are two acknowledged issues here. The first is that a DNS wildcard
does not do what you would want for default policy, the second is that
wildcards cannot be defined on wildcard records.

The first problem is that the requirement has been given the same name
as the technical solution that does not match.

So don't talk about the need for 'wildcard' policy records, the
requirement is for default policy records, that is a policy record that
applies to any node in the zone whether or not it exists. Defining such
a record will require multiple entries in the zone file but these can be
easily added by a preprocessor as everyone agrees. The only reason to
document it is that otherwise we keep returning to the discussion.
Perhaps a short informational would clear up the issue.

The second issue has been discussed.

The third issue is that when you have a large number of policies to
manage you will want to be able to manage hosts by class and not
individually. That is you will want to be able to set out a list of
policies that relate to a desktop machine and then drop a policy record
that says 'this is a desktop'.

> > My suspicion is that discussion will be greatly aided by 
> creating new 
> > names for each proposed new functions, and the new names 
> need to have 
> > essentially nothing to do with the semantics of existing 
> names.  Names 
> > like "super-*" don't really have any differential semantics.
> 
> Good point. I tried to carefully draft the functionality, but 
> today I lost the ability to write comprehensively in a 
> non-native language .... Ed, this is your queue ;-)

I agree here as well, when wildcards were first described they were
almost an afterthought. Then folk realized that they wanted to be able
to zone transfer them and so they crept into the spec but in a
half-baked way. Then when DNSSEC came along we discovered that the
loosey-goosey description was a real liability.

So regardless of CHOICES we should describe a 'super-wildcard', or as I
would call it a default record.

We need to agree a common symbol. I see only two real possibilities. The
question mark ?, unfortunately that has a widespread use as a single
character match. The double asterisk ** looks like it is the one to use.

--
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/>