RFC 2010 (rfc2010) - Page 2 of 7

Operational Criteria for Root Name Servers

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