rfc2870.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            R. Bush
Request for Comments: 2870                                         Verio
Obsoletes: 2010                                            D. Karrenberg
BCP: 40                                                         RIPE NCC
Category: Best Current Practice                               M. Kosters
                                                       Network Solutions
                                                                R. Plzak
                                                                    SAIC
                                                               June 2000


               Root Name Server Operational Requirements

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

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

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.

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.






Bush, et al.             Best Current Practice                  [Page 1]

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 [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.



Bush, et al.             Best Current Practice                  [Page 2]

RFC 2870       Root Name Server Operational Requirements       June 2000


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

   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



Bush, et al.             Best Current Practice                  [Page 3]

RFC 2870       Root Name Server Operational Requirements       June 2000


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

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



Bush, et al.             Best Current Practice                  [Page 4]

RFC 2870       Root Name Server Operational Requirements       June 2000


              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(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.
              It is best if the LAN segment simply does not have any
              other hosts on it.

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

        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.



Bush, et al.             Best Current Practice                  [Page 5]