[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-bush-dnsop-root-opreq) 00 01 02 03 04 RFC 2870

dnsop                                                         Randy Bush
INTERNET-DRAFT                                                     Verio
draft-ietf-dnsop-root-opreq-04.txt                     Daniel Karrenberg
March 2000                                                      RIPE/NCC
                                                            Mark Kosters
                                                       Network Solutions
                                                           Raymond Plzak
                                                                    SAIC


               Root Name Server Operational Requirements


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

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.  The primary focus of
   this document is to provide guidelines for operation of the root name
   servers.  Other major zone server operators (gTLDs, ccTLDs, major
   zones) may also find it useful.  These guidelines are intended to
   meet the perceived societal needs without overly prescribing
   technical details.







Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 1]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


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









Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 2]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


   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
       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 may allow them to provide
       cached answers.  They also MUST NOT provide secondary service for
       any zones other than the root and root-servers.net zones.  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 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 as advice has been heard
       such as "To avoid having a corruptable cache, make your server a
       stealth secondary for the root zone."  The root servers MAY put
       the root zone up for ftp or other access on one or more less
       critical servers.






Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 3]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


   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 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 Unless there is documentable experience that the local
             power grid is more reliable than the MTBF of a UPS (i.e.
             five to ten years), 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
             the specifications and recommendations of the maufacturer.

       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.2 Network security should be of the level provided for critical
       infrastructure of a major commercial enterprise.








Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 4]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


       3.2.1 The root servers themselves MUST NOT provide services other
             than root name service e.g.  remote internet protocols such
             as http, telnet, rlogin, ftp, etc.  The only login accounts
             permitted should be for the server administrator(s).
             "Root" or "privileged user" access MUST NOT be permitted
             except through an intermediate user account.

             Servers MUST have a secure mechanism for remote
             administrative access and maintenance.  Failures happen;
             given the 24x7 support requirement (per 4.5), there will be
             times when something breaks badly enough that senior
             wizards will have to connect remotely.  Remote logins login
             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.

       3.2.2 Root name servers SHOULD NOT trust other hosts, except
             secondary servers trusting the primary server, for matters
             of authentication, encryption keys, or other access or
             security information.  Trusted key servers for Kerberos,
             IPSEC, etc, MUST be protected with the same prudence as the
             root servers.

       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
             masquerading.  Some LAN switches aren't suitable for
             security purposes, there have been published attacks on
             their filtering.  While these can often be prevented by
             careful configuration, extreme prudence is recommended.

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

       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 cooperative security team communicating with
             all server operators to look for patterns, serious
             attempts, etc.  Servers SHOULD log in GMT to facilitate log
             comparison.



Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 5]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


       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 homed SHOULD have in-
             addr.arpa service.

   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.  Out
             of band security validation of updates MUST be supported.
             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.

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




Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 6]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


       3.3.8 In the advent 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.

       3.3.9 Each root MUST keep global statistics on the amount and
             types of queries received/answered on a daily basis. These
             statistics must 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.

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

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

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

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

5. Acknowledgments

The authors would like to thank Scott Bradner, Robert Elz, Chris
Fletcher, John Klensin, and Steve Bellovin for their constructive
comments.



Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 7]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


6. References

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

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

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

[RFC2181]
     Clarifications to the DNS Specification.  R. Elz, R. Bush.  Jul
     1997.

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

7. Authors' Addresses

   Randy Bush
   Verio, Inc.
   5147 Crystal Springs
   Bainbridge Island, WA US-98110
   +1 206 780 0431
   randy@psg.com

   Daniel Karrenberg
   RIPE Network Coordination Centre (NCC)
   Singel 258
   NL-1016-AB Amsterdam
   Netherlands
   EMail: daniel.karrenberg@ripe.net

   Mark Kosters
   Network Solutions
   505 Huntmar Park Drive
   Herndon, VA 22070-5100
   +1 703 742 0400
   markk@internic.net







Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 8]


INTERNET-DRAFT  Root Name Server Operational Requirements       00.03.04


   Raymond Plzak
   SAIC
   1710 Goodridge Drive
   McLean, Virginia 22102
   +1 703 821 6535
   plzakr@saic.com

8. Specification of Requirements

   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.

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"
   basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS 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.













Bush, Karrenberg, Kosters, Plzak   Expires September 2000        [Page 9]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/