@ -----BEGIN PGP SIGNED MESSAGE-----
@ On Tue, 18 Feb 1997 13:01:06 -0600 (CST), email@example.com 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:
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
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....