>>> 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.
>> It is a SHOULD not a MUST. Having a existing cache entry is a reasonable >> exception to the SHOULD. >The second SHOULD in the quote above seems to be explicitly saying that >those cache entries should be made unreachable, so I think it would be >unreasonable to interpret the SHOULD as meaning "don't implement this >requirement". >(Really, I think if a spec uses words like SHOULD, it ought to include a >discussion of when it is reasonable not to implement that requirement and >what are the consequences of not doing so.) >I think the spec needs to make an explicit distinction between conforming >behaviour for names already in the cache and names not in the cache. The issue here is that there is no interoperability problem that these SHOULDs are addressing, so you can't have a discussion about the exceptions. What this normative requirement is doing is giving explicit implementation advice, not saying what must be done for correct operation of the protocol. That's the problem. What this document should be doing is telling implementations that they are permitted to assume that names under an NXDOMAIN are also NXDOMAIN. The way to do that is with a MAY, not a SHOULD: Iterative caching resolvers MAY assume upon receiving an NXDOMAIN that all names below the name that elicited the NXDOMAIN response in the DNS hierarchy are also nonexistent, for the duration of the lifetime of the NXDOMAIN response. All the rest of this verbiage is in the document essentially because the authors want to explicitly recommend one implementation strategy over another, not because there is actually any normative requirement. If you just state this clarification as I've suggested , it can be a one page draft, and accomplish exactly what is needed. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
