RE: Just got on this thing (perhaps very belatedly) - root server trouble?

@ On Tue, 18 Feb 1997 13:01:06 -0600 (CST), writes:
@ >
@ >In fact, our solution has you *SECONDARYING* ".", which means that in
@ >general, other than the requirement for you to be able to reach a source for
@ >that file on a every-few-days basis (to check the SOA record) you no longer
@ >NEED connectivity to the root domain.
@ >
@ >This is demonstrably superior; you no longer need to make that query for
@ >".", as you already know who is authoritative for all the TLDs under ".".
@ Yiiii... Having everyone secondary "." sounds demonstrably inferior to
@ me. Just think what would happen if every nameserver that is
@ authoritative for a .com domain started secondarying ".". There are
@ approximately 50,000 name servers that are authoritative for .com
@ (according to the .com zone file from the InterNIC). That would mean
@ that the system ROOT-NS.MCS.NET would waste around 5 queries per
@ second because those 50,000 name servers would be trying to check the
@ SOA (at the time that I write this, the eDNS servers list a 3 *hour*
@ refresh interval for the root zone with a 15 *minute* retry
@ interval). Just think what will happen to poor ROOT-NS.MCS.NET when
@ the serial number changes!

There are really two approaches being used. Actually three
if you include the current InterNIC approach of allowing
some TLDs (like .COM, .NET, etc.) to be served from the
Root Name Server.

The two approaches could be called:

  1. Secondarying
  2. TRUE Root

In both approaches you might want to keep in mind that
the objective is to create a Root Name Server (i.e. a
server for servers) as opposed to a standard ISP Name
Server or a TLD Name Server that might be found in
a TLD registry operation.

In the first approach, Secondarying, a Root Name Server
is created by taking a rather standard ISP Name Server
and pulling in (via the secodarying of ".") a rather static
base of information about the location of the TLD Name

There are several benefits to this approach:
  1. People can easily reconfigure an existing
    server to do this as well as other name
  2. The zone transfer features can be used to
    make the update of "." easy from some
    central coordinator.
  3. As Karl has pointed out, you mostly run with
    better performance because you have pulled
    a view of the entire TLD world in and periodically
    get it updated.

The disadvantages are mostly philosophical in that
this type of Root Name Server can end up being a
jack of all trades and a master of too much or none
depending on how you view it. Keep in mind that as
a Root Name Server it still can be used to serve
ISP Name Servers which was the objective.

The second approach (TRUE Root) takes a purists
view of a Root Name Server and only TLD Name
Server referral information is hosted on the machine.
Queries that make their way to this type of server are
easily handled. A query about a .COM domain name
is answered with only information on where the .COM
TLD Name Servers can be found.

There are several benefits to this approach:
  1. The software for this type of name server is
    trivial and can be made to be very
    efficient. The role of this server is
    very bounded and therefore cumbersome
    "named" software with years of whistles
    and bells is not required. We have
    written two versions of "named" for
    such a server and each took little effort.
    One is in Perl and the other is in C.
    The flag-ship version will of course
    be in C+@.
  2. The administration and operations can be
    made to be more robust again because
    the server plays a limited role and
    therefore there is no way that an
    administrator can turn this type of
    server into a complex multi-role
    server as seen today on the legacy
    Root Name Servers.
  3. This type of server can be easily scaled and
    generally has very little load because
    it serves ISP Name Servers and they
    rarely need to relocate the high runner
    TLD Name Servers that do not move
    that often, especially .COM, .NET, etc.

The major disadvantage of this type of server is
the added cost and the fact that it makes the most
sense isolated on a bullet-proof machine. Many ISPs
do not have the luxury of having spare machines to
throw at such problems as an experiment. The
InterNIC of course just deployed 4 such machines
but they have $8,000,000 per month in domain
registrations to help pay for gear.

In my opinion, it is good for NANOG members to
understand all of the ins and out of the DNS and
the various ways to configure name servers. It is
not productive for people to continue to tell people
that only certain individuals can understand what
really amounts to a protocol and a data base and
some rather trivial software to make it all work.

I hope these notes help NANOG members as
well as other people experimenting with the
AlterNIC, Root 64, Root 128, or even the new
IANA TRUE Root Name Servers....:slight_smile: