On Fri, Mar 11, 2016 at 3:52 PM, Ted Lemon <ted.le...@nominum.com> wrote:
> > It is certainly not the goal. Can you tell exactly where it is > > assumed? Section 2 is supposed to be implementation-neutral. > > Right here: > > When an iterative caching DNS resolver receives a response NXDOMAIN, > it SHOULD store it in its cache and all names and RRsets at or below > that node SHOULD then be considered to be unreachable. Subsequent > queries for such names SHOULD elicit an NXDOMAIN response. > > "At or below" assumes a tree. Just because it isn't explicitly mentioned > doesn't mean that it's not saying that! > Perhaps we can make it explicit that the tree here is conceptual, and not an implementation required data structure? The domain name space is certainly defined in terms of a tree structure. And the cache being a subset of the data in the domain name space -- it is much easier to reason about it in terms of that tree structure and to describe things in those terms (names under/above, descendent names, subtrees etc). In fact, the DNS algorithm description in RFC 1034 clearly states an assumption that the cache is a tree structure, so the precedent is already well established: see section 4.3.2 which says "The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache:" ... Personally, I would be okay with removing the "Implementation Considerations" section. On the question of "SHOULD", I was hoping we'd get rough consensus that this is a good goal, in terms of making the entire DNS ecosystem more efficient - why should resolvers make unnecessary outbound queries for name that don't exist, and why should authoritative servers receive those queries? But I understand the concern that there might be implementation challenges for some. -- Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
