rfc2870.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 2870       Root Name Server Operational Requirements       June 2000


        3.3.1 The root zone MUST be signed by the Internet Assigned
              Numbers Authority (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.

        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





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


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

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













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


6. References

   [RFC1035] Mockapetris, P., "Domain names - implementation and
             specification", STD 13, RFC 1035, November 1987.

   [RFC1305] Mills, D., "Network Time Protocol (Version 3)
             Specification, Implementation", RFC 1305, March 1992.

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

   [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
             Specification", RFC 2181, July 1997.

   [RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security
             Extensions", RFC 2535, March 1999.



































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


7. Authors' Addresses

   Randy Bush
   Verio, Inc.
   5147 Crystal Springs
   Bainbridge Island, WA US-98110

   Phone: [phone]
   EMail: [e-mail]


   Daniel Karrenberg
   RIPE Network Coordination Centre (NCC)
   Singel 258
   NL-1016 AB  Amsterdam
   Netherlands

   Phone: [phone]
   EMail: [e-mail]


   Mark Kosters
   Network Solutions
   505 Huntmar Park Drive
   Herndon, VA 22070-5100

   Phone: [phone]
   EMail: [e-mail]


   Raymond Plzak
   SAIC
   1710 Goodridge Drive
   McLean, Virginia 22102
   [phone]

   EMail: [e-mail]

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.








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


9.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















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