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: David Blacka <[email-masked]>
Date: Fri, 16 Jun 2006 11:27:50 -0400

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.

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?

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?

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?

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

---

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?

---

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 can certainly think of reasons why, but I was wondering what the  

	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.

> if not, then why not?  Perhaps the working group should change DNAME  

	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.
 
> same name is not harmful?

	Yes.  You couldn't query for a DNAME through a 1034 cache.
 
> 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: David Blacka <[email-masked]>
Date: Sun, 18 Jun 2006 10:53:06 -0400

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

> 	Yes.  You couldn't query for a DNAME through a 1034 cache.

Why would you query for a DNAME?

> 	for DNAME as we know there are no children of the name with

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.

---

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

---

From: David Blacka <[email-masked]>
Date: Sun, 18 Jun 2006 20:30:58 -0400

> 	to support synthesizing the CNAMES.

I.e., it is far easier to upgrade all of your nameservers than to get  
your parent to do so.  Makes sense.

> 	Does it matter why?  The problem is that you can't do it.

Well, it only matters why if you are trying to figure out if having a  
CNAME at a DNAME is a practical or only theoretical problem.

> 	    impossible          possible        possible

Excellent responses, all.  I still don't know if there is any ongoing  
use of DNAME (all of the examples given no longer use it or no longer  
exist.)

A few things about DNAME struck me as strange or sub-optimal.  The  
main one is that you cannot use DNAME to completely move a zone,  
since you cannot move the zone apex.  Hence my wondering if this  
could be solved by having a CNAME at the DNAME (and putting the DNAME  
at the parent), or if it would make sense to define a DNAME2 that  
matched at the DNAME.

The other thing is that I've found that very few people seem to  
understand DNAME, and it also seems very sparsely used.  So I wonder  
if this is because a) not enough software supports it, b) DNAME  
doesn't work quite the way people need it to to be useful, c) it  
suffers from a general lack of awareness (i.e., it would be used more  
if more widely known and understood), or d) it doesn't solve a  
problem that people actually have.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 19 Jun 2006 11:24:22 +1000

> problem that people actually have.

	Just about every cases where you double load the same
	masterfile could be handled using DNAME.

	I think is it not used because of lack of awareness and
	because people mis-read RFC 3363.  The later is very true
	within the IETF.
 
	Mark

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Jun 2006 02:10:32 +0000

> ...  I still don't know if there is any ongoing use of DNAME
> (all of the examples given no longer use it or no longer exist.)

i don't know a way to find out.  only an authority server could be sure that
DNAMEs aren't in use, and most DNS characterization these days is done on
query/response flows or inside of caches.  and voluntary surveys of DNS data
and usage are notoriously inaccurate.

> A few things about DNAME struck me as strange or sub-optimal.  The main one
> is that you cannot use DNAME to completely move a zone, since you cannot
> move the zone apex.  Hence my wondering if this could be solved by having a
> CNAME at the DNAME (and putting the DNAME at the parent), or if it would
> make sense to define a DNAME2 that matched at the DNAME.

if you want to complete move a zone, you can't instantiate it, there will not
be an SOA.  you'd have to completely move that zone's namespace, which is to
say, you'd have to put a leaf-DNAME at the parent.  i must be misunderstanding
the complaint.

> The other thing is that I've found that very few people seem to understand
> DNAME, and it also seems very sparsely used.  So I wonder if this is because
> a) not enough software supports it, b) DNAME doesn't work quite the way
> people need it to to be useful, c) it suffers from a general lack of
> awareness (i.e., it would be used more if more widely known and understood),
> or d) it doesn't solve a problem that people actually have.

i'd say that (c) is most likely, and has led to (d) out of general ignorance.
that is, if (c) is true now and stops being true, then (d) would also die out.

---

From: David Blacka <[email-masked]>
Date: Sun, 18 Jun 2006 22:56:47 -0400

> and usage are notoriously inaccurate.

This is true.  But, in this case, a few real-world, still active  
examples would go a long way.  That is, it would make a huge  
difference (in my mind, at least) if a few folks just stood up and  
said "I use DNAME here because ..."  I'm guessing that this mailing  
list isn't the place to find out, though.

>> main one

The issue is that you cannot move the *entire* namespace of the  
zone.  These days there is frequently non-trivial content at the zone  
apex.

