Deaggregating for emergency purposes

Wed Aug 7 00:30:03 UTC 2002

At 4:28 PM -0700 2002/08/06, David Conrad wrote:

>  "Mildly mis-configured root nameservers"?
>
>  Care to explain?

	Sure.

	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, <brad.knowles at skynet.be>

"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(+++)