## A Common Operational Problem in DNS Servers - Failure To Respond. ## draft-ietf-dnsop-no-response-issue-03
I have a lot of high-level concerns with this document. ##1. Introduction ## ## The DNS [RFC1034], [RFC1035] is a query / response protocol. Failure ## to respond to queries or to respond incorrectly causes both immediate ## operational problems and long term problems with protocol ## development. While the latter is true, operationally the DNS is not strictly query - response. It's more like "query - if I want to respond". I was "enlightened" during a project 10-15 years ago when I realized that some DNS implementations choose silence when deciding how to respond. Based on this premise, the prescriptive language in sections 3 and 10 are very problematic in my opinion. ##2. Common queries kinds that result in non-responses. This section is not built on data or a document study, making it seem flimsy, to wit: ## Some servers fail to respond to ... This doesn't establish a need to react to the situation. "Some" might be one operator's code, etc. ##3. Remediating This section steers far from the purpose of defining interoperability of the protocol. This section gets too specific regarding the current business of DNS registration (registry and registrars) for technical needs. I don't think this section belongs in an IETF document. ##7. Response Code Selection ## ## NOERROR (no data) are the expected response codes. A server is not ## supposed to serve a zone which contains unsupported types ([RFC1034]) ## so the only thing left is return if the QNAME exists or not. NOTIMP But we have "Handling of Unknown DNS Resource Record (RR) Types" which contradicts that "not supposed to". This is the closest I'll come to a "nit." ##10. IANA Considerations ## ## IANA / ICANN needs to consider what tests, if any, from above that it ## should add to the zone maintenance procedures for zones under its ## control including pre-delegation checks. Otherwise this document has ## no actions for IANA. There is a lot wrong with that paragraph. (As in, I'm not sure where to start.) The IANA functions operator manages according to community defined processes, there is no internal consideration of what to test. Further, only delegations from the root zone are considered, not anything lower in the tree. (I.e., most of the issues observed wouldn't be touched.) This document would be more useful if it clarified the use of RCODEs in the face of queries described here, in the vein of "Negative Caching of DNS Queries (DNS NCACHE)". We lack any document describing the circumstances in which RCODE values are returned and what the appropriate reaction to them is. As the document stands, it is unspecific regarding issues, particularly the operational scale, and ventures into policy instead of technical directions regarding operations. As an afterthought - Perhaps a whitepaper (non-IETF) can be produced to describe testing methodology and results observed would be an avenue to publicize the situation seen here.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
