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

["W.C.A. Wijngaards" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I read (and implemented) this draft (as config options) some time ago.
They are pretty good ideas, but I have some concerns, below.

On 02/21/2011 08:51 PM, Brian Dickson wrote:
> On Mon, Feb 21, 2011 at 2:58 PM, David Blacka <[e-mail]> wrote:
>>> Background: The draft contains three recommendation on how resolvers operate,
>>>    A. Re-validating a delegation when a parent NS RRset TTL expires.
>>>    B. Stopping a downward cache search when an NXDOMAIN is encountered.
>>>    C. Upgrading the credibility of NS RRsets upon delegation event.
>>>
>> (A) is (I think) trying to solve issues caused by "cache pinning" when moving a zone from one set of nameservers to another.  Actually, it goes further than that (if I understand the draft correctly, which I very well may not) by effectively removing entire delegation chains when the ancestor NS RRset expires.  So, e.g., every time the com NS RRset expires, all delegations below it effectively expire.  I have no idea what problem this overall behavior solves, although I suspect that it defeats a great deal of the value of a cache.
> 
> 
> My read on the draft, and I'm reasonably confident it's what the
> author intended, is that "stale" delegations be "refreshed" (or have a
> "refresh" attempted) before they are used.
> It is analogous to the "refresh" between master and slave authority
> servers for a given zone, e.g. verifying the SOA SN if the "refresh"
> timer fires off.

Yes, I appreciate the utility of picking up new delegation changes
once-in-a-while.

> And, basically, the "refresh" is to make sure the delegation
> (non-authoritative) NS records are "reasonably consistent" with what
> was already cached, and if so, re-establishes the validity, re-sets
> the TTL, and re-populates the NS set if some changes have occurred.
> No expiration occurs, unless both (a) the TTL expires, and (b) the new
> delegation NS RRSET has nothing in common with the cached RRset - in
> which case, the child side and all descendants MUST be discarded.

I think discarding the tree below is cache-management strategy, and was
not the aim of point A.  The usual DNS time shifted coherency is the goal.

>> (B) is about having resolvers actually believe NXDOMAIN responses.  While I think it might be nice if we could trust that NXDOMAIN actually meant that the name didn't exist, I don't see how this improves the "resiliency" or "robustness" of the *resolver*.
> 
> This is one place where I think some updates to the ID need to be done.
> 
> Basically, we need a reference (i.e. to RFCs in standard I-D style)
> to the changes to the standard(s) that differentiate 1034's "Name
> Error" from the two cases we now know about, "NXDOMAIN", and "empty
> non-terminal" (a node with no RRs itself, which has descendants,
> inside a zone).
> 
> If I understand it, things should now work as follows:
> - if an empty non-terminal matches a QNAME, the *answer* should be
> empty, but there should *not* be any error code.
> - if no domain exists (and that means neither  the domain nor any
> children exist), there *should* be an error code of NXDOMAIN

Yes this problem exists.

> And, given the logic immediate above, this means that NXDOMAIN can and
> should be cached (if and only if the above applies), and when an
> NXDOMAIN is cached, children of that node get discarded, and
> subsequent queries to the *resolver* below that NXDOMAIN can
> themselves be guaranteed to be NXDOMAINed, and there is no need to
> send the query to the authority server for the given zone.
> 
> But, this should be clarified in the text of the draft.
> 
> I agree that it is a suitable optimization, and as I understand it,
> correct behavior.

I do not think you could enable this by default today, because very old
software might still have bugs in handling empty nonterminals and send
NXDOMAINs for them.

>> (C) is about working around delegation scenarios that favor parent-side delegation information by instructing the resolver to directly query the child nameservers for NS records.  I don't know what actual problem this is attempting to solve.

Sounds like an idea of a Dutch guy.  Disabled by default ...

>>> 2. Is the draft clear in its message?  If not, please suggest improvements.
>>
>> It is entirely unclear to me what problems the various proposals are actually trying to solve.

Yes, that is not a part of the text.  Perhaps a light-weight fix can be
applied.

>>> 3. After (if any) editing fixes is this draft ready for WG Last Call?

That would be a little too quick.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1jkHkACgkQkDLqNwOhpPg29gCgnGOIlcuwoKhv+MslQ+09Dn8/
Y+IAoKmaCRUjQBZkwoRO7R+t5CbZ3s27
=9HrR
-----END PGP SIGNATURE-----