|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Deaggregating for emergency purposes
At 4:28 PM -0700 2002/08/06, David Conrad wrote: Sure."Mildly mis-configured root nameservers"? Care to explain? We know that some root nameservers are in violation of RFC 2870 sections 2.3 and 2.4. They just can't handle anywhere remotely close to: ... three times the measured peak of such requests on the most loaded server in then current normal conditions ... 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". I ran into this problem frequently at Skynet, where they would block all packets coming from 195.238.0.0/20, apparently because this netblock was in Europe and therefore "dangerous". It didn't seem to matter to them that we were also the primary network provider for many NATO groups in Europe, and by their blocking us, they were also blocking NATO. Note that these same idiots had explicit holes cut in their firewalls for 194.78.0.0/16, which was an older netblock also owned by Skynet. This affected the nameservers hosted by the US government & military, as well as at least some of the machines that are registered authoritative nameservers for the .mil and .gov zones. 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". 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. 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. 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 we made appropriate changes so that all root nameservers were in compliance with section 2.5, then this would become a moot point. 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. So far as I know, this document is supposed to describe the way these machines should be operated. 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. Clearly, this is not happening. Therefore, at least some of the root nameservers are at least mildly mis-configured. This really is a lot further than I wanted to go into detail, at least publicly. If you want any further discussion of this matter, you should contact me via private e-mail, or you can come to my invited talk "Domain Name Server Comparison: BIND 8 vs. BIND 9 vs. djbdns vs. ???" that I will be giving at LISA 2002, and where I will be discussing these issues and a whole lot more. -- Brad Knowles, <[email protected]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
|