Operational Criteria for Root Name Servers
RFC 2010

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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 a