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

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.

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

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

> 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
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

--
David Blacka                          <davidb@verisign.com> 
Principal Engineer    Verisign Platform Product Development