I'm not convinced that this is actually a problem, but it does seem  
sub-optimal to me.

>> understand

I think that (c) and (d) are mutually exclusive.  Either there are  
problems that people actually have that are solved by DNAME or there  
are not.  I'm not clear how increased awareness of DNAME leads to  
more problems.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Jun 2006 03:06:09 +0000

> > if you want to complete[ly] move a zone, you can't instantiate it, there
> > will not be an SOA.  you'd have to completely move that zone's namespace,
> > which is to say, you'd have to put a leaf-DNAME at the parent.  i must be
> > misunderstanding the complaint.
> 
> The issue is that you cannot move the *entire* namespace of the  zone.

you can if you do it at the parent, but not if...

> These days there is frequently non-trivial content at the zone  apex.

...there's necessary non-trivial content inside the zone.

what you're looking for sounds more like CNAME2 than DNAME2.  that is,
a fall-through for uninstantiated types.  call it the "OTHER" RR.  it
would only match queries whose {QNAME,QCLASS} matched an existing node
but whose {QNAME,QCLASS,QTYPE} did not match any existing RR's.  sadly,
there's no way to do this with authority-server synthesis, and no way
to require caches or stubs or applications to be able to understand it
any other way.  if you were hoping to accomplish this with DNAME2, then
i wonder what you thought the synthesized CNAMEs from the authority server
would end up doing inside caches and applications.  now, a DNAME2 that
could synthesize an OTHER at the apex and a CNAME otherwise, would work,
if OTHER could work, which it can't.

> >> understand DNAME, and it also seems very sparsely used.  So I wonder if
> >> this is because a) not enough software supports it, b) DNAME doesn't work
> >> quite the way people need it to to be useful, c) it suffers from a
> >> general lack of awareness (i.e., it would be used more if more widely
> >> known and understood), or d) it doesn't solve a problem that people
> >> actually have.
> >
> > i'd say that (c) is most likely, and has led to (d) out of general
> > ignorance.  that is, if (c) is true now and stops being true, then (d)
> > would also die out.
> 
> I think that (c) and (d) are mutually exclusive.  Either there are problems
> that people actually have that are solved by DNAME or there are not.  I'm
> not clear how increased awareness of DNAME leads to more problems.

a lot of people probably have a lot of problems that they don't recognize
as being DNAME-soluble simply because they don't know about DNAME or have
misunderstood the deprecation statements regarding A6 and bitstring labels.

---

From: David Blacka <[email-masked]>
Date: Mon, 19 Jun 2006 00:21:24 -0400

On Jun 18, 2006, at 11:06 PM, Paul Vixie wrote:

>> zone.

Not that I understood any of that, but it sounds way more complex  
that what I was thinking of.  The behavior that I am thinking of  
would be accomplished if DNAME2 matched at (and below) its  
ownername.  Or are you saying that that would not work?

I will continue to state that I do not know if such behavior is  
necessary or desired, I'm just thinking about it.

>> problems

yeah, that was (c).

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Jun 2006 04:47:16 +0000

> Not that I understood any of that, but it sounds way more complex that what
> I was thinking of.  The behavior that I am thinking of would be accomplished
> if DNAME2 matched at (and below) its ownername.  Or are you saying that that
> would not work?

DNS is often more complex than it appears.  Let me try again.

DNAME works by synthesizing CNAMEs in the authority servers for the zone and
optionally by synthesizing them in caches as well.  (Note that when we start
synthesizing CNAME from DNAME in caches, the TTL of the DNAME will function
as a long-lived whiteout for any new names one wishes to introduce in the
zone below the node of the DNAME, so such TTL's should be kept low, noting
that TTL's do not decrement in authority servers and so the impact of this
particular low TTL will be, um, low.)

If DNAME2 were to arrive which was like DNAME in other ways but had the added
feature of "matching at" rather than just "matching below" the node of the
DNAME2, then authority servers (and who knows, perhaps caching servers too?)
would be able to synthesize CNAME RRs for the node that the DNAME is at.  
Since anyone receiving this synthetic CNAME knows that a DNS node either is
or is not an alias, and that this node is an alias, that it cannot contain
other data, including most kinds of metadata, especially SOA.

