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: Paul Vixie <[email-masked]>
Date: Fri, 15 Apr 2005 16:30:17 +0000

> come to have a complete dislike for the DNAME.  Not just the document

it's a mindbender, no question.  but the reason we didn't cast it aside
when we killed bitstring labels is that it has a lot of good uses.

> For one, DNAME violates principles that have been voiced in opposition
> to things like NSEC3 and proposals to put application data in the DNS.

which principles?  and if these didn't exist at the time DNAME was approved
(as evidenced by its approval!) then how is it that DNAME can violate them?

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

well, that's you.  i take this to mean that "dns is hard."

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

(rhetorical question about whether ed took his pills today omitted.)

DNAME and wildcards work just fine.  try it:

  dig \
    1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.b.0.0.3.0.0.0.8.f.4.0.1.0.0.2.ip6.int \
    aaaa

see also <http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.txt>.

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

this, at least, sounds problematic and in need of clarification/revision.

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

i think you can amend it in a way that makes NSEC3 easier, without killing
it, simply because we all know that there's only one implementation (BIND9)
and very modest utilization so far.

far from removing DNAME, i think we need to work on nonterminal wildcards
and per-rrtype wildcards.  not all complexity is bad; sometimes if you add
good kinds of complexity you prevent bad kinds of workarounds.

the big problem with DNAME is that people who havn't read about it end up
proposing things that aren't compatible with it and then they feel blindsided
when the real problem is that they didn't do their research well enough.

---

From: David Conrad <[email-masked]>
Date: Fri, 15 Apr 2005 10:26:03 -0700

On Apr 15, 2005, at 8:52 AM, Edward Lewis wrote:
> others?

Perhaps not surprisingly, Nominum CNS supports DNAME.

> (Has interoperability been achieved?)

I'm not aware of any formal interoperability tests, although I suspect 
a number of informal tests have been done.

> If there is interoperability and widespread use, then the RFC ought to 
> be amended for completeness.

If there is a need for amendment, yes.

> If not, I'd like to put forward the idea of obsoleting the record.

I would not want to do this, but that's just me.

Rgds,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Fri, 15 Apr 2005 14:10:50 -0400

>(as evidenced by its approval!) then how is it that DNAME can violate them?

Principles seem to change over time.  Witness the gradual 
"un-definition" of "* NS".

The principle I have in mind is seen in the message I 
referenced...changes to the lookup algorithm.  Without DNAMEs, caches 
could still just use hash buckets to store data, with DNAMES the tree 
is needed.  To me that seems a significant change.

>see also <http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.txt>.

OTOH, someone from ISC was behind outlawing "* DNAME".

I know that in some cases DNAME works.  I am just questioning if it 
works in all cases.  The doc is weak, and there is a call to make "* 
DNAME" illegal.

That's why I'm questioning...

>and very modest utilization so far.

There's no link of NSEC3 to DNAME per se.  I raised NSEC3 because of 
the observation that it too mentioned changing the search algorithm - 
and that was cited as a problem.

>when the real problem is that they didn't do their research well enough.

I think the big problem with DNAME is that when reading the doc, it's 
unclear what happens.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Fri, 15 Apr 2005 14:12:04 -0400

>Perhaps not surprisingly, Nominum CNS supports DNAME.

Until now, I hadn't heard of anyone else implementing it...

>I would not want to do this, but that's just me.

I'm still curious about how much use it is getting.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Alex Bligh <[email-masked]>
Date: Fri, 15 Apr 2005 19:30:47 +0100

--On 15 April 2005 14:10 -0400 Edward Lewis <[email-masked]> wrote:

> I raised NSEC3 because of the observation that it too mentioned changing
> the search algorithm - and that was cited as a problem.

