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

[Edward Lewis <[e-mail]>]

At 3:45 -0500 2/21/11, Olafur Gudmundsson wrote:
>The chairs have received a request to Last call this draft.
>http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00

Some comments on the document.

# 1. Introduction
#
#   1.1. Iterative caching DNS resolvers can be both compliant and
#   interoperable without also being optimal. Indeed a wide range of
#   optimizations, mechanisms, and outright "tricks" can be employed
#   without affecting correctness or interopability. Such optimizations
#   could be recommended but never required.

The first use of the word "optimal" is a problem.  First, is there 
really a definition by which an "iterative caching" resolver can be 
deemed compliant?  Second, is there any way to measure the degree to 
which it is optimal.

This is a wording nit.  I'd suggest something along this line:

1.1. Iterative caching DNS resolvers can be interoperable with other 
servers yet vary in speed of obtaining an answer, safety in believing 
answers, efficient in use of computing resources, and so on. 
Interoperability is of the utmost importance, but there are some 
useful optimizations that deserve to be documented.

(A rough reworking.  The point is to remove comparative words, like 
"optimal" and "compliant," when there's nothing being compared.)

#   1.3. Three practices are described here:
#
#      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.

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

#      C. Upgrading the credibility of NS RRsets upon delegation events.

A mistake I've made many times: the term is "trustworthiness," not 
credibility.  See RFC 2181, 5.4.1. Ranking data.

# 3. Stopping Downward Cache Search on NXDOMAIN
#
#   3.1. In virtually all existing resolvers, a cached NXDOMAIN is not
#   considered "proof" that there can be no child domains underneath.
#   This is due to an ambiguity in RFC 1034 that failed to distinguish
#   empty nonterminal domain names from nonexistent names.  For DNSSEC,
#   the IETF had to distinguish this case, but the implication on non-
#   DNSSEC resolvers wasn't fully realized.

FWIW, the ambiguity was addressed in RFC 4592 to fix wild cards, not DNSSEC.

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

And I have a sneaking suspicion that this optimization isn't all that 
good of an idea.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at [phone]

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"