Due to its fundamental design assumption of a singly rooted hierarchical namespace, the domain name system (DNS) comprises one of the few (logical) single points of failure within the Internet. More specifically, the root of the Internet namespace is held in 13 geographically distributed root name servers operated by nine independent organizations. In a worst case scenario, loss of all 13 of the root name servers would result in significant disruption to Internet operation as name to address translation (and vice versa) would no longer function.

In preparation for the year 2000 (Y2K), this document describes the research done and steps taken to insure that the operation of the 13 root name servers is not disrupted. The first section of this document describes the root nameserver system, detailing the two major components of that system, the root zone file and the servers which make that file available via the DNS protocol. Next, the administrative services which insure that the root name servers operate correctly will be discussed, followed by a section describing the Y2K testing performed by the root name server operators to date. Finally, open issues (as of the July, 1999) will be presented along with a brief summary.

The data presented in this document was collected in Y2K seminars and the ICANN Root Server System Advisory Committee (RSSAC) meetings in Singapore (during APRICOT '99), INET '99, and several IETF meetings and was discussed and reviewed in online discussion from July 1998 - June 1999.

While not a guarantee of Y2K compliance, this document hopes to demonstrate that the root name server system does not exhibit significant potential for disruption of the Internet at or around the year 2000.

The Root Nameserver System is comprised of three major components, the DNS protocol itself, the root zone file and the root name servers. This section describes these components in some detail.

The DNS protocol only uses relative time, that is, periods of time relative to an arbitrary starting point, for the purposes of timers to insure proper timeout and retry periods. As such, there is no dependence on absolute time, e.g., calendar dates, and the DNS protocol itself has no Y2K issues.

The root of the Internet namespace consists of a single file, the root zone file, which describes the delegations of the top level domains and the associated records necessitated by the DNS protocol to implement those delegations. Currently, this file is maintained by Network Solutions Incorporated of Herndon, Virginia, USA and is made available to the 12 secondary servers from the primary

The root zone file is made available to the root name servers either in-band via the DNS protocol itself (through zone transfers as described in RFC 1034) or out-of-band via the FTP protocol (as described in RFC 952). Given the relatively small size of the root zone, most updates of the root zone file are propagated via zone transfers.

The root zone file itself is composed of 7-bit ASCII characters and contains an SOA record, NS records for each of the top level domain zone delegations, and associated glue records. As a (human) administrative convenience, the SOA serial number is often represented as a date indicating the last modification to the zone file, typically of the form YYYYMMDDXX where YYYY is the year, MM is the month (1-12), DD is the day (1-31), and XX is a sequence number indicating the number of updates within a day. The DNS protocol, however, treats the serial number as an unsigned 32 bit value that is compared using "sequence number arithmetic" (see RFC 1982) such that 0 is larger than 4,294,967,296 thereby allowing serial number wrap-around. As such, the serial number represented as a date as described does not pose a Y2K issue. However, it should be noted that some vendors have shipped versions of the name server with sample configuration files that used YYMMDDXX format for the serial number. Sites that followed that example and naively update their serial numbers in the year 2000 may experience Y2K issues and should consult RFC 1982. As the root zone serial number is consistent with RFC 1982 conventions, this will not affect root name server operations.

The root name servers are the machines that provide access to the root zone file for proper DNS protocol operation. Due to protocol limitations, the number of these machines is currently limited to 13, although efforts are underway to remove this limitation. A conscious effort has been made to diversify the administration of these 13 machines in several areas. As of this writing, the root name servers are operated by the US military, commercial organizations, non-profit organization, Internet service providers, universities, and research institutes with 3 of the 13 servers being operated outside the US, one in London (administered from the Netherlands), one in Japan, and one in Sweden. The complete list of root name servers and their operators can be found in appendix A.

All of the 13 servers have some "hardening" with respect to environmental contingencies. This hardening includes the use of controlled physical access, protection against power grid and cooling failures with UPS protected power with local generator capacity for extended outages, and diverse Internet connectivity in layers 1 through 3. The root servers themselves all use some variant of the Unix operating system, however both the hardware base and the vendors' Unix variants are relatively diverse: of the 13 root servers, there are 7 different hardware platforms running 8 different operating system versions from 5 different vendors.

Given the name servers are geographically distributed and some of the name servers operate on local time (as opposed to GMT), all the root name servers will not encounter significant Y2K events at the same time. It has been estimated, given the amount of traffic each individual root name server receives, that root name service can function given current loads with little to no disruption when 40% of the name servers are offline, thus should a significant Y2K issue be found, the diversity of time zones will permit the root name server system to continue operation while the issue is resolved.

Administratively, the root name server operators have all taken steps to minimize susceptibility to Y2K disruptions. Each root name server site keeps backup copies of zone files, thus should a disruption occur in the generation or transmission of the root zone file, the root servers can make use of backup copies until the situation is resolved. In addition, each root name server operator has contact information (in hard copy) for all other operators, thus should an issue be detected, the root name server operators can get in contact with each other (assuming the telephone system is operational). As all root name servers run recent versions of BIND, expertise in troubleshooting and resolving name server issues can be shared.

With respect to the administration of the root name server hardware itself, each root name server has redundant hardware available to it. In some cases, the hardware is in the form of a hot spare, able to be made operational with human intervention. In other cases, the hardware is operated as a live spare able to take on the full load of serving the root zone without human intervention should their be a hardware failure. However, should disruption occur, each root name server operator has multi-level system administration personnel and support with internally defined escalation procedures.

In order to increase confidence levels that Y2K issues will not negatively impact the operation of the root name serves, the root name server operators have undertaken testing of various aspects of the root name server system. As previously mentioned, each root name server run on some variant of Unix and the root name servers have been in contact with the vendors/authors of those Unix variants to ascertain the level of Y2K testing performed for the operating system as a whole.

In addition, core application software running on all of the root name servers has been reviewed for Y2K compliance. These applications are BIND, NTP, Syslog, and SSH and all known Y2K issues with these applications have been addressed. Perhaps the most critical of these applications in the context of root name service, BIND, has been subject to extensive Y2K review by many third parties including the US Military and has not been found to have any Y2K issues. NTP provides clock synchronization, insuring machine clocks are quite closely aligned with standard time sources. While no Y2K issues have been detected within NTP, should there exist any, the operation of the name server would not be affected as BIND makes no use of the system clock itself. With respect to syslog, some Y2K issues are known to exist, particularly in older versions of this application. However, Syslog is only used to log system messages, thus no direct impact would be made on name server operation albeit the log files for a machine with a non-Y2K compliant Syslog may be confusing to read (e.g., the year 2000 may be represented as 19100 as 99 is incremented by 1). SSH provides remote access to the root name server. While no Y2K non-compliance issues are known with SSH, failure of this application simply means remote access to the root name server is impacted, there would be no impact on the operation of the name server software itself.

With respect to the Y2K event itself, testing for Y2K clock rollover, leap year, and GPS failure have been done on isolated root name server systems with no operational impact noted. In addition, several of the root name server operators have their own, enterprise-wide Y2K compliance programs and are insuring all systems within their enterprise will not be affected by Y2K related events.

Finally, contact information, including telephone (landline and mobile where available), fax, and email for the root name servers is periodically verified to insure that the information is correct and up to date.

This section discusses some open issues made apparent in the review of Y2K related considerations by the root name server operators. While not indicative of specific problems, they do indicate areas that may warrant future study.

As is well known, the most significant open issue is the use of 32 bit counters for time on Unix operating systems. As the Unix epoch begins Jan 1, 1970, there will exist an issue in the year 2038. Discussion of the Y2.038K issue is beyond the scope of this document. Also related to the use of Unix, some system or library calls are known to have Y2K issues, in particular dates written in syslog records. While these system or library calls may make reading logs a bit complicated, they should not have any direct impact on the operation of critical software.

Finally, the root name servers exist in an environment that may be subject to Y2K difficulties. In particular, power grid failures, telecom infrastructure failure, cooling system failures, security system failures, etc. are all areas in which Y2K concerns have been raised. The root name server operators have taken what steps they can to minimize the impact of such failures, however most of these systems are beyond the control or influence of the root name server operators, thus problems may yet exist.

The root name server system, comprised of the DNS protocol itself, the root zone file, and the root name servers, has been reviewed for Y2K related issues and testing for various Y2K related events, including Y2K clock rollover, leap year, and GPS failure, has been done with no operational impact noted.

Operation of the root name server system is highly diversified and where common elements exist, significant testing has been done to ferret out any Y2K related issues and to resolve them.

This document was derived from a presentation prepared by Bill Manning of USC-ISI for the ICANN RSSAC and includes data collected by Akira Kato of Tokyo University. Evi Nemeth provided helpful comments and wordsmithing.