Strictly speaking, NSEC3 does NOT mention changing the search
algorithm. It was me that pointed out an argument from before NSEC3
was proposed, that if the hash space and the "valid" native namespace
overlapped, AND the search algorithm wasn't changed, THEN this
would alter existing wildcard behaviour if a zone publisher changed
from NSEC to NSEC3 in some corner cases (QNAME=a hashed name, QTYPE!=NSEC3,
wildcard present). It has yet to be established this is a real world
problem (not least because the publisher itself is aware of it so
may just accept "heh, a consequence of signing with NSEC3 is I may
generate a funny response for queries starting with two underscores"
or whatever).

What people did say was that solving this (potential non-) problem
by changing the search algorithm was undesirable. I think your point
is that there is a precedent with DNAME. But the above does not
equate to NSEC3 requiring a change to the search algorithm!

Alex

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Apr 2005 18:43:56 +0000

> > which principles?  and if these didn't exist at the time DNAME was
> > approved (as evidenced by its approval!) then how is it that DNAME
> > can violate them?
> 

at the risk of kicking a dead war, that's a bad example since many of us
felt that "* NS" was always implicitly-but-provably meaningless and that
the only thing needed to "kill" it is an editorial clarification, not a
protocol or principle change.

> referenced... changes to the lookup algorithm.  Without DNAMEs, caches

it's a significant change to implementations of future enhancements, sure.
but as approved, it required no change to any principle we then knowingly
held.  but i suspect that this definitional wordplay will not lead us to
a better joint understanding so let's move on.

> I know that in some cases DNAME works.  I am just questioning if it works
> in all cases.  The doc is weak, and there is a call to make "* DNAME"
> illegal.
> 

there have been calls to do all kinds of things.  saying "i want a pony"
will not, however, make one appear.  (unless you're one of my daughters,
it seems.)  but to balance things out, i'm calling for "* DNAME" to remain
legal, since i'm using it, and i find it useful, and since it's the first
brick of the "nonterminal wildcard" proposal i've been considering a while.

> and that was cited as a problem.

if dname changed the search algorythm in the same way and to the same extent
and nothing bad has happened then we shouldn't stand in the way of changing
it still further for NSEC3.  however, i think the NSEC3 changes are different
in their nature and extent than the DNAME changes.  something to do with
backward compatibility and split data horizons.  let's revisit it and see
if our new-found terminology and perspective sheds different light on it?

> I think the big problem with DNAME is that when reading the doc, it's

well, there's a call for editorial improvements to the doc, so that's out
of the way.  now let's focus on the issue at hand, which appears still to
be zone walking?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Apr 2005 13:45:28 +1000

> idea of obsoleting the record.

	The reason for blocking "* DNAME" is that it results in different
	results from authoritative servers compared with the results that
	come from the cache.

	Plain (non-wildcard) DNAME.

	"example.com DNAME foo.net" is like
	"*.example.com CNAME <match of wildcard>.foo.net".  Note there
	is a implict wildcard generated by the DNAME that *also* operates
	in caches.  To get consistant results from both authoritative
	servers and caches no subdomains of the DNAME owner are permitted.

	With wildcard DNAME you have *only* the explict wilcard being expaned
	by the authoritatives servers and *only* the implicit wildcard being
	expanded by the caches.  This results in different answers depending
	apon which server you query.

	As for which servers support DNAME.  Every server that supports
	DNSSECbis is required to support DNAME.

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

---

From: "Niall O'Reilly" <[email-masked]>
Date: Wed, 27 Apr 2005 08:40:46 +0100

On 27 Apr 2005, at 04:45, Mark Andrews wrote:

> Note there

Succinct, clear, helpful, bravo!

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Edward Lewis <[email-masked]>
Date: Wed, 27 Apr 2005 07:52:29 -0400

>University College Dublin Computing Services

Maybe it's my American English or my desire for longer email 
messages, but, Mark, could you cook up an example?  Maybe a zone with 
just a DNAME and one other name below the apex and then a sequence of 
queries showing what you mean?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 27 Apr 2005 09:59:12 -0400

>	results from authoritative servers compared with the results that

So, unlike '* NS' this case ought to be outright "banned?"

