DNS Operations Root Server System Advisory Committee
Internet-Draft B.Manning Ed.
Intended status: Informational
Expires: 2012 June 18 27 December 2011
Root Name Server Operational Requirements
draft-rssac-dnsop-rfc2870bis-00
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2012.
IETF Legal Notices
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
"This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
"This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE."
"The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79."
"Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr."
"The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org."
Abstract
This memo replaces RFC 2870. As the Internet has become critical to
the world's social and economic infrastructure, attention has rightly
focused on the correct, safe, reliable, and secure operation of the Internet
infrastructure itself. The root domain and its name servers are a crucial
part of that technical infrastructure. The primary focus of this
document is to provide guidelines for secure, stable, and resilient name
service for the root zone. Additionally it will look into some specifics
for the operation of the name servers. Other operators of critical name
servers--such as those for generic top-level domains (gTLDs), country code
top-level domains (ccTLDs) and other major zones--may also find it useful.
1. Background
The resolution of domain names on the Internet is critically
dependent on the proper, safe and secure operation of the root domain
name servers. The Internet Assigned Numbers Authority (IANA)
publishes the "root hints" file
(http://www.internic.net/zones/named.root), which lists the names and
IP addresses of the thirteen root name servers that are the focus of
this document. These servers are operated by twelve different
organizations, which are listed at http://root-servers.org/. This
document provides formal guidelines for the operation of these root
name servers.
1.1 ICANN has appointed a Root Server System Advisory Committee
(RSSAC) (http://www.icann.org/committees/dns-root/) to give
technical and operational advice to the ICANN board. ICANN and
RSSAC look to the IETF to provide engineering standards.
1.2 The root servers serve the root (".") and ROOT-SERVERS.NET
zones. For legacy reasons, some of the root servers have also
served other important zones, namely ARPA, IN-ADDR.ARPA. In
the future, the root servers may not serve any additional
zones or they may be asked to serve other zones.
1.3 The root servers are neither involved with nor dependent upon
any WHOIS [5] data.
1.4 The domain name system has proven to be sufficiently robust
that that the (presumably temporary) loss of most of the root
server instances 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 top-level domain (TLD)
zones. Providing authentication, validation, and security of these
data and the communications channels they use are protected.
Most of the root operators now provision more than one physical or
logical host to provide root name service. In such configurations,
incoming DNS queries to the IP address providing root name service
are distributed to multiple hosts using a variety of techniques,
including layer-three load balancing devices, equal-cost multipath
routing and anycast routing. (Anycast is discussed further in
Section 4.)
For simplicity, this document uses the term "server" to refer to
however many hosts a root operator provisions to provide root name
service at a single address per address family.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
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 RFC1035 [2], RFC2181
[3] and RFC4035[14]. While there are no accepted, 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 at least ten times the measured
average number of requests on that server in then-current
normal conditions. This capacity is usually expressed in
queries per second. This requirement is intended to ensure
continued operation of root services in the event of extreme
scenarios, such as distributed denial-of-service (DDoS) attacks
and other operational anomalies.
2.4 Each root server should have sufficient connectivity to the
Internet to support the bandwidth needs of the above
requirement. Connectivity to the Internet SHOULD be as diverse
as possible.
Root servers SHOULD have mechanisms in place to accept IP
connectivity to the root server from any Internet provider
delivering connectivity at their own cost.
2.5 Servers MUST provide authoritative responses only from the
zones they serve. The servers MUST disable recursive lookup,
forwarding or any other function that might allow them to
provide cached answers. These restrictions help prevent undue load
on the root servers and reduce the chance of their caching
incorrect data.
2.6 Root servers MUST answer queries from any Internet host, i.e.
root servers may not block root name resolution from any valid
IP address, except in the case of queries causing operational
problems, in which case the blocking SHOULD last only as long
as the problem, and be as specific as reasonably possible.
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers. This
restriction is intended to, among other things, prevent
unnecessary load on the root servers from both well-meaning but
misguided operators configuring their recursive name servers to
secondary the root zone, loading from one of the root servers,
and from malicious denial-of-service attacks. The root servers
MAY distribute the root zone via FTP, HTTP or other access
methods on other less-critical servers.
2.8 Servers MUST generate checksums when sending UDP datagrams and
MUST verify checksums when receiving UDP datagrams containing a
non-zero checksum.
3. Security Considerations
The servers need both physical and protocol security as well as
unambiguous authentication of their responses.
3.1. Physical Security
Physical security MUST be ensured in a manner expected of data
centers critical to a major enterprise.
3.1.1 Whether or not the overall site in which a root server is
located has access control, the specific area in which the
root server is located MUST have positive access control,
i.e. the number of individuals permitted access to the area
MUST be limited, controlled, and recorded. At a minimum,
control measures SHOULD be either mechanical or electronic
locks. Physical security MAY be enhanced by the use of
intrusion detection and motion sensors, multiple serial
access points, security personnel, etc.
3.1.2 Power continuity for at least 24 hours MUST be assured,
whether through on-site batteries, on-site power generation
or some combination thereof. This backup power source MUST
supply the server itself, as well as the infrastructure
necessary to connect the server to the Internet. There MUST
be procedures that ensure the power fallback mechanisms and
supplies are tested no less frequently than the
specifications and recommendations of the manufacturer.
3.1.3 Fire detection and/or retardation MUST be provided.
3.1.4 Provision MUST be made for rapid return to operation after a
system outage. Such provision SHOULD involve backup of
system software and configuration but SHOULD also involve
backup hardware which is pre-configured and ready to take
over operation, which MAY require manual procedures.
3.2. Network Security
Network security should be of the level provided for critical
infrastructure of a major commercial enterprise.
3.2.1 The root servers themselves MUST NOT provide services other
than DNS name service, secure shell, and network time, e.g.
protocols such as HTTP, Telnet, rlogin, FTP, routing daemons,
etc. The only login accounts permitted should
be for the server administrator(s).
Servers MUST have a secure mechanism for remote
administrative access and maintenance. Failures happen;
there will be times when something breaks badly enough that
administrators will need to connect remotely. Remote logins
MUST be protected by a secure means that is strongly
authenticated and encrypted, and sites from which remote
login is allowed MUST be protected and hardened. Remote
logins SHOULD be restricted to a list of discrete IP
addresses or address ranges.
3.2.2 Root name servers SHOULD NOT trust other hosts, except
secondary servers trusting the primary server, for matters of
network time, authentication, encryption keys, or other access
or security information. If a root operator uses Kerberos authentication
to manage access to the root server, then the associated
Kerberos key server MUST be protected with the same prudence
as the root server itself. This applies to all related
services which are trusted in any manner.
3.2.3 The LAN segment on which a root server is located SHOULD NOT
also have other Internet-reachable hosts. Secure monitoring
hosts that passively monitor network traffic to and from the
root server MAY be placed on the same LAN segment. LAN
segments SHOULD be switched or routed so there is no
possibility of masquerading.
3.2.4 The LAN segment(s) on which a root server is located SHOULD
be separately firewalled or packet filtered to prohibit
network access to any port other than those needed for name
service.
3.2.5 The root servers SHOULD have their clocks synchronized via
NTP [6], SNTP [7] or similar mechanisms, in as secure manner
as possible. For this purpose, servers and their associated
firewalls SHOULD allow the root servers to be NTP clients.
Root servers MUST NOT act as NTP peers or servers.
3.2.6 All attempts at intrusion or other compromise SHOULD be
logged, and all such logs from all root servers SHOULD be
analysed by a cooperative security team communicating with
all server operators to look for patterns, serious attempts,
etc. Servers SHOULD log in UTC to facilitate log comparison.
3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
protected similarly to the root servers themselves.
3.2.8 The server SHOULD be protected from attacks based on source
routing. The server MUST NOT rely on address- or name-based
authentication.
3.2.9 The network on which the server is located SHOULD have in-
addr.arpa service.
3.3. Protocol Authentication and Security
Protocol authentication and security are required to ensure that data
presented by the root servers are those created by those authorized
to maintain the root zone data.
3.3.1 The root zone SHOULD be signed by IANA in accordance with
DNSSEC ([8], [9] and [10]).
3.3.2 Once the root zone is DNSSEC-signed, the root servers MUST
be DNSSEC-capable so that queries may be authenticated by
clients with security and authentication concerns.
3.3.3 Transfer of the root zone between root servers MUST be
authenticated and be as secure as reasonably possible. Out
of band security validation of updates MUST be supported.
Servers MUST use TSIG [4] to authenticate root zones
received from other servers.
3.3.4 A "distribution" server, which only allows access by the
authorized secondary root servers, MAY be used.
3.3.5 Root zone updates SHOULD only progress after a number of
heuristic checks designed to detect erroneous updates have
been passed. In case the update fails the tests, human
intervention MUST be requested.
3.3.6 Root zone updates SHOULD normally be effective no later than
one fourth of the time between root zone updates from notification
of the root server operator.
3.3.7 A special procedure for emergency updates SHOULD be defined.
Updates initiated by the emergency procedure SHOULD be made
no later than 12 hours after notification.
3.3.8 In the event of a critical network failure, each root server
MUST have a method to update the root zone data via a medium
which is delivered through an alternative, non-network,
path. In the event that the root server cannot serve
current data, it MUST cease offering DNS service. See also
Paragraph 4.3.
3.3.9 Each root MUST keep global statistics on the amount and
types of queries received/answered on a daily basis. These
statistics SHOULD be made available to RSSAC and RSSAC-
sponsored researchers to help determine how to better deploy
these machines more efficiently across the Internet. Each
root MAY collect data snapshots to help determine data
points such as DNS query storms, significant implementation
bugs, etc.
3.3.10 Each root operator MUST monitor its server to detect operational
problems, such as a host being down, a host not running a
name server, a name server not returning authoritative
answers for the root zone, etc. Servers MAY also be
monitored from an external network. These monitoring
processes SHOULD be automated. If problems are detected,
the appropriate staff MUST be notified to troubleshoot and
remedy the problem.
4. Anycast and Network Considerations
The root zone has been available via shared unicast as described in
RFC 3258 [11] from several of the authoritative root name servers
since 2002. This technique is now commonly referred to as "anycast",
despite its differences from the definition of that term in RFC 1546
[12]. Anycast has proven to be a successful method for increasing
the capacity and geographic distribution of the root server system.
For a root server to offer service successfully using anycast,
several best practices should be followed.
4.1 A root server SHOULD be anycast using IPv4 address space that is a
/24 from legacy allocations. Using any prefix longer than a /20 that
is not from the swamp risks reachability problems because of
filtering by ISPs who won't route such address space. IPv6 address space
SHOULD be at least a /48.
4.2 Each of a root server's anycast instances MAY be sourced
from a consistent origin autonomous system (AS). That is, the
BGP routing announcement for all instances of a given root
server's service address (i.e., the IPv4 address corresponding
to the RDATA of that root name server's NS record) should have
the same origin AS.
4.3 Each anycast instance of a root server MUST withdraw its BGP
routing announcement upon service failure. Each anycast
instance MUST monitor its ability to provide root name service
and withdraw its route if it detects itself unable to provide
service. Such monitoring SHOULD be automatic and not dependent
on a human noticing a service failure.
4.4 Anycast instances SHOULD NOT use the BGP MULTI_EXIT_DISC (MED)
attribute because of possible inter-domain routing (IDR)
oscillation in networks using route reflectors or AS
confederations. Suggested better alternatives are BGP origin
code, altering AS path length (i.e., prepending), adjusting
local preference and communities. Specific route oscillation
scenarios and mitigations are described in detail in RFC 3345
[13].
4.5 Some root operators provision different kinds of anycast
instances for a given root server. Some instances are
designated to be local to particular autonomous systems and
thus advertise their routes with the BGP no-export community
attribute. Other instances are designated "global" and
reachable from anywhere on the Internet; these instances do not
advertise with no-export. In the event of this configuration,
the local and global instances SHOULD NOT advertise routes with
the same prefix length. The global instances SHOULD advertise
a shorter covering prefix.
Failure to advertise a shorter covering prefix from the global
instances can result in unreachability in certain scenarios.
For example, consider AS A with a local root server anycast
instance (i.e., advertising its route with the no-export
attribute) announced as prefix P1. AS A prefers its local
route to P1 over the other paths to P1 it may have received
(corresponding to any global nodes). Now consider AS B that
peers only with AS A. Since the local instance of prefix P1 is
the best path and is marked no-export, AS A does not send this
prefix to AS B. AS B thus has no route to prefix P1 and cannot
reach any instances of this root server.
Instead, consider if the root server operator advertised a
shorter covering prefix P2 for its global instances. In the
scenario above, AS A would send prefix P2 to AS B, making any
of this root server's global instances reachable from AS B.
For IPv4, if the root server prefix is a globally routable /24, and the
operator does not have the necessary adjacent address space to
aggregate and advertise a shorter prefix, the /24 itself SHOULD
be advertised globally and a longer prefix (i.e., /25 or
longer) designated local-only. Such a longer local-only prefix
will not typically be passed across peering boundaries, which
eliminates the need to tag this prefix as no-export.
4.6 There SHOULD NOT be more than three root servers (including
anycast instances) in close physical or topological proximity.
Multiple root servers near each other introduces the
possibility of undesirable fate sharing, since the impact of
any issue that could cause poor performance or an outage is
magnified by the presence of multiple root servers in one
place.
For example, consider an AS hosting multiple root servers that
suffers a catastrophic failure that drastically reduces
performance but does not sever connectivity with the rest of
the Internet. In such a situation, there could be sufficient
connectivity to continue announcing routes but not to reliably
deliver service traffic. If the routes to the root servers
located in this AS are sufficiently attractive, some portion of
the traffic destined for those root servers could be siphoned
off to this AS and then dropped because of insufficient
capacity. Obviously, the more root servers located in the AS,
the more significant and problematic the resulting
unreachability. This scenario is worse for a unicast root
server because the server's entire traffic load is affected:
there are no other anycast instances to handle that server's
query load.
5. Communications
Communications and coordination between root server operators and
between the operators and IANA and ICANN are necessary.
5.1 Planned outages and other down times SHOULD be coordinated
between root server operators to ensure that a significant
number of the root servers are not all down at the same time.
Announcement of planned outages also keeps other operators from
wasting time wondering about any anomalies.
5.2 Root server operators SHOULD coordinate backup timing so that
many servers are not off-line being backed up at the same time.
Backups SHOULD be frequently transferred off site.
5.3 Root server operators SHOULD exchange log files, particularly
as they relate to security, loading, and other significant
events. This MAY be through a central log coordination point,
or MAY be informal.
5.4 Statistics as they concern usage rates, loading, and resource
utilization SHOULD be exchanged between operators, and SHOULD
be reported to IANA for planning and reporting purposes.
5.5 Root name server administrative personnel MUST be available to
provide service 24 hours a day, 7 days per week. On call
personnel MAY be used to provide this service outside of normal
working hours.
6. IANA considerations
There are no new IANA considerations introduced by this memo.
7. Internationalization considerations
There are no new internationalization considerations introduced by
this memo.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[4] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
8.2. Informative References
[5] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004.
[6] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[7] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330, January 2006.
[8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[11] Hardie, T., "Distributing Authoritative Name Servers via Shared
Unicast Addresses", RFC 3258, April 2002.
[12] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
[13] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border
Gateway Protocol (BGP) Persistent Route Oscillation Condition",
RFC 3345, August 2002.
[14] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Protocol
Modifications for the DNS Security Extensions", RFC 4035, March 2005
Authors' Addresses
Root Server System Advisory Committee (RSSAC)
<rssac@icann.org>
Bill Manning, Editor
PO Box 12317
Marina del Rey, CA 90295
USA