Subject: Re: DNAME questions

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Jun 2006 16:19:39 +0000

"creeeeeeeeeeeeeeeaaaaaaaaaak."  (opening the crypt.)

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

since dname was cast in the shadow of cname, and a cname to itself is not
useful, there was no expectation that a dname to itself would be useful.

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

well, there's <http://www.isc.org/pubs/tn/index.pl?tn=isc-tn-2002-1.txt>
which proved to my satisfaction that DNAME-as-deployed works pretty well.
since it is deployed, i recommend that it be treated as "finished", and if
the working group wants incompatible DNAME-like functionality, they start
from scratch with a new type code (DNAME2 or whatever).  if something new
comes about and is more useful, then we can talk later on about deprecating
DNAME.

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

yow.  i would never have thought of that, but you're right, other than the
implications for #4 (below).  a node in the DNS graph is either an alias,
or not.  if it's an alias, then it can't contain any data of its own other
than Secure DNS metadata (to validate the aliasness and alias target.)  i
think the corner cases for CNAME+DNAME at the same node would be ~numerous.

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

it was always intended that anyone possessing a cached DNAME could use it
to act-as-if a CNAME existed.  i think caches should be able to synthesize.

--
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: Matt Larson <[email-masked]>
Date: Fri, 16 Jun 2006 17:30:53 -0400

> useful, there was no expectation that a dname to itself would be useful.

I believe you have perhaps misunderstood Dave's question.  He's not
asking about a DNAME from one name pointing to the same name; rather,
he's asking why DNAME synthesis/matching/whatever-we-call-it occurs
below the DNAME owner name and not at it.  For example, given:

foo.  DNAME  bar.

...then obviously queries for "<whatever>.foo" are rewritten to
"<whatever>.bar" for an arbitrary number of labels in <whatever>.  But
queries for "foo" are not rewritten to "bar".  Dave's question is: why
was DNAME designed this way?

One reason I've thought of is that this allows a DNAME at a zone apex.
Is that a reason (or the reason) or is it something else?

> comes about and is more useful, then we can talk later on about deprecating

I would be interested to know if anyone is using the technique
described in that document.  Has anyone ever deployed or encountered a
DNAME in a production environment?  I haven't.

I'm not trying to use this as an excuse to change or not change DNAME
semantics.  I'm mostly asking out of curiosity.

> think the corner cases for CNAME+DNAME at the same node would be ~numerous.

The reason for this question goes back to #1.  If one truly wanted to
alias everything from one node to another, including the node itslef,
then one would theoretically need not only the DNAME but also a CNAME
at the same node.

The rule used to be "no other data at a CNAME".  Now it's "no other
data except security metadata at a CNAME".  We could conceivably
change it again.  Since CNAME matches at the node only and DNAME
matches below the node only, I don't immediately see a bunch of corner
cases.

> to act-as-if a CNAME existed.  i think caches should be able to synthesize.

I agree, but I can't find any language in 2672 that explicitly allows
synthesis from DNAME.  That's at least one of the issues the rewrite
needs to address.

Matt

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Jun 2006 21:39:17 +0000

> ...

ah.  yes.  it's to avoid a "DNAME and other data" problem that would
otherwise occur.

> ...

2001:4f8::/32 used it.

> ...
> The rule used to be "no other data at a CNAME".  Now it's "no other data
> except security metadata at a CNAME".  We could conceivably change it again.
> Since CNAME matches at the node only and DNAME matches below the node only,
> I don't immediately see a bunch of corner cases.

at a minimum, since CNAME and NS can't coexist, you would not be able to use
DNAME at a zone apex if you also wanted a CNAME.  at a maximum, if we want to
change it yet again, it'll cost an EDNS version number to prevent caching
resolvers who would not understand "CNAME and other data" and who might be
implemented internally in a way that the aliased node isn't fully
instantiated and doesn't even have a place to hang the other data.  (more or
less the same way and for the same reason we try to keep such caches from
seeing Secure DNS metadata.)

in other words, lots of corner cases.  but i agree that it's ~achievable.

> synthesis from DNAME.  That's at least one of the issues the rewrite

suits me.  note that i was worried about a cache doing this synthesis if the
real zone had data below the DNAME and would know NOT to synthesize in that
case, but marka talked me out of worrying about this, i just don't recall how.

---

From: David Blacka <[email-masked]>
Date: Fri, 16 Jun 2006 17:56:31 -0400

> useful, there was no expectation that a dname to itself would be  

I was asking why a DNAME doesn't (essentially) act as a CNAME at the  
ownername.  And, in particular, what was the thinking at the time, as  
opposed to the reasoning now.

> comes about and is more useful, then we can talk later on about  

This doesn't answer my question at all.

I'm not necessarily advocating changes to DNAME.  I mostly want to  
know if DNAME has been found to be generally useful in actual  
practice, and if not, why not.

> think the corner cases for CNAME+DNAME at the same node would be  

I thought that the corner case for CNAME+anything really boiled down  
to a single corner case, so I'm not sure I share this view.

AFAICT, for there to be an issue, your cache would have to be using a  
cached DNAME as a source of synthesis AND have seen a query for the  
DNAME itself first AND the target of the CNAME would have to have a  
DNAME.

> to act-as-if a CNAME existed.  i think caches should be able to  

But why this and not that?

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

---

From: [email-masked]
Date: Sat, 17 Jun 2006 10:24:14 +0000

> > DNAME in a production environment?  I haven't.

	2002.ip6.int used it to map to 2002.ip6.arpa.  (we could not get ICANN 
		to do it for the ip6.int/ip6.arpa)
	
	2001:478::/32 used it.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Sun, 18 Jun 2006 17:20:22 +1000

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

	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.

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

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 26 Jun 2006 10:59:16 -0400

I've been SMTP issues, so I'm  bit slow to respond.

>1. Why does DNAME not match at the DNAME itself?

I think this is captured in http://tools.ietf.org/html/2672#section-5.1

It lets the owner name retain as much functionality of a zone apex as 
needed.  I.e., it can retain an A (for a web server maybe), an MX, 
etc.  This wouldn't be possible for CNAME-like behavior.

Anyway, that's my guess at what the intention was.

>2. Does anyone know of any non-trivial production use of DNAME?

I think this was already answered by someone else.

>3. Would there be harm in allowing a DNAME and CNAME to both exist at the

I think so - if only because CNAME is a domain hog.  CNAME takes over 
completely and shunts the search elsewhere.  DNAME is trying to 
rewrite the query while retaining what's needed for transitioning a 
domain.  Not much of a difference, really, but enough probably to 
drive the RFC the way it is.

I suppose that DNAME is meant for "sinking" a name from higher in the 
tree (or closer to the root) down under another name as would be done 
in a corporate merger/purchase.  CNAMEs pretty much go up, down, 
sideways, etc.

>4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs?

Ug.  I don't like authorities "chasing" CNAMEs as it is, but that's 
what the good book says they do.  I suppose that it could work, I'm 
not passing judgement on that.

PS - I should say that I have no insight into what Matt Crawford was 
thinking at the time.  I'm just trying to read an intent from the RFC.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...