By that I mean, '* NS' was once plausible, but DNSSEC has made 
exposed the rift in the fabric of DNS and created a protocol pinch 
point.  It seems that '* DNAME' has never been a wise idea and should 
have been explicitly prohibited when this went to proposed standard.

>	apon which server you query.

So, to try an example (I know I asked for one earlier):

If there is a "*.example DNAME cctld." here are two scenarios...

SCENARIO 1

Query                  Cache                    Authoritative

www.zone1.example.     ------------------------> responds with
                                                  www.zone1.example DNAME

                        www.zone1.example DNAME <----

www.sub.zone1.example. (cache miss) -----------> responds with
                                                  www.sub.zone1.example. DNAME

SCENARIO 2

Query                  Cache                    Authoritative

zone1.example.         ------------------------> responds with
                                                  zone1.example DNAME

                        zone1.example. DNAME <--------

www.zone1.example.     falls under DNAME above
                        "synthesizes" the CNAME
                        www.zone1.example. CNAME www.tld
zone1.example.     DNAME tld. <----------
www.zone1.example. CNAME www.tld.

www.sub.zone1.example.  (Not a cache miss this time)

It seems to me that DNAME processing in the cache is the culprit.

>	DNSSECbis is required to support DNAME.

That's not a good gauge.  There is no enforcement of IETF standards...;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: "Niall O'Reilly" <[email-masked]>
Date: Wed, 27 Apr 2005 20:55:21 +0100

On 27 Apr 2005, at 12:52, Edward Lewis wrote:

> Maybe it's my American English or my desire for longer email messages, 
> but, Mark, could you cook up an example?  Maybe a zone with just a 
> DNAME and one other name below the apex and then a sequence of queries 
> showing what you mean?

I hope this isn't too short, and that I'm not "teaching my grandmother 
to suck eggs",
as we say in this part of the anglophone world.  8-)

A well-crafted example would be nice, and I'll take off my hat to 
whoever shows one.
See also the penultimate sentence below.

What I found truly wonderful about Mark's message was that he told me 
something
which, on reflection, I believe I must already have known, but had 
never recognized
in such simple terms.

What it comes down to is, not mixing the kinds of synthesis you use.

Simple terminal (non-NS, non-DNAME) wildcard specifies a synthesis 
which might be
called "default terminal substitution".  This is synthesis because the 
given QNAME
does not match the NAME of any existing RR; an RRset is brought into 
existence on
demand.

Simple CNAME specifies "specific terminal substitution".  In this case, 
what
happens is not synthesis; the given QNAME matches an existing RR, and 
the
specified substitution is performed.  No tricks.

Simple DNAME specifies "non-terminal substitution".  This is synthesis 
because,
just like the simple wildcard case, the given QNAME does not match the 
NAME of
any existing RR.

What Mark helped me realize is that these two kinds of synthesis are 
sufficiently
different that there is probably no circumstance in which mixing them 
would be
appropriate.

A well-crafted example contradicting this view would be a significant 
contribution
to the discussion.

Non-terminal wildcard and wildcard NS are topics on which I don't feel 
prepared to
comment.

/Niall

---

From: David Blacka <[email-masked]>
Date: Wed, 27 Apr 2005 16:18:35 -0400

> 	DNSSECbis is required to support DNAME.

What do you mean by server?  What do you mean by "support DNAME"?

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

---

From: [email-masked]
Date: Wed, 27 Apr 2005 20:33:05 +0000

> David Blacka wrote:

	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?

--bill

---

From: Rob Austein <[email-masked]>
Date: Wed, 27 Apr 2005 16:54:53 -0400

> OTOH, someone from ISC was behind outlawing "* DNAME".

Note that the technique outlined in the above reference does not in
fact use wildcard DNAME.  It uses plain old DNAME.

I think that Niall's observation is correct.   Part of the reason that
wildcard DNAME make's people's heads hurt is that it's a mixture of
two different kinds of synthesis, which work in sufficiently different
ways that the result is (at best) undefined.

