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




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
1. 出身背景

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 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.1 互联网名称和号码分配公司(ICANN)负责根服务器的运行。ICANN已任命一个根服务器系统咨询委员会(RSSAC),向ICANN董事会提供技术和运营建议。ICANN和RSSAC希望IETF提供工程标准。

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.2 根服务器服务于根区域,即“.”。尽管今天一些根服务器还服务于一些TLD(顶级域),如GTLD(COM、NET、ORG等)、基础设施TLD(如INT和IN-ADDR.ARPA)和一些CCTLD(国家代码TLD,如瑞典SE),但这可能会发生变化(见2.5)。

1.3 The root servers are neither involved with nor dependent upon the 'whois' data.

1.3 根服务器既不涉及也不依赖“whois”数据。

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.4 域名系统已经被证明是足够强大的,因此我们相信,大多数根服务器的丢失(可能是暂时的)不会对互联网的运行产生重大影响。

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.

1.5 经验表明,互联网很容易受到根区域或TLD中不正确数据的攻击。因此,这些数据的身份验证、验证和安全性备受关注。

2. The Servers Themselves
2. 服务器本身

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.1 在本文档中指定特定的硬件、操作系统或名称服务软件是短视的。这些方面的变化实际上会增加整体稳健性。

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.2 每台服务器必须运行正确执行IETF DNS标准的软件,当前为[RFC1035][RFC2181]。虽然没有标准符合性的正式测试套件,但根服务器上使用的软件的维护人员应采取所有合理措施,以符合IETF当时记录的预期。

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.3 在任何时候,每个服务器都必须能够处理根数据的请求负载,该负载是当前正常情况下负载最大的服务器上此类请求峰值的三倍。这通常以每秒请求数表示。这是为了确保根服务在三分之二的服务器因故意、意外或恶意而停止运行时继续运行。

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.

2.4 每个根服务器应具有足够的internet连接能力,以支持上述要求的带宽需求。与互联网的连接应尽可能多样化。

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 zones. These restrictions help prevent undue load on the root servers and reduce the chance of their caching incorrect data.

2.5 服务器必须仅从其服务的区域提供权威响应。服务器必须禁用递归查找、转发或任何其他允许其提供缓存答案的功能。它们还不得为根服务器和根服务器.net区域以外的任何区域提供辅助服务。这些限制有助于防止根服务器上的过度负载,并减少其缓存错误数据的机会。

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.6 根服务器必须回答来自任何internet主机的查询,即不能阻止任何有效IP地址的根名称解析,但导致操作问题的查询除外,在这种情况下,阻止应持续问题的时间,并尽可能具体。

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.7 根服务器不应回答来自其他根服务器以外的客户端的AXFR或其他区域传输查询。除其他外,此限制旨在防止根服务器上出现不必要的负载,因为已听到建议,如“为了避免缓存损坏,请将您的服务器设置为根区域的隐形辅助服务器”。根服务器可以将根区域设置为ftp或在一个或多个不太关键的服务器上进行其他访问。

2.8 Servers MUST generate checksums when sending UDP datagrams and MUST verify checksums when receiving UDP datagrams containing a non-zero checksum.

2.8 服务器在发送UDP数据报时必须生成校验和,在接收包含非零校验和的UDP数据报时必须验证校验和。

3. Security Considerations
3. 安全考虑

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 必须以对大型企业至关重要的数据中心预期的方式确保物理安全。

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

3.1.1 无论根服务器所在的整个站点是否具有访问控制,根服务器所在的特定区域必须具有积极的访问控制,即,必须限制、控制和记录允许访问该区域的个人数量。至少

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.2 除非有文件证明当地电网比UPS的MTBF更可靠(即五到十年),否则必须确保至少48小时的电源连续性,无论是通过现场电池、现场发电还是其他方式。这必须提供服务器本身,以及将服务器连接到internet所需的基础设施。必须制定相关程序,确保对电源回退机制和电源的测试频率不低于制造商的规范和建议。

3.1.3 Fire detection and/or retardation MUST be provided.

3.1.3 必须提供火灾探测和/或减速装置。

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.1.4 必须为系统停机后快速恢复运行做好准备。这应包括系统软件和配置的备份。但还应包括预配置的备份硬件,并准备好接管操作,这可能需要手动程序。

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

3.2 网络安全应达到为大型商业企业的关键基础设施提供的级别。

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.

3.2.1 根服务器本身不得提供根名称服务以外的服务,例如远程internet协议,如http、telnet、rlogin、ftp等。只允许服务器管理员使用登录帐户。除非通过中间用户帐户,否则不得允许“Root”或“特权用户”访问。

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