I find this assertion-by-implication of the nonexistence of a zone cut to be
disturbing.  I would also find it disturbing if I were to ask for MX and get
a real answer (because there's an MX RRset there) and then I might ask for "A"
and get back a DNAME2 and a synthesized CNAME (because there was no "A" there)
and then I'd be left wondering, is that DNS node an alias, or is it not?

> I will continue to state that I do not know if such behavior is necessary or
> desired, I'm just thinking about it.

I will continue to state only that this design choice wasn't stylistic, and
to make a different choice you will need to be able to synthesize something
besides CNAME in order to make the DNAME2 effective at its own DNS node but
without the disturbing (to me) side effect of "turning that node into an
alias".  (And no, mandating a zero TTL on the synthetic CNAME won't fix it.)

---

From: David Blacka <[email-masked]>
Date: Mon, 19 Jun 2006 12:32:51 -0400

On Jun 19, 2006, at 12:47 AM, Paul Vixie wrote:

>> that what

I don't think that you are allowed to introduce *any* names below the  
DNAME, so I'm not sure what this "whiteout" you are speaking of is.

> other data, including most kinds of metadata, especially SOA.

This hypothetical DNAME2 would, indeed, have to be the only RR at its  
ownername, just like CNAME (and thus must be in the parent, not at a  
zone apex).  However, there could (and probably would be) a SOA at  
the *target* name.  That is what I mean by moving the entire zone.

I'm guessing one point of confusion here is that I'm not suggesting  
that if DNAME(2) matched at its ownername that it would *also* be  
present at the zone apex.

> and then I'd be left wondering, is that DNS node an alias, or is it  

This behavior that you are describing certainly sounds interesting,  
but doesn't seem to have much to do with what I'm talking about.

> alias".  (And no, mandating a zero TTL on the synthetic CNAME won't  

I did ask the question as to why DNAME didn't match at the DNAME  
itself, and the answers I got back from both you and Mark seemed  
stylistic to me.  The reasons were good, but it didn't seem like the  
choice was forced by the protocol.  If it were, then that would be  
very good to know.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Jun 2006 16:51:30 +0000

> > (Note that when we start synthesizing CNAME from DNAME in caches, the TTL
> > of the DNAME will function as a long-lived whiteout for any new names one
> > wishes to introduce in the zone below the node of the DNAME, so such TTL's
> > should be kept low, noting that TTL's do not decrement in authority
> > servers and so the impact of this particular low TTL will be, um, low.)
> 

if you remove the DNAME from the authority zone you will still have to wait
for the expiration of that DNAME's TTL in all caches before you can usefully
add nodes in the authority zone before the DNS node where the DNAME had been.

this seems obvious until you realize that as long as only authority servers
were doing the DNAME->CNAME synthesis, it wasn't true.  anything obvious that
happens not to be true creates an opportunity and therefore a likelihood that
some folks will depend on the contra-obvious behaviour.  so, i'm just saying.

> ownername, just like CNAME (and thus must be in the parent, not at a zone
> apex).  However, there could (and probably would be) a SOA at the *target*
> name.  That is what I mean by moving the entire zone.

oh.  ok.

> I'm guessing one point of confusion here is that I'm not suggesting that if
> DNAME(2) matched at its ownername that it would *also* be present at the
> zone apex.

indeed not.  when you spoke of "renaming a zone" it made me think that the
DNAME2 you wanted would have to be at the apex of some zone whose name you
wanted to change.  now i see that you want to "rename a zone-cut".  oops.
for this, most of us are currently using another set of NS RR's and just
loading and serving the same relativised zone content at multiple namespaces.

a DNAME2 that could only appear as a parent leaf and not a child apex is
not as obvious to me as an authority-server per-zone option that just said
"this relativised content should be made available under multiple zone
namespaces, and does not need to be loaded into memory (or DB) more than
once."  but i admit i'm biased toward the perspective of child zone
operations rather than delegation-only or mostly-delegation zone operations,
and also biased by my perspective as a sometimes-implementor of name server
software.  there could be meat further up this bone that i'm not seeing.

> I did ask the question as to why DNAME didn't match at the DNAME  itself,
> and the answers I got back from both you and Mark seemed  stylistic to me.
> The reasons were good, but it didn't seem like the  choice was forced by
> the protocol.  If it were, then that would be  very good to know.

had DNAME matched the owner name of the DNAME, it would not be valid to use
at a zone apex, where SOA and NS must also appear.  so, still not stylistic.

---

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