[dns-operations] root server address in whois

[Steve Gibbard]

The list below is a result of a bunch of renumberings over the years, so 
there's no question that how to deal with renumbering has been an issue in 
the past.  Whether it will continue to be an issue is presumably a matter 
of whether all the renumbering that needs to happen has already happened, 
or whether there's more to come.  Past performance is not a guarantee of 
future performance, and all that...

There are a few reasons why a renumbering might be necessary:

* Root server needs to be moved, anycasted, etc., and other things in the
   subnet can't.
* Political issues:  Root server needs independence from organization
   owning IP address space (whether the root server is changing operators
   or not).
* Anything else I'm missing?

Looking at the 13 root server addresses, 12 of them are being announced as 
/24.  The only other top level DNS service happening in those 12 /24s is 
DNS for .ARPA.  It may be that those networks are all sufficiently 
independent already.  The remaining one is D Root, at the University of 
Maryland.  It's still part of a campus /16.  Even if we assume its /24 
could be broken out of that /16, there are 92 hosts that responded to a 
scan of that /24, so the root server does not appear to be alone there. 
So, it looks like moving or anycasting D Root would probably require 
renumbering, but moving any of the others might not at this point.

Ed's data below appears to show that renumbering a root server for 
political control shouldn't now be necessary unless changing who the root 
operator is.

So, that leaves the issue of what happens if one of the root operators 
gets replaced.  From my understanding of the current agreements, that 
would probably require renumbering the roots.  Would the current root 
operators (aside from UMD) be willing to package their root server /24s 
with their root servers, such that if their root server gets transferred 
to another organization, the /24 will go with it, or would that be seen as 
giving up too much control?

-Steve

On Fri, 23 May 2008, Edward Lewis wrote:

> Looking into the ARIN, APNIC, and RIPE whois servers, here are there
> registered organizations for the IPv4 addresses in use for the root
> servers.  In the left column are the letter and the operator
> according to www.root-servers.org.
>
> I took the liberty of abbreviating...
>
> root-servers IP address      whois entries
>
> A VeriSign   198.41.0.4      OrgName: VeriSign Infrastructure & Operations
> B ISI        192.228.79.201  OrgName: B.Root-Server-OPS
> C Cogent     192.33.4.12     OrgName: PSI Inc.
> D UMD        128.8.10.90     OrgName: UMD = University of Maryland
> E NASA ARC   192.203.230.10  OrgName: NASA
> F ISC        192.5.5.241     OrgName: ISC
> G U.S. DOD   192.112.36.4    OrgName: U.S. DoD (NIC)
> H U.S. Army  128.63.2.53     OrgName: Headquarters, USAAISC
> I Autonomica 192.36.148.17   Autonomica
> J VeriSign   192.58.128.30   OrgName: VeriSign Global Registry Services
> K RIPE-NCC   193.0.14.129    RIPE NCC
> L ICANN      199.7.83.42     OrgName: ICANN
> M WIDE Proj  202.12.27.33    The University of Tokyo/Info-Tech Center
>
> A  DEFGHIJKL  = seems normal (operator and registered address holder match)
>  BC         M = not exact matches>
> The "mismatch" in C is (maybe) a matter of Cogent not updating
> (transfering) the registrations from PSI when they acquired/merged.
>
> For M - WIDE is a project at the University of Tokyo.
>
> For B - I don't know how to read that.  The whois entry doesn't mention ISI.
>
> It might be that the L-root incident is a one time event.  (For
> whatever little value that point is.)
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
>
> Never confuse activity with progress.  Activity pays more.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
>