Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness

[Brian Dickson <[e-mail]>]

I have some questions, which this discussion has caused me to consider...

(I apologize if they are answered in some RFC or another already,
and/or they may need to be addressed in some future -bis document if
they don't belong here.)

On Thu, Feb 24, 2011 at 12:45 AM, Paul Vixie <[e-mail]> wrote:
>> Date: Wed, 23 Feb 2011 14:04:15 -0500
>> From: Edward Lewis <[e-mail]>
>>
>> #      A. Revalidating a delegation when a parent NS RRset TTL expires.
>>
>> What does it mean to "validate" a delegation?  We have a definition of
>> validation in the context of DNSSEC.  I am sure this is different.
>
> in this context it means making sure the delegation still exists.

Delegations come from referrals and authority sections thereof...
(restating the obvious.)

There is an odd corner case to consider, but I'm not sure if it's been
considered, and I think it is something which is slightly more likely
to occur nowadays than in the distant past:

Suppose a nameserver serves both a particular zone, and a
great(^n)-grandchild zone.
(E.g. a nameserver serving some TLD, and simultaneously doing DNS
hosting for third parties.)
Suppose also, that some intermediate zone(s), great(^n-1)-grandchild,
parent of the great(^n)-grandchild zone, is *not* served by this
nameserver,. but is delegated elsewhere. That "other" server then
delegates back to "this" server, for the great(^n)-grandchild zone.

An iterative resolver, directed to this (TLD) server by the root
server(s), when querying for the great(^n)-grandchild zone, gets back
an answer for the great(^n)-grandchild *directly* (no passing "go"),
including that zone's authority data.
It gets that without ever chaining through the delegations from the
TLD through the great(^n-1)-grandchild zone(s).

(Obviously in the DNSSEC case, there would need to be explicit DS
chasing and proofs included in serving the answer, if DO=1 on the
client query.)

Should not the iterative resolver look for the intermediate referrals,
if they aren't already in the cache?
I think it *needs* those to "validate" the delegation... (i.e. for the
optimization of the present proposal.)

Have I lost everyone yet?

>> #      B. Stopping a downward cache search when an NXDOMAIN is encountered.
>>
>> I'm not so sure this is a good one.  It goes against RFC 2308.
>
> see below.
>
>> #   3.2. When searching downward in its cache, an iterative caching DNS
>> #   resolver should stop searching if it encounters a cached NXDOMAIN.
>> #   The response to the triggering query should be NXDOMAIN.
>> #
>> #   3.3. When an iterative caching DNS resolver stores an NXDOMAIN in its
>> #   cache, all names and RRsets at or below that node should be deleted
>> #   since they will have become unreachable.
>>
>> This is in conflict with RFC 2308, section 5:
>>
>> RFC A negative answer that resulted from a name error (NXDOMAIN) should
>> RFC be cached such that it can be retrieved and returned in response to
>> RFC another query for the same <QNAME, QCLASS> that resulted in the
>> RFC cached negative response.
>>
>> This says that the cached NXDOMAIN only applies to the FQDN itself, not
>> it's domain.  Ok, ok, that's just paper fighting paper, but this switch in
>> requirements has to be addressed.
>
> it does not say "only", which would have been overprescriptive, and the
> resimprove proposal could be seen as a 2308 amendment to the effect that
> in addition to what 2308 says, and is not in conflict with it.  if so then
> it would make resimprove a standards track document not a bcp.
>
>> And I have a sneaking suspicion that this optimization isn't all that good
>> of an idea.
>
> please say more when your suspicions become less sneaky?

Here's a sneaky-by-proxy observation and/or question:

Consider a query for "foo.bar.no-chickens.example.net.".

Suppose that "no-chickens.example.net." does not exist (NXDOMAIN and
no descendants).

The authority server for example.net returns "NXDOMAIN", which applies
to the FQDN of the original query (and gets cached there only),
"foo.bar.no-chickens.example.net."

I don't think there's anything in the answer that indicates *where* in
the FQDN, while matching downward, that there was an NXDOMAIN.

For optimization purposes, it would be good (I think) to establish the
"best" place to put an NXDOMAIN.
I.e. Query downward from the zone apex, iteratively, until an NXDOMAIN
is found. QTYPE = NS is benign and/or informative. This should be in
parallel, since it isn't needed for answering the original query.

(While it might be "interesting" to somehow signal this in the first
NXDOMAIN answer, I can't imagine how to do this without breaking lots
of software... like, all of it. E.g. what would happen if the answer
section (also) included the "shorter" NXDOMAIN FQDN, e.g.
"no-chickens.example.net", with RTYPE = ANY instead of matching the
QTYPE?)

Putting the NXDOMAIN as close to the root of the DNS tree as possible
is a clear optimization, since subsequent queries for any sibling of
the first query, wouldn't succeed.

It doesn't change the number of NXDOMAINs required from the current
state, it just moves the NXDOMAIN to a new node.

And, it not only reduces (theoretical) load to the authority server,
it also prevents lots of leaf NXDOMAINs from populating the cache,
below the "real" place that the NXDOMAIN should be.

(It even lowers the impact on the cache, as the "match downwards" will
terminate sooner.)

I'm sure there's a more succinct way to word this, for adding text to
the document.

Brian