> Perhaps we can make it explicit that the tree here is conceptual, and > not an implementation required data structure?
That's not the point. The point is that if the _cache_ is represented as a tree, then you can talk about names being "under" other names; if it's not, then that relationship doesn't exist _in the cache_ even though it _does_ exist in the namespace. > 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). Absolutely right. The problem is that are not just reasoning about it: we are placing a requirement on implementations. > 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. That's up to the chairs to decide, but I certainly don't think we _should_ have consensus on this point without having some sense of whether there is any measurable real-world increase in efficiency. This is easy to implement, as is any proposal; the question is, do we want to slow down _every_ query in order to speed up a very tiny number of queries? A hashed implementation will, for every query, have to check every label in the question, starting from the root, a cached NXDOMAIN record, and almost every time will find nothing. So this is really quite a significant increase in overhead. Whereas the increase in efficiency even for caches that use a tree data structure will be down in the noise. What this might be is a quick speed hack for dealing with PRSD attacks in caches that use trees. So I support _allowing_ this behavior. I just don't support requiring it, and if you do, you should really do some measurements to show that there is a _significant_ speed improvement to justify such a requirement. Otherwise, I think that this change is out of charter, because there's no operational issue that this new _requirement_ addresses, even if the clarification has some value operationally. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
