Subject: Re: Who hates the DNAME?

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Apr 2005 16:30:17 +0000

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

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.

--
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 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?
> 
> Principles seem to change over time.  Witness the gradual
> "un-definition" of "* NS".

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.

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

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.
> 
> That's why I'm questioning...

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.

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

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
> unclear what happens.

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?