dnsop                                                        Randy Bush
INTERNET-DRAFT                                                    Verio
draft-bush-dnsop-root-opreq-00.txt                         Mark Kosters
April 1999                                            Network Solutions

               Root Name Server Operational Requirements

    Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

0. Abstract

   As the internet becomes increasingly 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 name servers are seen as a
   crucial part of that technical infrastructure.  This document
   attempts to provide guidelines for operation of the root servers.
   These guidelines are intended to meet the perceived societal needs
   without overly prescribing technical details.

Bush, Kosters             Expires October 1999                  [Page 1]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

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.  Currently, these dozen or so servers are
   provided and operated by a very competent and trusted group of
   volunteers.  This document does not propose to change that, but
   merely to provide formal guidelines so that the community understands
   how and why this is done.

   1.1 The 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 'dot', 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 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 and presumptious of this document to
       specify particular hardware, operating systems, or name serving
       software.  Variations in these areas would actually add overall

Bush, Kosters             Expires October 1999                  [Page 2]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

   2.2 Each server MUST run software which correctly implements the IETF
       standards for the DNS, currently [RFC1035] [RFC2181].  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.

   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
       conectivity to the root server from any internet provider
       delivering connectivity at their own cost.

   2.5 Root name servers MUST disable recursive name lookup, forwarding,
       etc.  They also MUST NOT provide secondary service for any zones
       other than the root zone and root-servers.net.  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. 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 MUST NOT answer AXFR, or other zone transfer,
       queries from clients other than other root servers.

3. Security Considerations

   The servers need both physical and protocol security as well as
   unambiguous authentication of their responses.

   3.1 Physical security MUST be ensured in a manner expected of data
       centers critical to a major enterprise.

Bush, Kosters             Expires October 1999                  [Page 3]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

       3.1.1 Physical access security MUST be provided for the location
             of the servers themselves, whether or not the overall site
             itself is secure.  This may be through traditional locks
             with very restricted key access, electronic locks, etc.

       3.1.2 Power continuity for at least 48 hours MUST be assured,
             whether through on-site batteries, on-site power
             generation, or some combination thereof.  This MUST supply
             the server itself, as well as the infrastructure necessary
             to connect the server to the internet.  There MUST be
             procedures which ensure that power fallback mechanisms and
             supplies are tested no less frequently than once a month.

       3.1.3 Fire detection and/or retardation MUST be provided.

       3.1.4 Provision MUST be made for rapid return to operation after
             an system outage.  This SHOULD involve backup of systems
             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.1.5 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

   3.2 Network security should be of the level provided for critical
       infrastructure of a major commercial enterprise.

       3.2.1 The root servers themselves SHOULD provide no services
             other than root name service.  I.e. they SHOULD NOT support
             other internet remote protocols such as http, telnet,
             rlogin, ftp, etc.  Maintenance access SHOULD be via serial
             console.  Note that other very protected, i.e. strongly
             authenticated and encrypted, access methods MAY be used.

       3.2.2 Root name servers MUST NOT trust other hosts, except
             secondary servers trusting the primary server, for any
             matters of authentication, encryption keys, or other access
             or security information.

       3.2.3 The LAN segment(s) on which a root server is homed MUST NOT
             also home crackable hosts.  I.e. the LAN segments should be
             switched or routed so there is no possibility of

Bush, Kosters             Expires October 1999                  [Page 4]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

       3.2.4 The LAN segment(s) on which a root server is homed SHOULD
             be separately firewalled or packet filtered to discourage
             network access to any port other than those needed for name

       3.2.5 The root servers SHOULD have their clocks synchronized via
             NTP [RFC1305] [RFC2030] or similar mechanisms.  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 central security team communicating with all
             server operators to look for patterns, serious attempts,
             etc.  Servers SHOULD log in GMT to facilitate log

       3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
             protected similarly to the root servers themselves.

   3.3 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 MUST be signed by the IANA in accordance with
             DNSSEC, see [RFC2535] or its replacements.  It is
             understood that DNSSEC is not yet deployable on some common
             platforms, but will be deployed when supported.

       3.3.2 Root servers MUST be DNSSEC-capable so that queries may be
             authenticated by clients with security and authentication
             concerns.  It is understood that DNSSEC is not yet
             deployable on some common platforms, but will be deployed
             when supported.

       3.3.3 Transfer of the root zone between root servers MUST be
             authenticated and be as secure as reasonably possible.
             Servers MUST use DNSSEC to authenticate root zones received
             from other servers.  It is understood that DNSSEC is not
             yet deployable on some common platforms, but will be
             deployed when supported.

       3.3.4 A 'hidden primary' server, which only allows access by the
             authorized secondary root servers, MAY be used.

Bush, Kosters             Expires October 1999                  [Page 5]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

       3.3.5 Root zone updates SHOULD only progress after a number of
             heurstic 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 shall normally be effective no later than
             24 hours from notification of the root server operator.

       3.3.7 A special procedure for emergency updates SHOULD be
             defined.  Udates initiated by the emergency procedure
             SHOULD be made no later than 12 hours after notification.

       3.3.8 Each root MUST keep global statistics on the amount and
             types of queries recieved/answered on a daily basis. These
             stats must be made available to RSSAC and RSSAC sponsored
             researchers to help determine how to better deploy these
             machines more efficiently accross the internet.  Each root
             MAY collect data snapshots to help determine data points
             such as DNS query storms, significant implementation bugs,

4. Communications

   Communications and coordination between root server operators and
   between the operators and the IANA and and ICANN are necessary.

   4.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.
       Preannouncement of planned outages also keeps other operators
       from wasting time wondering about any anomalies.

   4.2 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

   4.3 Statistics as they concern usage rates, loading, and resource
       utilization SHOULD be exchanged between operators, and MUST be
       reported to the IANA for planning and reporting purposes.

5. Acknowledgments

   The authors would like to thank Scott Bradner, Robert Elz, Daniel
   Karrenberg, and John Klensin for their constructive comments.

Bush, Kosters             Expires October 1999                  [Page 6]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

6. References

     Domain names - implementation and specification.  P.V. Mockapetris.
     Nov 1987.

     Network Time Protocol (Version 3) Specification, Implementation.
     David L. Mills.  Mar 1992

     Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
     OSI.  D. Mills.  Oct 1996.

     Clarifications to the DNS Specification.  R. Elz, R. Bush.  Jul

     Domain Name System Security Extensions.  D. Eastlake, 3rd, C. Kauf-
     man.  Mar 1999.

7. Authors' Addresses

   Randy Bush
   5147 Crystal Springs
   Bainbridge Island, WA US-98110
   +1 206 780 0431

   Mark Kosters
   Network Solutions
   505 Huntmar Park Drive
   Herndon, VA 22070-5100
   Telephone: 703-742-0400

8. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

Bush, Kosters             Expires October 1999                  [Page 7]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

9. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to others,
   and derivative works that comment on or otherwise explain it or assist in
   its implementation may be prepared, copied, published and distributed, in
   whole or in part, without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such copies and
   derivative works.  However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as required
   to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an "AS IS"

Bush, Kosters             Expires October 1999                  [Page 8]