3.2.2 根名称服务器不应信任其他主机,除了信任主服务器的辅助服务器之外,其他主机的身份验证、加密密钥或其他访问或访问权限问题

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.3 根服务器所在的LAN段不能同时也是可破解主机的所在地。也就是说,LAN段应进行交换或路由,因此不存在伪装的可能性。一些LAN交换机不适合用于安全目的,已经发布了针对其过滤的攻击。虽然这些通常可以通过小心配置来防止,但建议极其谨慎。最好是LAN网段上没有任何其他主机。

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.4 根服务器所在的LAN段应单独进行防火墙或数据包过滤,以阻止网络访问除名称服务所需端口以外的任何端口。

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.5 根服务器应通过NTP[RFC1305][RFC2030]或类似机制以尽可能安全的方式同步时钟。为此,服务器及其关联防火墙应允许根服务器成为NTP客户端。根服务器不得充当NTP对等方或服务器。

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.6 应记录所有入侵或其他危害的尝试,并且所有根服务器的所有此类日志应由与所有服务器操作员通信的合作安全团队进行分析,以查找模式、严重尝试等。服务器应登录GMT以便于日志比较。

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

3.2.7 服务器日志记录应该是独立的主机,这些主机应该受到与根服务器本身类似的保护。

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.8 应保护服务器免受基于源路由的攻击。服务器不能依赖基于地址或名称的身份验证。

3.2.9 The network on which the server is homed SHOULD have service.

3.2.9 服务器所在的网络应具有in-addr.arpa服务。

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 需要协议身份验证和安全性来确保根服务器提供的数据是那些被授权维护根区域数据的服务器创建的数据。

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.1 根区域必须由互联网分配号码管理局(IANA)根据DNSSEC签署,见[RFC2535]或其替代文件。据了解,DNSSEC还不能部署在一些通用平台上,但将在支持时部署。

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.2 根服务器必须支持DNSSEC,以便查询可以由具有安全性和身份验证问题的客户端进行身份验证。据了解,DNSSEC还不能部署在一些通用平台上,但将在支持时部署。

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.3 根服务器之间的根区域传输必须经过身份验证,并且尽可能安全。必须支持更新的带外安全验证。服务器必须使用DNSSEC对从其他服务器接收的根区域进行身份验证。据了解,DNSSEC还不能部署在一些通用平台上,但将在支持时部署。

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

3.3.4 可以使用“隐藏的主”服务器,该服务器只允许授权的次根服务器访问。

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.5 根区域更新应仅在通过了大量旨在检测错误更新的启发式检查后进行。如果更新未能通过测试,则必须请求人工干预。

3.3.6 Root zone updates SHOULD normally be effective no later than 6 hours from notification of the root server operator.

3.3.6 根区域更新通常应在通知根服务器操作员后6小时内生效。

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.7 应规定紧急更新的特殊程序。由应急程序启动的更新应在通知后12小时内进行。

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.8 在出现严重网络故障时,每个根服务器必须有一种方法,通过一种介质更新根区域数据,该介质通过另一种非网络路径传送。

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

3.3.9 每个root用户必须每天对收到/回答的查询数量和类型进行全局统计。这些统计数据必须提供给RSSAC和RSSAC赞助的研究人员,以帮助确定如何更好地在全球范围内更有效地部署这些机器

internet. Each root MAY collect data snapshots to help determine data points such as DNS query storms, significant implementation bugs, etc.


4. Communications
4. 通讯

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.1 根服务器操作员之间应协调计划内停机和其他停机时间,以确保大量根服务器不会同时全部停机。计划停机的预先通知还可以避免其他运营商浪费时间去思考任何异常情况。

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.2 根服务器操作员应协调备份时间,以使许多服务器不会同时离线备份。备份应经常转移到异地。

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.3 根服务器操作员应交换日志文件,尤其是与安全、加载和其他重要事件相关的日志文件。这可以通过中心日志协调点进行,也可以是非正式的。

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.4 有关使用率、负载和资源利用率的统计数据应在运营商之间交换,并且必须向IANA报告,以便进行规划和报告。

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.

4.5 Root name服务器管理人员必须每周7天、每天24小时提供服务。待命人员可在正常工作时间以外提供此项服务。

5. Acknowledgements
5. 致谢

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

作者要感谢Scott Bradner、Robert Elz、Chris Fletcher、John Klesins、Steve Bellovin和Vern Paxson的建设性评论。

6. References
6. 工具书类

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

[RFC1035]Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 1035,1987年11月。

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

[RFC2030]Mills,D.“IPv4、IPv6和OSI的简单网络时间协议(SNTP)第4版”,RFC 2030,1996年10月。

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

[RFC2181]Elz,R.和R.Bush,“DNS规范的澄清”,RFC 21811997年7月。

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


7. Authors' Addresses
7. 作者地址

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

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

   Phone: +1 206 780 0431
   Phone: +1 206 780 0431

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

Daniel Karrenberg成熟网络协调中心(NCC)Singel 258 NL-1016 AB荷兰阿姆斯特丹

   Phone: +31 20 535 4444
   Phone: +31 20 535 4444

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

Mark Kosters网络解决方案,弗吉尼亚州赫恩登市亨特马公园大道505号,邮编22070-5100

   Phone: +1 703 742 0400
   Phone: +1 703 742 0400

Raymond Plzak SAIC 1710 Goodridge Drive McLean, Virginia 22102 +1 703 821 6535

雷蒙德·普扎克(Raymond Plzak SAIC)弗吉尼亚州麦克莱恩古德里奇大道1710号22102+1 703 821 6535

8. Specification of Requirements
8. 需求说明

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.

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。

9. Full Copyright Statement
9. 完整版权声明

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.






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