> 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! > If the cache is a hash, the requirement at the beginning of section > two is actually expensive to implement, > This is exactly what section 5 says (last paragraph). Yes, it does say that, and I agree with what it says--I'm just proposing that the document be changed so that it's not necessary to say that. > I disagree here. This is (if approved) a normative document. It does > place "new" requirments. (I write "new" between quotes because > resolvers with NXDOMAIN cut behavior are, IMHO, legal even today, the > original RFCs are not perfectly clear.) This is what I'm saying: it shouldn't be making requirements on the resolver. It should just clarify that if you get an NXDOMAIN for name K, any name that is a subdomain of K can be assumed also to return an NXDOMAIN. > It is a change in the behaviour of the majority of resolvers, but not > a change in the protocol. So, yes, it is "to address operational > issues with the DNS protocols by extending or performing protocol > maintenance on them" Any protocol change that changes the operation of the DNS in any way can be justified on this basis. If that is what this section of the charter means, then we can make nearly any change to the protocol that we want and still be in charter. I think more reasonably what this section of the charter means is that you can update the protocol to address an operational problem. But this draft isn't really adressing an operational problem: your motivation for doing this is to support DPRIVE, not because anybody is going to notice a reduction in the number of queries even if this is widely implemented. It's not even addressing a serious problem in DPRIVE. If it's just to address a subset of possible PRSD attacks, the protocol clarification without the requirement is already sufficient, because the clarification adds a tool for implementors who are motivated to use this technique to address that problem, but is not required of implementors who want to approach it in a different way. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
