Setting up a Root name server

[David R. Conrad]

Hi,

>    If one is indeed a very large organisation, changes to
>    make this possible/easier could in theory be implemented
>    (the code _is_ available:), or the ISC could become
>    convinced that it was technically worth doing.  

As with any development undertaken by ISC, an organization willing to
pay for such development would greatly increase the chances of
implementation (assuming it is technically worthwhile).

> 2) Since you, Chris, represent a reasonably sized interest,
>    why not pursue partnering with the Internic to have a
>    real honest-to-god root server set up on your network
>    (presumably at a peering point, so as not have to
>    have external net traffic back-hauled through too much
>    of your "internal" network).  

InterNIC is not the organization that determines where root nameservers
go.  That determination is currently being debated (most root server
operators say "IANA" and (arguably) by extenstion, ICANN.  NSI says
(with valid reason) "Dept. of Commerce").  However I suspect it is safe
to say it is unlikely another root nameserver will be allocated to the
US.  NSI (which is the company which has the cooperative agreement with
the Dept. of Commerce to run InterNIC) does have some say in where the
gTLD (.COM, .NET, .ORG) servers are located, but even that is a bit
controversial right now.

> Since there are 12 named

13.

>    root servers (probably scattered clusters of machines,
>    as opposed to 12 monolithic boxes, if I had to guess:),

You'd guess wrong.  Some of the root nameservers are multiple machines
arranged in a way to have hot spares and near instant failover
(f.root-servers.net is actually 2 2 GB RAM alphas with a cisco box doing
CEF between 'em so if one fails the other picks up the full load), but
all 13 are in essence single machines.

>         I should think that you would then have all the
>         data required to determine whether the cash and
>         time required to buy a n-way SMP, 2Gb RAM, x^y
>         Gb HDD, and configure said beast is worth it.

BINDv8 can only make use of a single processor (BINDv9 has gone to great
lengths to fix this).  Also, you don't need much disk space.  BIND still
keeps everything in RAM (BINDv9 separates the protocol engine from the
database back end so it will be easier to implement non-RAM backends). 
You don't want to swap.  Trust me.

Rgds,
-drc

P.S. BINDv9 is scheduled for public beta in January, final release
around the end of April, 2000.