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

From: Kevin Darcy <[email-masked]>
Date: Thu, 04 Sep 2003 22:43:25 -0400

[email-masked] wrote:

> > [email-masked] wrote:
> >
> [Are] there any/many caching
> > resolvers that actually use the NODATA response to "prune" the namespace so a
> > s 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.
>
>         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).

Sorry, I said that the wrong way around -- I meant NXDOMAIN-based pruning. The
question still stands: do any extant implementations you know of actually use such
NXDOMAIN responses to negatively cache subdomains? Does BIND?

> > If no-one, or very few implementations, are actually using the optimization t
> > hat
> > 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.
>
>         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.

Well, I'll try to make this short, since as others have pointed out, this
discussion is wandering somewhat astray of the I-D in question. Suffice it to say,
there are only 2 reasons why a resolver would care about the tree structure of
DNS: 1) in order to follow referrals to get its answer, or 2) because it might, in
the context of optimizing its negative caching, be smart enough to "prune" the
namespace tree if it gets a particular RCODE, so as to obviate subsequent
forwarded queries for descendant nodes, for the duration of that negative cache
entry.

But, if we assume that the resolver has already made it to an authoritative
nameserver for the zone in question (therefore reason #1 for caring about the tree
structure doesn't apply) and if reason #2 doesn't apply (as far as I know, no-one
has identified any resolver implementation that uses NXDOMAIN-pruning to its
advantage), what is the value to the resolver of having two different possible
response codes to the query of an empty node? It doesn't care about the tree
structure. Having multiple possible responses for essentially the same scenario
just makes response processing more convoluted and inefficient, not to mention
being less intuitive to us humans.

- 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 23:12:22 -0400

At 22:43 -0400 9/4/03, Kevin Darcy wrote:
>discussion is wandering somewhat astray of the I-D in question.

Amen. ;)

>what is the value to the resolver of having two different possible

Because going through the process of fixing this is worse that what 
we have, that's the best excuse I can come up with.  That's my story 
and I'm sticking to it.

I agree it's inane to have multiple ways to say "no" but we have 
quite a long history of it.  Maybe once we get to authenticated 
denial of existence a lot will be cleaned up, because there will be a 
record in the answer that says "no."  When that happens, we will 
still have name errors and non-name errors, but at least we'll have 
something in the authority section.  (Unless it's just telling us 
that there's no DS at an existing delegation.)

BTW, in my day job, I'm testing for lameness.  I'm getting some 
responses that have these settings - aa = 0, ra = 0, rcode = 0, 
an/ns/adcount = 0/0/0 - as nearly empty a response as I can can 
imagine, 1's-wise.  (The query has rd=0, and the query goes to an 
alleged authoritative server, asking for the SOA RR.)  I've been 
scratching my head on this and guess it's a type 3 "no data" answer 
from RFC 2308 - although it's lacking an aa bit.

If ancount was > 0, it'd be a classic referral.  If aa=1, it'd be a 
classic no error but no data.  As it stands, it looks like a negative 
answer from a cache that won't do recursion for me.  I suppose.  I 
can't say it's an illegal answer from the RFCs, but it leaves me 
guessing as to what is wrong.

DNS is puzzling...I agree...but it's "our" DNS.  (As in, like that 
weird uncle in the family.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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