I do not believe that wildcard DNAME ever worked, any more than
wildcard NS ever worked.  Stating that the result of using them is
undefined is simply acknowledging the behavior of horses that left the
barn long ago.

---

From: Rob Austein <[email-masked]>
Date: Wed, 27 Apr 2005 17:12:22 -0400

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Apr 2005 09:51:05 +1000

> queries showing what you mean?

	*.example.net DNAME foo.bar

	Perform the following query sequence.
	a) sub.example.net/ANY
	b) www.sub.example.net/A

	Auth server:
	a) sub.example.net DNAME foo.bar
	b) NODATA

	Cache:
	a) sub.example.net DNAME foo.bar
	b) sub.example.net DNAME foo.bar +
	   www.sub.example.net CNAME www.foo.bar

---

From: [email-masked]
Date: Thu, 28 Apr 2005 00:14:58 +0000

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Apr 2005 10:40:17 +1000

> 	(oh for better connectivity... :)

	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

---

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: Roy Arends <[email-masked]>
Date: Thu, 28 Apr 2005 16:19:06 +0200 (CEST)

On Thu, 28 Apr 2005, Mark Andrews wrote:

> 	aware to the server.

exactly.

>                             That is very different to saying that

So, well, until I see a signal that martians exist, I assume no martians
exist, especially when I can only depend on that signal to tell me
martians exists.

> 	That arguement should have been made six years ago.

Well, I'm making it now.

btw, how was interoperability tested with DNAME ? What was the other (as
in, other than BIND) implementation?

Why not move this to experimental, as we did with A6 ?

Roy

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Thu, 28 Apr 2005 10:42:48 -0400

>in, other than BIND) implementation?

Good question, has anyone else implemented DNAME processing ?

>Why not move this to experimental, as we did with A6 ?

As this is a DNSEXT specific question the joint process (DNSEXT +NGTRANS)
that lead to move of A6 to experimental did not have authority to
make that change.
The choices we have in front of us regarding DNAME are:
         Fix the specification
         Move it to experimental (i.e. make it optional to support)
         Obsolete DNAME

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

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.

         Olafur
PS: in regards to feature signalling at some point it might be worth while
to create a profile of required RFC's to implement for implementations
to be compliant with "modern" DNS.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Apr 2005 00:59:02 +1000

> exist, especially when I can only depend on that signal to tell me

	If the client groks a DNAME record then it is DNAME aware.
	Servers don't care if the client is DNAME aware or not.
	They just send the DNAME (for the DNAME aware clients) and
	the CNAME (for the non-DNAME aware clients).  Being able
	to say I understand DNAME is a optimisation not a requirement.

> in, other than BIND) implementation?

	You don't need interoperability to get a PS, you need it for a DS.
 
> Why not move this to experimental, as we did with A6 ?

	Because it is useful.  Because there is no need to move it
	to experimental.  I and I suspect others took great care
	to ensure DNAME was not marked as experimental when A6 and
	bitstring labels were moved to experimental.  That would
	have been throwing the baby out with the bath water.

	Section 4 of RFC 3363 is completely without basis.  The
	initial premise is false.  One can easily do a similar
	demonstation with nibble based reverse lookups as was
	done with bitstring based lookups in RFC 2874 and therby
	prove the initial premise false.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Apr 2005 01:07:23 +1000

> Good question, has anyone else implemented DNAME processing ?

	DRC has already said CNS implements DNAME.
 
> The first question to ask: is something like DNAME a useful feature in DNS?

	Yes.  We asked this question 6 years ago and the answer was
	yes then and it is still yes today.

	I suspect a lot have not implemented DNAME because they
	have mis-read RFC 3363 to imply that DNAME is experimental.
	I've heard "But isn't DNAME experimental?" so many times.

---

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.

> thing to do, if the answer is YES then the other options remain on the

clarify the specification, is my advice.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 28 Apr 2005 11:29:53 -0400

First let me apologize for stirring up such a 
nest of trouble. ;)  I only wanted to get wcard 
done.  I swear.

At 10:42 -0400 4/28/05, Ólafur Guðmundsson /DNSEXT  co-chair wrote:

