RFC 2870's applicability (Re: Deaggregating for emergency purposes)

Wed Aug 7 04:19:01 UTC 2002

> >  "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