"Mildly mis-configured root nameservers"?
Care to explain?
We know that some root nameservers are in violation of RFC 2870 ...
RFC 2870 had a lot of cooks, and the end result is somewhat descriptive of TLD servers but is anywhere from mildly to wildly wrong with respect to the root servers.
... We also know that some of the root nameservers are in violation of section 2.6 -- for example, I believe that the networks hosting the nameservers operated by the US government and the US military routinely block all packets from certain netblocks which they believe to be "subversive".
There's no way to change this, really, and one of the ways to not change it would be to write an RFC. USGov has its own way of doing things. I don't expect anybody to tell them they have to give up their root servers as a result. (Except maybe Karl or Jim, I guess.)
... Section 2.5 is outright blatantly violated, since there are definitely some root nameservers that are listed as being authoritative for zones other than "." and "root-servers.net".
We cooperate with the spirit of that provision (which it shares with RFC 2010, by the way) by not adding any new zones to any server which is also authoritative for ".". The current list, as far as I know, is: A: . arpa in-addr.arpa gov edu mil root-servers.net B: . arpa in-addr.arpa gov edu mil [root-servers.net] C: . arpa in-addr.arpa gov edu [root-servers.net] D: . arpa in-addr.arpa gov edu [root-servers.net] E: . arpa in-addr.arpa gov edu mil [root-servers.net] F: . arpa in-addr.arpa gov edu root-servers.net G: . arpa in-addr.arpa gov edu mil [root-servers.net] H: . arpa in-addr.arpa gov edu mil [root-servers.net] I: . arpa in-addr.arpa gov edu [root-servers.net] J: . root-servers.net K: . root-servers.net L: . [root-servers.net] M: . [root-servers.net] Speaking only for F, I'll say that ISC will never ask ARPA, IN-ADDR.ARPA, GOV, or EDU to seek elsewhere for their name service. I'd like to say that they're "grandfathered" but what I really mean is they're "Postel'd". (The []'s indicate stealth slave status.)
... IMO, section 2.7 is a bigger issue. I think you can reasonably argue that the root zone itself should (or could) be exposed to zone transfers, in part because it is relatively easy to create (the gTLDs are known, and you can easily programmatically find the ccTLDs). Moreover, I don't think there's much danger in exposing the root zone.
Not only that. F allows transfer of every zone it handles, and always has, other than a brief period when COM, NET, and ORG were restricted due to a request from VeriSign. (VeriSign now serves COM, NET, and ORG for itself.) If the operators of the zones F serves asked that they be restricted from zone transfer, we would of course comply. But RFC 2870 is flat wrong in its attempts to legislate F's ACL -- only the zone operators can do that.
... However, if it's going to be available for AXFR, then it should be available at all root nameservers, and not just a selected few. You can also argue that .arpa falls into this same category.
You ought to take that up with the zone operator, who at this moment appears for all intents and purposes to be US-DoC, or failing that, talk to IANA.
Contrariwise, I believe that the Domain Managers for .gov, .mil and .edu would probably violently disagree with this point, and their zones should not be exposed for zone transfers.
If so then they sure havn't told F, even after many years of full openness.
... IMO, sections 3.2.1, 3.2.3, and 3.2.4 are highly questionable with regard to certain machines. My testing is not yet complete, so I won't say much more with regards to these sections.
Some of the hosts from whom I have recently dropped more than 50 packets due to their exceeding a 100Kbit/sec ingress quota are shown below. Presumably yours is among them if you're still flooding me with queries to find out how fast I'll answer them. 124 ip 210.220.163.80/0 0.0.0.0/0 209 12466 0 0 126 313 ip 216.127.34.163/0 0.0.0.0/0 321 18939 0 0 120 64 ip 210.220.163.78/0 0.0.0.0/0 157 9385 0 0 88 499 ip 209.67.50.88/0 0.0.0.0/0 141 8987 0 0 84 1011 ip 144.137.113.189/0 0.0.0.0/0 119 6854 0 0 84 203 ip 216.175.216.50/0 0.0.0.0/0 139 8865 2 129 81 916 ip 209.150.65.1/0 0.0.0.0/0 160 9344 2 120 80 408 ip 218.44.147.218/0 0.0.0.0/0 130 7800 0 0 67 188 ip 65.192.24.190/0 0.0.0.0/0 121 8712 0 0 64 Evi gave a *wonderful* talk at NANOG a year or so back in which she explored the many bad flows seen on F. Anyone who runs benchmarks against root servers would be a "bad flow". So it's no wonder that your testing isn't complete :-).
So far as I know, this document is supposed to describe the way these machines should be operated.
That's one way to look at it. I think it's got more to do with TLD servers, and is advisory. With 250+ ccTLD's, there are a lot of new operators, and this document seems to have sought to advise that group.
Without any information to the contrary, I have to assume that the root server operators were in general agreement that they would follow these principles.
Allow me to present information to the contrary. I co-authored RFC 2010, but I had no part in RFC 2870 and in fact had not even read it until well after it was published. I consider it inadequate and inaccurate for root service, while nonetheless acknowledging its applicability toward some ccTLD servers.
Clearly, this is not happening. Therefore, at least some of the root nameservers are at least mildly mis-configured.
Clearly, you're way ahead of yourself. -- Paul Vixie