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

Tue Feb 18 22:17:03 UTC 1997

On Tuesday, February 18, 1997 3:09 PM, Jeffrey C. Ollie[SMTP:jeff at ollie.clive.ia.us] wrote:
@ -----BEGIN PGP SIGNED MESSAGE-----
@ 
@ On Tue, 18 Feb 1997 13:01:06 -0600 (CST), karl at mcs.net 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
Servers.

There are several benefits to this approach:
	1. People can easily reconfigure an existing
		server to do this as well as other name
		services.
	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+ at .
	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....:-)

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)