Comments on "Technical Checks Used for DNS Root Zone Changes"
I'm reading through the document "Technical Checks Used for DNS Root Zone Changes" and have some comments. Overall, it looks like a good start, my comments are mainly about nits and corner cases.... 1. Check #2 - maximum number of name servers of 13: Is the concern here that the list of servers will fit into a UDP reply of 512 bytes? If so, it is possible to construct a hypothetical case in which each name server has a very long FQDN, with none of the servers sharing a common FQDN suffix, thus preventing any DNS name compression. Such a hypothetical list of name servers could, if 13 servers are listed, be more than 3K bytes long! So I suggest that check #2 be modified to be a check that ensures that the actual NS list fits into a 512 byte packet. (Evaluating this might become more complex if servers have both IPv4 and IPv6 addresses.) 2. Check #3 - hostname validity. It would be useful if a character set were specified [e.g. alphanumerics with embedded hyphens]. Are IDN names to be permitted? 3. Check $4, reachability: Are you assuming IPv4 only or is there an IPv6 reachability component to this test? 4. Check #4, reachability: If the TLD is supported by Anycast, it might be useful to have a discussion with the TLD operator about how that TLD monitors, manages and troubleshoots the constellation of anycast servers. There's a lot of knowledge about this topic that I don't think has been recorded into a BCP, and perhaps it would be good to get the folks who have expertise in Anycast TLD servers to write their wisdom down into some sort of BCP. (Perhaps they've already done so?) 4a. Check #4, reachability: Is there any concern about path MTU issues (e.g. they are running their server over a last-hop link that runs PPP with an MTU of 256?) And is there any concern that there is at least an adequate provisioning of the access path or some degree of monitoring that path? (My own sense is that if TLD operators want to shoot themselves in the foot, that they ought to be allowed to do it, with full right of IANA to laugh at 'em and say "we told you so!") 4b. Check #4 again: It is possible that a TLD server has multiple IP interfaces and thus might issue replies using a different IP address than the requestor sent the request to. Should there be a concern about this, particularly if the response might come back via an entirely different path? 4c. Check #4 again: Are you checking TCP access as well as UDP? 4d. Check #4, yet again: What if a server is reachable and such, but is behind a NAT? Is that OK? 5. Sanity. It would be useful to do some sort of run of pathological or complex queries to ensure that the server's are not paper-thin implementations. This is perhaps more of an open-ended topic than something that is appropriate for this effort. 6. It would be useful to apply these tests to the list of root servers itself. 7. These tests ought to be repeated periodically, particularly reachability and some sort of response time + sanity metric. 8. As for your questions at the end, with regard to #1 "Which technical requirements should be mandatory for TLD operators to comply with in order for changes to be accepted in the DNS root": It seems to me that there is a troublesome issue here. Ideally we want people to operate servers that are incredibly robust and accurate and without any bias against certain requesters. But we can imagine TLDs that operate for a somewhat limited clientele. And is it up to IANA to protect that clientele? My own personal sense is that for IANA to start to become protective starts to make IANA consumer protection body - and that's a rough road that I think should be avoided at the outset. So, I'd limit the answer to your question to inquiring (or requiring) of TLD operators whether they will operate in accord with broadly accepted, published internet technical standards and practices. As long as an operator is willing to do that, and as long as the server changes, are in accord with the really good list you have so far, then IANA ought to impart its wisdom - by asking, for instance, whether they really want do do what they are doing - but letting their server change proceed nevertheless. Again, I think overall you've got a reasonable foundation. --karl-- |