Subject: Re: Who hates the DNAME?

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

On Thu, 28 Apr 2005, Mark Andrews wrote:

>
> > On Thu, 28 Apr 2005, Mark Andrews wrote:
> >
> > > 	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.
> >
> > 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.

exactly.

>                             That is very different to saying that
> 	there are no DNAME aware clients.

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.

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

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

---

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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

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: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: 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
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: [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: 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