Subject: Re: Who hates the DNAME?

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

At 16:30 +0000 4/15/05, Paul Vixie wrote:

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

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

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

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.

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

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

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