Root Server Criteria: Operational Criteria for Root Name Servers
The rules for running a bulletproof DNS root name server.
Manning, B. and P. Vixie, "Operational Criteria for Root Name Servers", RFC 2010, DOI 10.17487/RFC2010, October 1996, <https://www.rfc-editor.org/info/rfc2010>.
@misc{rfc2010,
series = {Request for Comments},
number = 2010,
howpublished = {RFC 2010},
publisher = {RFC Editor},
doi = {10.17487/RFC2010},
url = {https://www.rfc-editor.org/info/rfc2010},
author = {B. Manning and P. Vixie},
title = {{Operational Criteria for Root Name Servers}},
pagetotal = 7,
year = 1996,
month = oct,
} RFC text
Contents
Network Working Group B. Manning
Request for Comments: 2010 ISI
Category: Informational P. Vixie
ISC
October 1996
Operational Criteria for Root Name Servers
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document specifies the operational requirements of root name
servers, including host hardware capacities, name server software
revisions, network connectivity, and physical environment.
1 - Rationale and Scope
1.1. Historically, the name servers responsible for the root (".")
zone have also been responsible for all international top-level
domains (iTLD's, for example: COM, EDU, INT, ARPA). These name
servers have been operated by a cadre of highly capable volunteers,
and their administration has been loosely coordinated by the NIC
(first SRI-NIC and now InterNIC). Ultimate responsibility for the
correct operation of these servers and for the content of the DNS
zones they served has always rested with the IANA.
1.2. As described in [Postel96], many new TLD's may be created
shortly. Servers for all new and existing iTLD's will be subject to
the operational requirements given in [Postel96]. The set of servers
for the root (".") zone is likely to become disjoint from the set of
servers for any TLD or group of TLD's, including those maintained by
the InterNIC.
1.3. In spite of the similarities in operational requirements between
the servers for the iTLD's and the servers for the root (".") zone,
they are in fact different server sets with different administrators
and slightly different operational requirements. It is likely that
many contry code tld servers will have even more divergent
operational requirements. That said, the requirements set down in
this document could be successfully applied to any name server
(whether root, top level, or any other level), but may be more
draconian than necessary for servers other than those of the root
(".") zone.
Disclaimer: The selection of name server locations and
administrators, and the procedures for addressing
noncompliance with these stated operational
requirements, are outside the scope of this document.
Definition: For the purpose of this document, the term "zone master"
shall be used to designate the administrative owner of
the content of a zone. This person is expected to have
final responsibility for the selection and correct
operation of all of the zone's servers. For the root
(".") zone, this is the IANA.
2 - Operational Requirements
2.1. Name server software. The zone master shall initially and
periodically choose a name server package to run on all of the zone's
servers. It is expected that the BIND server will be used, at least
initially, and that new versions or other servers will be specified
from time to time.
Rationale: This requirement is based on the wide and free
availability of BIND's source code, and the active
analysis and development it constantly receives from
several members of the IETF.
Name server software upgrades will be specified and scheduled by the
zone master, and must occur on all of a zone's servers within a
specified 96 hour window.
Rationale: In some cases it has proven necessary to "cold start" a
zone's servers in order to clear out oscillating bad
data. By forcing all software upgrades to happen at
about the same time, it will be possible to coordinate
a software change with a zone content change.
2.2. UDP checksums. UDP checksums must be generated when sending
datagrams, and verified when receiving them.
Rationale: Some vendors turn off UDP checksums for performance
reasons, citing the presence of MAC-level frame checks
(CRC, for example) as "strong enough." This has been
a disaster in actual practice.
2.3. Dedicated host. A name server host should have no other
function, and no login accounts other than for system or network
administrators. No other network protocols should be served by a
name server host (e.g., SMTP, NNTP, FTP, et al). If login is
permitted from other than the system console, then the login service
must be by encrypted channel (e.g., Kerberized and encrypted
rlogin/telnet, the secure shell (SSH), or an equivilent).
Rationale: Each additional service performed by a host makes it
less reliable and potentially less secure, as well as
complicating fault isolation procedures. While name
service does not consume very much in the way of system
resources, it is thought best that a host do a few
things well rather than many things poorly.
2.4. Clock synchronization. A name server host should synchronize
its clock using the NTP protocol (currnet version) with
authentication. At least two NTP servers should be used. As an
exception to section 2.3 above, a name server host can be an NTP
server as well.
Rationale: For distributed fault isolation reasons, synchronized
time stamps in system event logs are quite helpful.
NTP is easily spoofed by UDP blast attacks, thus the
requirement for authentication between the name server
host and its NTP servers. A name server host is
allowed to be an NTP server because it has been
observed that a single host running both name service
and stratum 1 NTP is still quite reliable and secure.
2.5. Network interfaces. Name servers must send UDP responses with
an IP source address (and UDP source port number) equal to the IP
destination address (and UDP destination port number) of the request.
Also, a name server might have multiple real interfaces, but only one
will be advertised in the zone's NS RRset and associated glue A RRs.
The advertised address should be that of the "best" interface on the
host, in terms of network performance and reliability to the largest
number of destinations.
Rationale: While not required by [RFC1035], many extant DNS
implementations require the source address and port of
a reply to match the destination address and port to
which the request was sent. The number of advertised
addresses is limited to one (1) so that DNS delegation
responses containing this name server can be as short
as possible.
2.6. Physical environment. A name server host must be located in a
secure space such as a locked computer room or a data center with
restricted access. The power supply should be redundant, using
batteries, generators or some other means to protect against utility
power failures. Network connectivity should be redundant, so that a
single wide area line failure cannot completely isolate the name
server host from the rest of the network.
2.7. Network security. The system and network administrators should
educate themselves about potential threats, and stay current on CERT
bulletins regarding network breakins. The system staff should
periodically audit the name server host's activity logs and be able
to detect breakins during or after the fact.
2.8. Host performance. As of the time of this writing, a name server
must be able to answer 1,200 UDP transactions per second with less
than 5 milliseconds of average latency. Because the network is still
growing at a high rate, the ability to grow to 2,000 transactions per
second and still support a 5 millisecond latency is highly desirable.
Note that this requirement affects both the host and the network
infrastructure to which that host is attached.
2.9. Response time. The administrators responsible for a name server
will respond to e-mail trouble reports within 24 hours. Personnel
issues such as vacations and illness will cause responsibilities to
be delegated and/or reassigned rather than ignored. After hours
telephone numbers must be made available to the zone master for
nonpublished use in emergencies. An escalation contact name, e-mail
address, and telephone number will also be made available to the zone
master in the event of nonresponse through the normal channel.
2.10. Zone transfer access control. The name server shall be
configured so that outbound zone transfers are permitted only to
destinations on the server's local networks, and to whichever
networks the zone master designates for remote debugging purposes.
Rationale: Zone transfers can present a significant load on a name
server, especially if several transfers are started
simultaneously against the same server. There is no
operational reason to allow anyone outside the name
server's and zone's administrators to transfer the
entire zone.
2.11. Zone transfer protocol. DNS AXFR shall be used in preference
to FTP or any other non-DNS transfer protocol. DNS NOTIFY (see
[NOTIFY]) and DNS IXFR (see [IXFR]) shall be supported and enabled
when available.
Rationale: Historically, the common implementations of DNS
(a.k.a., BIND) did not support zone transfer of the
root (".") zone due to programming errors. Thus, FTP
was used. In the future, DNS implementations which do
not support zone transfer of all zones will not be
considered suitable for use as root name servers. The
benefits of [IXFR] and [NOTIFY] should be obvious.
2.12. Recursion shall be disabled for queries.
Rationale: Recursion is a major source of cache pollution, and can
be a major drain on name server performance. An
organization's recursive DNS needs should be served by
some other host than its root name server(s). An
exception is made for missing glue since it's possible
that glue needed for some delegations will not be
within or beneath any zone for which the server is
authoritative. Such glue must be fetched via
recursive lookups to other servers.
2.13. Outages shall be reported. All outages, scheduled or not,
shall be reported to the zone master via e-mail. If an outage is
unscheduled or if an outage is scheduled less than 24 hours in
advance, then an additional notification of the zone master shall be
made via telephone. Extended or repeated outages may beget special
handling by the zone master.
2.14. Inverse name lookups. The PTR RR associated with a server's
primary interface address (that is, the address shown in in the
zone's delegation) shall have its target specified by the zone
master.
Rationale: Since each organization has local control of their
network's PTR RRs, and since it is necessary for the
correct operation of some software that the forward and
reverse lookups have symmetrical results, it is left
up to the zone master to select the name for each
authority server's primary address.
3 - Possible Selection Criteria
3.1. Host population. A server's location on the network should be
such that it has a low IP hop count to a high number of end hosts.
Duplication of service should be avoided, such that any given set of
end hosts needs to have a low IP hop count to at most one authority
server for any given zone.
3.2. Infrastructure diversity. A server's location on the network
should be such that most failures capable of isolating it from a
large number of end hosts are diverse from the failures capable of
similarly isolating other authority servers for the same zone(s).
4 - Security Considerations
See section 2.7.
5 - References
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[Postel96]
Postel, J., "New Registries and the Delegation of International Top
Level Domains", Work in Progress.
[IXFR]
Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
[NOTIFY]
Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
RFC 1996, August 1996.
6 - Acknowledgements
Constructive comments have been received from: Jon Postel, Michael
Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle,
Owen DeLong and other members of the internet community.
7 - Authors' Addresses
Bill Manning
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310 822 1511
EMail: bmanning@isi.edu
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.com
AI ELI5
On this page
§1What Root Servers Do
Historically, root name servers have been operated by volunteers and coordinated by the NIC (Network Information Center). Root servers handle the root ("." ) zone of the DNS and are responsible for all international top-level domains like COM, EDU, INT and ARPA.
The RFC notes that as new top-level domains (TLDs) are created, the set of servers for the root zone may become separate from TLD servers. However, the operational requirements are similar. The RFC is most strict about root zone servers but notes that many of its requirements could apply to any name server.
Root servers are the top of the internet's address book. When you type a web address, your computer asks a root server "where should I look for this?" Millions of computers ask root servers questions every second, so they have to be fast and never crash.
§2Operational Requirements
The RFC establishes 14 detailed operational requirements covering software, networking, security and performance. All root zone servers must run the same software package (initially BIND), and software upgrades must be coordinated so all servers update within a 96-hour window. This allows the zone master (IANA) to coordinate software changes with zone data updates.
UDP checksums must always be enabled on packets, even though some vendors disable them for performance. The RFC notes this has caused serious problems in practice. Name servers must be dedicated hosts with only DNS service and administrative access, using encrypted login channels like SSH.
Root servers must follow strict rules: everyone runs the same software, they update at the same time, checksums are always on to catch errors, and nobody can log in except administrators using secure passwords.
§3Network and Security Configuration
Each server must synchronize its clock using NTP (Network Time Protocol) with authentication, using at least two NTP servers. This helps with troubleshooting and security. Servers must send DNS responses with the same source address and port as the request used, and each server advertises only one primary address in the zone.
The RFC requires redundant physical environment protections: servers must be in locked rooms or data centers with restricted access, redundant power supplies (batteries or generators), and redundant network connections so a single line failure does not isolate the server. System administrators must stay current on security threats, audit logs regularly, and be able to detect breakins.
Each server needs good timekeeping (using multiple clocks synchronized on the network), lives in a locked room with backup power and backup internet connections, and is watched carefully for any signs of trouble.
§4Performance Requirements
As of the time of writing, root servers must handle 1,200 UDP transactions per second with less than 5 milliseconds average latency. The RFC notes that the ability to grow to 2,000 transactions per second while maintaining 5 millisecond latency is highly desirable, as the network was growing rapidly.
These requirements affect both the host hardware and the network infrastructure to which it attaches. Administrators responsible for servers must respond to trouble reports within 24 hours, handle vacations and illness by delegating responsibilities, and provide escalation contacts with telephone numbers for emergencies.
A root server must answer 1,200 questions per second, each in less than 5 milliseconds. That is incredibly fast. The person running it must be available 24/7 or have someone covering for them.
§5Zone Transfers and Delegation
Zone transfers (copying the entire zone database to other servers) are restricted to local networks and networks designated by the zone master for debugging. The RFC notes that zone transfers can significantly load a server, especially if multiple transfers start simultaneously.
The RFC requires use of DNS AXFR for zone transfers (not FTP or other protocols), and when available, DNS NOTIFY and IXFR (incremental zone transfer) should be supported and enabled. Recursive queries must be disabled for regular queries because recursion causes cache pollution and drains performance. The only exception is when the server needs to fetch missing glue records needed for delegations.
Other servers can only copy the zone data from specific trusted computers, not from just anyone. The server answers delegations (telling clients where to look) but does not do web searches on behalf of clients, because that takes too much power.
§6Administration and Monitoring
All outages (scheduled or unscheduled) must be reported to the zone master via email. If an outage is not scheduled in advance or is scheduled less than 24 hours ahead, the zone master must also be notified by telephone. The PTR record (reverse DNS lookup) for each server's primary address is specified by the zone master.
The RFC identifies possible selection criteria for where root servers should be located: servers should have low IP hop count to a large number of end hosts, and the set of servers should be geographically and infrastructurally diverse so that failures affecting one server are unlikely to affect others.
When something goes wrong, the person in charge must be told right away. Administrators talk to each other about the best places to put servers so that different disasters do not take them all down at once.