Subject: Who hates the DNAME?

From: Edward Lewis <[email-masked]>
Date: Fri, 15 Apr 2005 11:52:48 -0400

After trying over and over to "clarify" DNAMEs and wild cards, I have 
come to have a complete dislike for the DNAME.  Not just the document 
but also the idea.

For one, DNAME violates principles that have been voiced in 
opposition to things like NSEC3 and proposals to put application data 
in the DNS.  In short, denying current proposals via criteria that 
the DNAME "breaks" is rather hypocritical.  Worse, I take this to 
mean that perhaps the DNAME is a suspect extension.

It is said that DNAME works.  But it only works within certain 
bounds, i.e., not with wild cards.  If that's the case, then other 
extensions ought to be allowed if they are used within their bounds.

Specifically, I am troubled by the changes to the search algorithm in 
the DNAME RFC (RFC 2672).  Not only is part 'c' of step 3 
incompletely updated (it says nothing of what happens when the QTYPE 
is any or DNAME), but it also modifies the search in the cache. 
Specifically, the cache now takes on a role that is otherwise 
reserved for the authoritative data - a "search" having knowledge of 
the tree structure.

(NSEC3 proposes changing the search algorithm, this has been cited as bad:
   http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00685.html)

How many implementations have the DNAME processing in them - in the 
recursive server, doing step 4?  I suppose BIND does, but do any 
others?  (Has interoperability been achieved?)

How widespread is the use of DNAME?  There's an ISC report on how to 
do it, but is it common enough?

If there is interoperability and widespread use, then the RFC ought 
to be amended for completeness.  If not, I'd like to put forward the 
idea of obsoleting the record.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

--
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: Mark Andrews <[email-masked]>
Date: Thu, 28 Apr 2005 10:40:17 +1000

> On Wed, Apr 27, 2005 at 05:12:22PM -0400, Rob Austein wrote:
> > At Wed, 27 Apr 2005 20:33:05 +0000, Bill Manning wrote:
> > > 
> > > > > Mark Andrews wrote:
> > > > 
> > > > >	As for which servers support DNAME.  Every server that supports
> > > > >	DNSSECbis is required to support DNAME.
> > > > 
> > > > David Blacka wrote:
> > > > What do you mean by server?  What do you mean by "support DNAME"?
> > > 
> > > 	and for that matter, Mark, you talk aobut a cache that
> > > 	performs tricks :)   i'd be really interested in the distinction
> > > 	betwn a cache (which i think of a data structures in storage)
> > > 	and a server (authoritative is the only kind i know)
> > > 
> > > 	what some folks call a caching server is really an iterative mode
> > > 	resolver  that has access to a cache... right?
> > 
> > It's a recursive name server, which includes an iterative reolver,
> > which includes a cache.
> > 
> > As far as DNSSECbis requiring support for DNAME, search for "DNAME" in
> > RFC4035, but the one that's relevant here has to do with validation of
> > synthesized CNAMEs:
> > 
> > 4.8.  Synthesized CNAMEs
> > 
> >    A validating security-aware resolver MUST treat the signature of a
> >    valid signed DNAME RR as also covering unsigned CNAME RRs that could
> >    have been synthesized from the DNAME RR, as described in [RFC2672],
> >    at least to the extent of not rejecting a response message solely
> >    because it contains such CNAME RRs.  The resolver MAY retain such
> >    CNAME RRs in its cache or in the answers it hands back, but is not
> >    required to do so.
> > 
> > That is: the DNSSECbis validation algorithm requires the validator to
> > understand DNAME, because DNAME is another kind of synthesis rule.
> > Just as with wildcards, the only real options we had here were:
> > 
> > a) signing synthesized RRsets on the fly, or
> > 
> > b) signing the synthesis rule, which requires the validator to
> >    understand the synthesis rule.
> > 
> > RFC2672 said to do both (a) and (b) at once.  For DNSSECbis, the WG
> > decided to punt (a) and just do (b).
> > 
> 
> 	that still leaves me withthe question of -where- synthesis
> 	is supposed to occur.  ... the resolver?   the validator?
> 	some shared datastructures where intermediate data si stored
> 	ffor future use by either the resolver or the validator?
> 	it could be that synthesis can occur in several distinct areas
> 	but the expectation is that the results of the synthesis operation
> 	is expected to be stored in a cache... and one of the problems Ed and M
> ark
> 	were trying to tease out is that what is eventually stored in
> 	a cache may not be consistant with what an auth server might
> 	have synthesized - or for that matter what might be found in some other
>  cache.
> 	regardless of who ir what did the synthesis to put it there.  
> 
> 	(oh for better connectivity... :)
> 
> --bill

	Well for BIND 9 we don't cache the CNAME.  We cache the DNAME and
	generate the CNAME when replying.  Note that CNAME generation
	is for non-DNAME aware clients.  DNAME aware clients are supposed
	to self generate the CNAME / re-write the QNAME when processing
	the answer.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Thu, 28 Apr 2005 09:18:29 +0200 (CEST)

> 	to self generate the CNAME / re-write the QNAME when processing

non-dname aware clients are currently ALL clients by definition. RFC2672
states DNAME aware clients may indicate DNAME support by signalling EDNS
version>0. There is no version>0 defined.

rfc4035 does not change that fact. Sure, the validator needs to understand
how to validate DNAME in order to trust the syntesized CNAMEs, but that is
basically it.

This self generating/synthesizing crap on a resolver is imho an undesired
precedent.

I dislike DNAME as well.

Roy

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Apr 2005 23:44:01 +1000

> non-dname aware clients are currently ALL clients by definition.

	No.  There is no signaling of whether the client is DNAME
	aware to the server.  That is very different to saying that
	there are no DNAME aware clients.

> RFC2672

	That arguement should have been made six years ago.
 
> I dislike DNAME as well.

	I like DNAME.  I don't think that wildcard DNAMEs are sensible
	or meaningful.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Apr 2005 15:24:27 +0000

> The first question to ask: is something like DNAME a useful feature in DNS?

yes, absolutely.

> If the answer to this question is NO then obsoleting DNAME is the right
> thing to do, if the answer is YES then the other options remain on the
> table.

clarify the specification, is my advice.