Subject: Re: DNAME questions

From: David Blacka <[email-masked]>
Date: Sun, 18 Jun 2006 10:53:06 -0400

On Jun 18, 2006, at 3:20 AM, Mark Andrews wrote:

>
>> I have a few questions about DNAME that I've been storing up.  Since
>> some folks are currently working on a 2672bis document, I thought
>> that now might be a reasonable time to ask the list.
>>
>>
>> 1. Why does DNAME not match at the DNAME itself?
>>
>> I can certainly think of reasons why, but I was wondering what the
>> original reason was.
>
> 	Yes.  That allows you to deploy DNAME at the zone apex.  The
> 	synthesised CNAME records don't break "no other data at a
> 	CNAME" rule.  They play nice with 1034 caches.

This is, of course, the reason that I thought of.

But, why was there a desire to deploy the DNAME at the zone apex and  
not at the parent?

>> 2. Does anyone know of any non-trivial production use of DNAME?
>>
>> I am curious about this for two reasons: a) if not, then the working
>> group might be free to modify how DNAME works (or deprecate it), b)
>> if not, then why not?  Perhaps the working group should change DNAME
>> to make it more useful?
>
> 	DNAME has been used to renamed ip6.int to ip6.arpa.  It has
> 	also been used to rename zones.  The A6/DNAME examples to
> 	aid renumbering are equally applicable to AAAA/DNAME especially
> 	if you do delegations on the nibble boundary.
>
>> 3. Would there be harm in allowing a DNAME and CNAME to both exist at
>> the same name?
>>
>> This is related to questions #1 and #4, actually.  But since DNAMEs
>> do not match at the DNAME, does that mean that having a CNAME at the
>> same name is not harmful?
>
> 	Yes.  You couldn't query for a DNAME through a 1034 cache.

Why would you query for a DNAME?

>> 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs?
>>
>> I believe that some implementations do this, but we did spend a lot
>> of time in DNSSEC trying to specify that caches should not synthesize
>> negative responses, nor use cached wildcard records to synthesize.
>> Should DNAME be any different?
>
> 	That was the design intent.  That is why there cannot be
> 	any children of a DNAME.  DNSSECbis aware servers MUST know
> 	about DNAME processing so that can validate synthesised
> 	answers.
>
> 	You can't, in general, synthesis from a cached wild names
> 	as you don't how what other names there are in the zone
> 	that would normally block synthesis.  The same is not true
> 	for DNAME as we know there are no children of the name with
> 	the DNAME record.

Some folks have expressed that idea that "caches don't do synthesis",  
which is possibly what they got out of the discussion around caches  
using NSEC records to synthesize negative responses.  I'm just trying  
to reconcile this concept with reality.

It is clear that having caches synthesize from a cached DNAME is  
*safe*, because it was defined to be safe.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
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: Paul Vixie <[email-masked]>
Date: Sun, 18 Jun 2006 18:24:53 +0000

> > 	synthesised CNAME records don't break "no other data at a CNAME" rule.
> > 	They play nice with 1034 caches.
> 
> But, why was there a desire to deploy the DNAME at the zone apex and not at
> the parent?

probably it was developed by folks who were usually representing a child
zone rather than a parent zone.  being able to deploy at a zone apex gives
greater autonomy to child zone administrators, while taking none away from
parent zone administrators.

> Why would you query for a DNAME?

IIRC, the argument was not of the form "because we foresee a need to query
for this type..." but rather "because we don't want to unnecessarily prohibit
someone from querying for this type..."

---

off topic response:

> Some folks have expressed that idea that "caches don't do synthesis", which
> is possibly what they got out of the discussion around caches using NSEC
> records to synthesize negative responses.  I'm just trying to reconcile this
> concept with reality.
> 
> It is clear that having caches synthesize from a cached DNAME is *safe*,
> because it was defined to be safe.

if we had it to do over again, everything synthesizable anywhere would be
synthesizable everywhere, which ultimately means: wildcards wouldn't be 
synthetic at all, a covering-wildcard would be considered-responsive, and
would be synthesized in the querying agent (or in gethostbyname etc).  the
fact that DNAME is designed to be safe in this way is wonderful... but it's
25 years too late to save wildcards, and 10 years too late to save NXDOMAIN.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 19 Jun 2006 09:06:47 +1000

> But, why was there a desire to deploy the DNAME at the zone apex and  

	Because all the nameservers for a zone with a DNAME have
	to support synthesizing the CNAMES.

	Say you wanted have "FOO.COM. DNAME BAR.COM."  You would
	have to wait for all the COM servers to be upated and for
	the registry to accept DNAMES.

	Once the COM servers are updated and the registry process
	is updated to support adding DNAME (and everything else
	that normally appears there sans NS and SOA) then the
	delegation could be replaced.

> Why would you query for a DNAME?

	Does it matter why?  The problem is that you can't do it.
 
> to reconcile this concept with reality.

	Which was never a technical arguement.  It was just people
	being cautious.  DNAME synthesis is simple.  A lot simpler
	than generating a negative response from a cached negative
	response for a different QNAME.
 
> *safe*, because it was defined to be safe.

	And it was alway the intent that such synthesis occur.

	           Synthesis in the cache.

	wildcard synthesis   negative answer   	 DNAME
	    impossible          possible        possible
	         -                hard            easy
	 
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]