Olafur Gudmundsson wrote: > There is a new version in the works, expect it late tomorrow (monday) > [...] > I tries to define that resolver treat NOTIMP as long term signal > that resolver should keep track of and not retry.
That's a bad idea, IMO. When the resolver gets a NOTIMP response, it has no way of knowing if it means "meta-type not implemented", "class not implemented", "opcode not implemented", or any number of other "not implemented" conditions. There have been many operational problems caused by resolvers applying cached SERVFAILs or cached indications of non-responsiveness to entire servers, entire names, or excessive periods of time in violation of RFC2308 sections 7.1 and 7.2. We are now at risk of repeating all those mistakes with the caching of NOTIMPs. If we really do want NOTIMP caching in spite of those risks, it should be specified in a separate draft updating RFC2308. Discussing it in the context of ANY will only make things worse by biasing the reader towards assuming that NOTIMP responses are ANY related. Also, ANY queries are relatively rare, and with this draft, should because even rarer, and cheaper for the authoritative server to respond to. Keeping state in the resolver is expensive, and the memory would probably be better spend on other things such as a larger cache. -- Andreas Gustafsson, g...@araneus.fi _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
