Operational Criteria for Root Name Servers
RFC 2010
Document | Type |
RFC - Informational
(October 1996; No errata)
Obsoleted by RFC 2870
Was draft-manning-dnssvr-criteria (individual)
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text pdf html bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2010 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group B. Manning Request for Comments: 2010 ISI Category: Informational P. Vixie ISC October 1996 Operational Criteria for Root Name Servers Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. 1 - Rationale and Scope 1.1. Historically, the name servers responsible for the root (".") zone have also been responsible for all international top-level domains (iTLD's, for example: COM, EDU, INT, ARPA). These name servers have been operated by a cadre of highly capable volunteers, and their administration has been loosely coordinated by the NIC (first SRI-NIC and now InterNIC). Ultimate responsibility for the correct operation of these servers and for the content of the DNS zones they served has always rested with the IANA. 1.2. As described in [Postel96], many new TLD's may be created shortly. Servers for all new and existing iTLD's will be subject to the operational requirements given in [Postel96]. The set of servers for the root (".") zone is likely to become disjoint from the set of servers for any TLD or group of TLD's, including those maintained by the InterNIC. Manning & Vixie Informational [Page 1] RFC 2010 DNSSVR Criteria October 1996 1.3. In spite of the similarities in operational requirements between the servers for the iTLD's and the servers for the root (".") zone, they are in fact different server sets with different administrators and slightly different operational requirements. It is likely that many contry code tld servers will have even more divergent operational requirements. That said, the requirements set down in this document could be successfully applied to any name server (whether root, top level, or any other level), but may be more draconian than necessary for servers other than those of the root (".") zone. Disclaimer: The selection of name server locations and administrators, and the procedures for addressing noncompliance with these stated operational requirements, are outside the scope of this document. Definition: For the purpose of this document, the term "zone master" shall be used to designate the administrative owner of the content of a zone. This person is expected to have final responsibility for the selection and correct operation of all of the zone's servers. For the root (".") zone, this is the IANA. 2 - Operational Requirements 2.1. Name server software. The zone master shall initially and periodically choose a name server package to run on all of the zone's servers. It is expected that the BIND server will be used, at least initially, and that new versions or other servers will be specified from time to time. Rationale: This requirement is based on the wide and free availability of BIND's source code, and the active analysis and development it constantly receives from several members of the IETF. Name server software upgrades will be specified and scheduled by the zone master, and must occur on all of a zone's servers within a specified 96 hour window. Rationale: In some cases it has proven necessary to "cold start" a zone's servers in order to clear out oscillating bad data. By forcing all software upgrades to happen at about the same time, it will be possible to coordinate a software change with a zone content change. Manning & Vixie Informational [Page 2] RFC 2010 DNSSVR Criteria October 1996 2.2. UDP checksums. UDP checksums must be generated when sending datagrams, and verified when receiving them. Rationale: Some vendors turn off UDP checksums for performance reasons, citing the presence of MAC-level frame checks (CRC, for example) as "strong enough." This has been a disaster in actual practice. 2.3. Dedicated host. A name server host should have no other function, and no login accounts other than for system or network administrators. No other network protocols should be served by aShow full document text