>Good question, has anyone else [other than BIND] implemented DNAME processing?

I believe Nominum has done it.

(someone else) >Why not move this to experimental, as we did with A6?

>         Move it to experimental (i.e. make it optional to support)

And the ever popular option of "leave it as is."

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

I'd like to hear cases for the DNAME, and cases 
where it has proven to be a big help. 
Personally, as an architectural purist, I think 
it's an abomination - but if it's something of 
benefit, it's worthwhile.  (Don't let the bus 
driver determine the route.)  To date, I have 
heard a few strong voices say "it's important" 
but there hasn't been much anecdotal data to 
support the claims.

Note - no offense to "strong voices" but it takes 
more than a comment from a reputable person to 
support something.  People come and go, 
reputations are fleeting, that is why it pays to 
document use cases, etc.

>thing to do, if the answer is YES then the other options remain on the

And if the answer is unclear, then...;)

>to be compliant with "modern" DNS.

While this is admirable, I don't see a nest of 
engineers ever defining a useful profile. 
Operators would be invaluable for this...you'd be 
surprised at the differing perspectives of a 
protocol architect and of a service provider.

---

From: Jim Reid <[email-masked]>
Date: Thu, 28 Apr 2005 16:48:04 +0100

> Good question, has anyone else implemented DNAME processing ?

I'm fairly sure it's in the Nominum servers.

---

From: David Conrad <[email-masked]>
Date: Thu, 28 Apr 2005 10:14:19 -0700

Hi,

> Good question, has anyone else implemented DNAME processing ?

Nominum has.  It works.

>         Move it to experimental (i.e. make it optional to support)

Unless DNAME is going to be obsoleted, I believe the specification 
should be fixed.

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

I believe so.

> to be compliant with "modern" DNS.

I would imagine that such a profile would be a teensy bit controversial 
and may with a bit of luck be completed before heat death of the 
universe.  Just maybe.

Rgds,
-drc

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 28 Apr 2005 20:45:13 +0100

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

Yes, definitely.

On 28 Apr 2005, at 16:29, Edward Lewis wrote:

> I'd like to hear cases for the DNAME, and cases where it has proven to 
> be a big help.

I've found it operationally useful for consolidating the administration
of scattered parts of both the in-addr.arpa and e164.arpa hierarchies
into a single zone file (à la RFC2317, but for shorter prefixes than 
/24).

For an example, dig 1.7.0.2.6.1.7.1.3.5.3.e164.arpa. naptr

To my mind, using $GENERATE or creating numbers of zone files containing
256 or 65536 CNAME records is considerably uglier, and creating lots of
delegation points with paired configuration entries and microzone files,
worse again.

/Niall

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Apr 2005 03:54:59 -0000

Niall O'Reilly writes:
> 256 or 65536 CNAME records is considerably uglier

You're having trouble configuring your computer. This is not an Internet
protocol problem. Your computer is not having trouble communicating with
DNS clients. You should not be asking for changes in the DNS protocol;
you should be complaining to whoever wrote your server software.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 29 Apr 2005 08:30:15 +0100

On 29 Apr 2005, at 04:54, D. J. Bernstein wrote:

> You should not be asking for changes in the DNS protocol;

Agreed.  I'm not.  I'm arguing against downgrading an
existing and useful protocol element to "experimental".

Best regards,

Niall O'Reilly

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 29 Apr 2005 13:25:44 +0300 (EEST)

> 	   www.sub.example.net CNAME www.foo.bar

Not all caching servers will actually give the response shown on the
last two lines of the example above, and it's far from clear that this
response is the correct one based on the DNAME specification.

Let's look at what the caching server will do in terms of the

>	a) sub.example.net/ANY

Here, the caching server will cache the record "sub.example.net
DNAME foo.bar".  The caching occurs in step 4a of the algorithm
(not step 4d - this DNAME is simply the answer to the question,
not a DNAME being redirected through to find the answer).

>	b) www.sub.example.net/A

