Subject: Re: wcard-clarify violating RFC 2119, section 6

From: Kevin Darcy <[email-masked]>
Date: Thu, 04 Sep 2003 15:54:51 -0400

[email-masked] wrote:

> > Not to be contrary, but I think the more _modern_ way to view it is that a
> > DNS name is just a concatenated sequence of labels which forms a unique index
> >  into
> > a DNS database. From that standpoint, the distinction between "terminal" and
> > "nonterminal" really loses its meaning and it seems rather silly and quaint f
> > or a
> > query of an empty "nonterminal" node to return anything different than a quer
> > y of
> > an empty "terminal" node. Empty is empty. Period. Whatever negative-caching
> > optimizations are theoretically possible as a result of the seemingly-inconsi
> > stent
> > empty-terminal-vs-empty-nonterminal response differentiation seem to me to be
> > underutilized and not worth the confusion and the extra code and resources
> > required to interpret such response variations.
> >
> > Obviously, the hierarchical structure of the DNS database is still important
> > from
> > a zone-delegation/referral standpoint. But as a *database*structure*, the
> > hierarhical paradigm has long been superceded by relational and/or contextual
> > paradigms. Maybe it's time to let it go...
>
>         Kevin this isn't about the "modern way".  This is about
>         clearing up any ambiguities in the definition.

Those are not mutually exclusive goals. If we have a more-or-less equal choice of
one interpretation or another, why not go with the one future administrators are
more likely to find familiar and intuitive?

> There are
>         lots of nameservers that follow RFC 1034 and support empty
>         nodes by returning NOERROR/NODATA.

I never questioned that. What I questioned was whether there were any/many caching
resolvers that actually use the NODATA response to "prune" the namespace so as to
obviate future queries for subsidiary nodes (that's what I was alluding to by the
term "negative-caching optimizations") for the duration of the negative cache
entry.

If no-one, or very few implementations, are actually using the optimization that
has been offered, and the behavior is confusing and quirky and requires more
programming logic to parse, let's clarify the spec to simplify the response
behavior -- i.e. empty node -> NXDOMAIN, whether it's terminal or nonterminal --
and move on.

-Kevin

--
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: Edward Lewis <[email-masked]>
Date: Thu, 4 Sep 2003 18:25:29 -0400

At 15:54 -0400 9/4/03, Kevin Darcy wrote:
>Those are not mutually exclusive goals. If we have a more-or-less equal
>choice of one interpretation or another, why not go with the one future
>administrators are more likely to find familiar and intuitive?
>
...
>
>If no-one, or very few implementations, are actually using the optimization
>that has been offered, and the behavior is confusing and quirky and requires
>more programming logic to parse, let's clarify the spec to simplify the
>response behavior -- i.e. empty node -> NXDOMAIN, whether it's terminal or
>nonterminal -- and move on.
...

While it would be insane of me to defend the current definition DNS 
as an epitome of excellent engineering, let's keep in mind the scope 
and bounds of our work as a group.  After a decade of beating my head 
against a pile of specifications and bloodied by the points of a 
thousand staples while trying to hammer out a workable DNSSEC 
definition, it is painfully obvious (to me) that DNS has some quirks, 
to put it nicely.

The current WG has two main points of work, DNSSEC and LLMNR.  For 
the group to ever hope of being successful (which is, "closed") we 
need to make sure we restrict ourselves to those two topics. 
wcard-clarify is written because of work in DNSSEC, not because 
there's a need to fix DNS per se.

As far as whether we should use the new features (DNSSEC) to right 
old wrongs, I can say from experience that when you extend any system 
in a way not in keeping with the original spirit of the system - 
right or wrong - the extension is bound to fail.  Exhibit A - RFC 
2065.  Exhibit B - RFC 2535.  Exhibit C - the house I almost bought 
in Severna Park until I noticed the incredibly straight crack in the 
basement floor (paralleling the old foundation).  Thus its apparent 
to me that we need to extend DNS within the lunacy of the current DNS.

I applaud the brave souls who wish to charge off and redefine a 
naming system, one that fixes the wrongs in DNS, fixes the wrongs in 
X.509 and LDAP, one that would have let DCE choose one system and not 
four! (4!) naming systems in its middleware offering. (~10 years ago, 
a product of the OSF.)  While you brave souls have a lot of previous 
work to build upon, remember that engineers of yore were just as 
bright as you and they didn't get it right, so it's not likely you 
will either.  It's not a statement about you, it's that the problem 
is just plain hard.  (And don't forget to measure deployment time in 
decades.)

I'm not willing to commit to replacing DNS with a workable system. 
(I'd like to retire some day with career closure.)  I'm not willing 
to again inflict pain on myself trying to extend a system that needed 
an adjustment to make the extension work.  (Like never again buying a 
used car that had it's frame straightened.)  I am willing to wind up 
extending a current system and, if I need to, declare failure when I 
find the foundation wasn't strong enough.

This is why wcard-clarify is in front of us.  To make sure the 
foundation of DNS is right for extension.  This is why I think 
Simon's comments are the most important - he's questioning if the 
clarifications are really within line of the original foundation. 
This is why I'd rather not get into the rat hole of what a 'name 
error' is in a cache - that's not part of the synthesis problem. 
Let's resist the temptation to widen the scope of any clarification 
work.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

---

From: [email-masked]
Date: Fri, 05 Sep 2003 09:50:52 +1000

> term "negative-caching optimizations") for the duration of the negative cache

	You can't use NODATA to prune namespace.  You can theoretically
	use a NODATA response to a ANY to answer queries for other types.

	You can theoretically use NXDOMAIN to prune namespace provided
	you have RFC 1034's definition of NXDOMAIN (Name Error).
 
> behavior -- i.e. empty node -> NXDOMAIN, whether it's terminal or nonterminal

	empty terminal nodes DO NOT EXIST.
	
	If I give you a domain name a.b.c.d.e.f.g.example then the
	super domains are b.c.d.e.f.g.example, c.d.e.f.g.example,
	d.e.f.g.example, e.f.g.example, f.g.example, g.example
	example and ".".  It is illogical to have a "sub-domain"
	of something that does not exist.  This is what returning
	NXDOMAIN for empty nodes produces.
 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Sep 2003 01:50:31 -0000

Kevin Darcy writes:
> If no-one, or very few implementations, are actually using the
> optimization that has been offered, and the behavior is confusing and
> quirky and requires more programming logic to parse, let's clarify the
> spec to simplify the response behavior -- i.e. empty node -> NXDOMAIN,
> whether it's terminal or nonterminal -- and move on.

There are two separate proposals here:

   (1) Telling caches that they can't apply NXDOMAIN to subdomains. This
       is important, and appears to have already been done by RFC 2308.
       Existing caches already comply with this rule. New caches have to
       comply too, because many server installations generate (and will
       continue to generate) NXDOMAIN for empty nonterminals.

   (2) Telling servers that they have to use NXDOMAIN rather than NODATA
       for nonempty terminals, or in any other situation where both
       NXDOMAIN and NODATA work. I see no interoperability excuse for
       this; NXDOMAIN is, from a protocol perspective, at best a minor
       speedup. I chose NXDOMAIN because it simplified my code, not
       because Vixie claimed that it was required; others might choose
       NODATA for the same reason. Anyway, many existing installations
       use NXDOMAIN, and many others use NODATA.

Neither proposal is tied to the definition of wildcards in DNSSEC.

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