RFC 2870 (rfc2870) - Page 2 of 10
Root Name Server Operational Requirements
Alternative Format: Original Text Document
RFC 2870 Root Name Server Operational Requirements June 2000
1.1 The Internet Corporation for Assigned Names and Numbers (ICANN)
has become responsible for the operation of the root servers.
The ICANN has appointed a Root Server System Advisory Committee
(RSSAC) to give technical and operational advice to the ICANN
board. The ICANN and the RSSAC look to the IETF to provide
engineering standards.
1.2 The root servers serve the root, aka ".", zone. Although today
some of the root servers also serve some TLDs (top level domains)
such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as
INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE
for Sweden), this is likely to change (see 2.5).
1.3 The root servers are neither involved with nor dependent upon the
'whois' data.
1.4 The domain name system has proven to be sufficiently robust that
we are confident that the, presumably temporary, loss of most of
the root servers should not significantly affect operation of the
internet.
1.5 Experience has shown that the internet is quite vulnerable to
incorrect data in the root zone or TLDs. Hence authentication,
validation, and security of these data are of great concern.
2. The Servers Themselves
The following are requirements for the technical details of the root
servers themselves:
2.1 It would be short-sighted of this document to specify particular
hardware, operating systems, or name serving software.
Variations in these areas would actually add overall robustness.
2.2 Each server MUST run software which correctly implements the IETF
standards for the DNS, currently [RFC 1035] [RFC 2181]. While
there are no formal test suites for standards compliance, the
maintainers of software used on root servers are expected to take
all reasonable actions to conform to the IETF's then current
documented expectations.
2.3 At any time, each server MUST be able to handle a load of
requests for root data which is three times the measured peak of
such requests on the most loaded server in then current normal
conditions. This is usually expressed in requests per second.
This is intended to ensure continued operation of root services
should two thirds of the servers be taken out of operation,
whether by intent, accident, or malice.
Bush, et al. Best Current Practice