This is where we get into murky waters.  When the caching server
resolves this query, at what step of the resolver algorithm does the
DNAME we just cached come into play, if any?

As far as I can see, the text of RFC2672 section 4.2 doesn't say.
Clearly in step 1 the answer is not in local information, so we
proceed to step 2, "find the best servers to ask", but what happens in
that step is unclear.  I see the following possible interpretations:

  1) "Finding the best servers to ask" means looking for the closest
     parent node with cached NS records, just as it did when DNAME was
     not yet invented.

     In this case, the cache ends up sending the "www.sub.example.net/A"
     query to the authoritative server which responds with a
     NODATA response because there is no A record at "*.example.net.".
     The client will get a NODATA response, not the DNAME + CNAME response
     Mark showed.

  2) "Finding the best servers to ask" means looking for the closest
     parent node with cached NS records or a parent node with a cached
     DNAME record.  If a cached DNAME is found, the SNAME is
     rewritten, a DNAME and optional synthetic CNAME are added to the
     response, and the search for the best servers is restarted at the
     SNAME, in a way similar to what authoritative servers do in
     section 4.1 step 3c.

     In this case, the response will be the DNAME + CNAME response
     Mark showed.

  3) "Finding the best servers to ask" means looking for the closest
     parent node with cached NS records or a parent node with a DNAME
     record that was cached in step 4d of the algorithm (due to being
     involved in a rewrite), disregarding any DNAME record that was
     cached in step 4a (due to being the answer to a query).
     If the former kind of DNAME is found, we rewrite as in 2) above.

     In this case, the client will get a NODATA response, as in 1).  
     The advantage of this interpretation over 1) is that it will avoid
     making queries to the authoritative servers in some situations where
     a server doing 1) would make them.

Of these interpretations, 1) seems closest to the letter of RFC2672,
but I don't know any implementation using it.  BIND 9 does 2), and
Nominum CNS does 3).

I would argue that the inconsistency between the responses from the
authoritative and caching server in Mark's example indicates a
problem with the BIND 9 implementation, not a problem with the DNAME
specification.  A server implementing the specification literally (as
in case 1 above) will not exhibit the inconsistency.

Also, this issue doesn't actually have anything to do with wildcards.
If you replace the "*" in Mark's example with "sub", you will get
exactly the same results.  This of course means that outlawing
wildcard DNAMEs would not eliminate the inconsistency.

If this message seems familiar, it's because I sent an almost
identical one in 2003 when the wildcard DNAME discussion last came up.
I have just changed the domain names to refer to Mark's current
example rather than the one that was used in the 2003 discussion and
made some minor edits.
--
Andreas Gustafsson, [email-masked]

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 29 Apr 2005 08:44:07 +0100

> you should be complaining to whoever wrote your server software.

Dan,

To quote a comedy TV series from my part of the world: "That would
be an ecumenical issue".  Let's keep such discussions off-list.

/Niall

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 29 Apr 2005 13:51:13 +0300 (EEST)

A small correction to my previous message...  I said:
> exactly the same results.

Actually, you won't.  Mea culpa.  Although the question of how cached
DNAMEs affect the resolution algorithm applies equally to DNAMEs that
resulted from wildcard expansion and ones that don't, the specific
inconsistency Mark showed only happens in the wildcard case.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Sat, 30 Apr 2005 11:55:33 +0000

> University College Dublin Computing Services

	er... at what point did "experimental" == "downgrade"

--bill

---

From: [email-masked]
Date: Sat, 30 Apr 2005 11:59:24 +0000

thank you andreas.  it is clear that the beahviour of the caching
engine is underspecified here and needs work.  I think that option
one is the correct behaviour - but since caches are woefully
underspecifed, we get into nasty interoperability problems.

--bill

---

From: "Niall O'Reilly" <[email-masked]>
Date: Sat, 30 Apr 2005 13:44:07 +0100

> 	er... at what point did "experimental" == "downgrade"

Fair point.  Ed's slogan applies:

/Niall