Subject: Re: DNAME questions

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

On Jun 18, 2006, at 7:06 PM, Mark Andrews wrote:
>>
>> But, why was there a desire to deploy the DNAME at the zone apex and
>> not at the parent?
>
> 	Because all the nameservers for a zone with a DNAME have
> 	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.

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

>
>> It is clear that having caches synthesize from a cached DNAME is
>> *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

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.

--
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: 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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.