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

[Brian Dickson <[e-mail]>]

I have read the draft, and also David's comments, and have comments of
my own in-line below.

Briefly, however, I'd say:
- the things in the draft are all good ideas
- the draft is good, should be adopted, requires only a small amount
of work, and once that is done, is probably fine for WGLC.
- s few clarifications will go a long way to addressing both David's
issues, and making the document useful
- all of the above are "IMIHO"

See below for in-line comments.

Brian

On Mon, Feb 21, 2011 at 2:58 PM, David Blacka <[e-mail]> wrote:
>
> On Feb 21, 2011, at 3:45 AM, Olafur Gudmundsson wrote:
>
>>
>> The chairs have received a request to Last call this draft.
>> http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00
>>
>> This draft is clearly in scope of the Working Group.
>>
>> As there has not been much discussion on this draft the chairs are
>> not ready at this point to start a Last Call but would like to get a sense of the working group participants' feelings on the draft.
>
> I was not aware of this draft's existence until now, but I just read it.
>
>>
>> The draft is aimed at BCP status; thus there is no RFC2119 language in the draft.
>>
>> 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.
>>
>> All of these have been suggested in various forms over the years.
>>
>> Following opinions are sought:
>> 1. Are the suggestions in the draft something people think is a good
>>   idea?
>
> I'm unsure, although I'm leaning toward thinking that they are not good ideas.
>
> (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.

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.

It actually is better than blindly discarding the children, which I
think might have to happen currently. Only if the delegation points
elsewhere, when the TTL expires, do the children need to be discarded.

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

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.

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

I *believe* it is working around situations where different
implementations of authority server have interpreted existing RFCs
differently, and arguably both interpretations are technically
correct.
And, that it is also always preferable to have the most authoritative
(correct) NS data in the cache, even if it wasn't returned in the
authority section of the authority server.
I believe this is particularly relevant in order to also do (A) above.

It would be helpful, perhaps, to differentiate the behavior of a
resolver, when it does have, and when it does not have, the apex NS
RRSET, and when that might trigger different behavior to a client of
the resolver.
(E.g. when the resolver path includes things like: "client ->
recursive resolver -> bigger recursive resolver -> authority
server(s)".)

>> 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.
>
>> 3. After (if any) editing fixes is this draft ready for WG Last Call?
>
> Not in my opinion.  I don't think the ideas are clearly BCPs.
>
>>
>>    Olafur and Andrew
>> _______________________________________________
>> dnsext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsext
>
> --
> David Blacka                          <[e-mail]>
> Principal Engineer    Verisign Platform Product Development
>
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>