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