ICANN participation

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 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.