Subject: Re: wildcards vs. RR types, was Faux wildcards

From: John Levine <[email-masked]>
Date: 19 Jan 2005 02:37:54 -0000

>>Seems to me that particular horse left the barn five years ago when
>>RFC 2782 was published. ...

>The SRV record didn't need an alteration of section 4.3.2 of RFC 
>1034.

I may have been unclear since my message was about two fairly separate
topics.

One is using SRV records with different interpretations of the fields.
That doesn't need any changes to anything.  Nothing else uses a prefix
of _client._smtp, so CSV SRV records won't collide with anything else.

Our SRV records don't work with wildcards, but no SRV records have
ever worked with wildcards.  So nothing's changed, if you did a
wildcard SRV before you'd be sorry, and you still will be.

>> It seems to me that name prefixes work great.  You can add ...
>> The only problem is that they don't play well with traditional DNS
>> wildcards.

>I can't imagine adding a solution that works 90% of the time to a 
>critical system.

Well, yeah, that's the problem, isn't it?

My inclination at this point it to tell CSV clients to do the tree
walk, since that works with any old DNS server, and to encourage the
servers to consider more sophisticated record synthesis so they can
respond directly to an initial CSV query even if it's for something
without an explicit record in the server.  If the client gets a
response to the initial exact match query, it won't do the tree walk,
so this works with current software, and allows servers to do an
upgrade transparently if they want.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 Jan 2005 11:52:03 -0800

> [mailto:[email-masked]] On Behalf Of Ben Laurie

> John Levine wrote:
> >>>There's no need for "new" wildcards.
> >>
> >>I'm not (yet) sure whether "new" wildcards is a protocol 
> change, or an 
> >>"ease of use config option" on servers (i.e. an application change)
> > 
> > 
> > It's only a protocol change if you use AXFR or IXFR to synchronize 
> > servers.  It doesn't affect normal DNS client-server 
> interactions at 
> > all.
> 
> Or if you use DNSSEC.

Or if you use DNSSEC and the NXT-n record does not take account of this 

There are two possible paths here, the first is to write an NXT-n record
that meets this requirement. If there is going to be a killer app for DNSSEC
then signing email security policy records is most likely to be it.

The second is to simply expand out the macros and design in a means of
dealling with security policies that are assigned to a non existent node
separately. One way that this could be done would be to identify a
distinguished node _default that can be used for the default prefix.

My personal technical preference would be to have an appropriate NXT-n
record and avoid the need to do the macro expansion.