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
   name server host (e.g., SMTP, NNTP, FTP, et al).  If login is
   permitted from other than the system console, then the login service
   must be by encrypted channel (e.g., Kerberized and encrypted
   rlogin/telnet, the secure shell (SSH), or an equivilent).

     Rationale:  Each additional service performed by a host makes it
                 less reliable and potentially less secure, as well as
                 complicating fault isolation procedures.  While name
                 service does not consume very much in the way of system
                 resources, it is thought best that a host do a few
                 things well rather than many things poorly.

   2.4. Clock synchronization.  A name server host should synchronize
   its clock using the NTP protocol (currnet version) with
   authentication.  At least two NTP servers should be used.  As an
   exception to section 2.3 above, a name server host can be an NTP
   server as well.

     Rationale:  For distributed fault isolation reasons, synchronized
                 time stamps in system event logs are quite helpful.
                 NTP is easily spoofed by UDP blast attacks, thus the
                 requirement for authentication between the name server
                 host and its NTP servers.  A name server host is
                 allowed to be an NTP server because it has been
                 observed that a single host running both name service
                 and stratum 1 NTP is still quite reliable and secure.

   2.5. Network interfaces.  Name servers must send UDP responses with
   an IP source address (and UDP source port number) equal to the IP
   destination address (and UDP destination port number) of the request.
   Also, a name server might have multiple real interfaces, but only one
   will be advertised in the zone's NS RRset and associated glue A RRs.
   The advertised address should be that of the "best" interface on the
   host, in terms of network performance and reliability to the largest
   number of destinations.

Manning & Vixie              Informational                      [Page 3]
RFC 2010                    DNSSVR Criteria                 October 1996

     Rationale:  While not required by [RFC1035], many extant DNS
                 implementations require the source address and port of
                 a reply to match the destination address and port to
                 which the request was sent.  The number of advertised
                 addresses is limited to one (1) so that DNS delegation
                 responses containing this name server can be as short
                 as possible.

   2.6. Physical environment.  A name server host must be located in a
   secure space such as a locked computer room or a data center with
   restricted access.  The power supply should be redundant, using
   batteries, generators or some other means to protect against utility
   power failures.  Network connectivity should be redundant, so that a
   single wide area line failure cannot completely isolate the name
   server host from the rest of the network.

   2.7. Network security.  The system and network administrators should
   educate themselves about potential threats, and stay current on CERT
   bulletins regarding network breakins.  The system staff should
   periodically audit the name server host's activity logs and be able
   to detect breakins during or after the fact.

   2.8. Host performance.  As of the time of this writing, a name server
   must be able to answer 1,200 UDP transactions per second with less
   than 5 milliseconds of average latency.  Because the network is still
   growing at a high rate, the ability to grow to 2,000 transactions per
   second and still support a 5 millisecond latency is highly desirable.
   Note that this requirement affects both the host and the network
   infrastructure to which that host is attached.

   2.9. Response time.  The administrators responsible for a name server
   will respond to e-mail trouble reports within 24 hours.  Personnel
   issues such as vacations and illness will cause responsibilities to
   be delegated and/or reassigned rather than ignored.  After hours
   telephone numbers must be made available to the zone master for
   nonpublished use in emergencies.  An escalation contact name, e-mail
   address, and telephone number will also be made available to the zone
   master in the event of nonresponse through the normal channel.

   2.10. Zone transfer access control.  The name server shall be
   configured so that outbound zone transfers are permitted only to
   destinations on the server's local networks, and to whichever
   networks the zone master designates for remote debugging purposes.

Manning & Vixie              Informational                      [Page 4]
RFC 2010                    DNSSVR Criteria                 October 1996

     Rationale:  Zone transfers can present a significant load on a name
                 server, especially if several transfers are started
                 simultaneously against the same server.  There is no
                 operational reason to allow anyone outside the name
                 server's and zone's administrators to transfer the
                 entire zone.

   2.11. Zone transfer protocol.  DNS AXFR shall be used in preference
   to FTP or any other non-DNS transfer protocol.  DNS NOTIFY (see
   [NOTIFY]) and DNS IXFR (see [IXFR]) shall be supported and enabled
   when available.

     Rationale:  Historically, the common implementations of DNS
                 (a.k.a., BIND) did not support zone transfer of the
                 root (".") zone due to programming errors.  Thus, FTP
                 was used.  In the future, DNS implementations which do
                 not support zone transfer of all zones will not be
                 considered suitable for use as root name servers.  The
                 benefits of [IXFR] and [NOTIFY] should be obvious.

   2.12. Recursion shall be disabled for queries.

     Rationale:  Recursion is a major source of cache pollution, and can
                 be a major drain on name server performance.  An
                 organization's recursive DNS needs should be served by
                 some other host than its root name server(s).  An
                 exception is made for missing glue since it's possible
                 that glue needed for some delegations will not be
                 within or beneath any zone for which the server is
                 authoritative.  Such glue must be fetched via
                 recursive lookups to other servers.

   2.13. Outages shall be reported.  All outages, scheduled or not,
   shall be reported to the zone master via e-mail.  If an outage is
   unscheduled or if an outage is scheduled less than 24 hours in
   advance, then an additional notification of the zone master shall be
   made via telephone.  Extended or repeated outages may beget special
   handling by the zone master.

   2.14. Inverse name lookups.  The PTR RR associated with a server's
   primary interface address (that is, the address shown in in the
   zone's delegation) shall have its target specified by the zone
   master.

Manning & Vixie              Informational                      [Page 5]
RFC 2010                    DNSSVR Criteria                 October 1996

     Rationale:  Since each organization has local control of their
                 network's PTR RRs, and since it is necessary for the
                 correct operation of some software that the forward and
                 reverse lookups have symmetrical results, it is left
                 up to the zone master to select the name for each
                 authority server's primary address.

3 - Possible Selection Criteria

   3.1. Host population.  A server's location on the network should be
   such that it has a low IP hop count to a high number of end hosts.
   Duplication of service should be avoided, such that any given set of
   end hosts needs to have a low IP hop count to at most one authority
   server for any given zone.

   3.2. Infrastructure diversity.  A server's location on the network
   should be such that most failures capable of isolating it from a
   large number of end hosts are diverse from the failures capable of
   similarly isolating other authority servers for the same zone(s).

4 - Security Considerations

   See section 2.7.

5 - References

   [RFC1035]
      Mockapetris, P., "Domain Names - Implementation and Specification",
      STD 13, RFC 1035, USC/Information Sciences Institute, November
      1987.

   [Postel96]
      Postel, J., "New Registries and the Delegation of International Top
      Level Domains", Work in Progress.

   [IXFR]
      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.

   [NOTIFY]
      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
      RFC 1996, August 1996.

6 - Acknowledgements

   Constructive comments have been received from:  Jon Postel, Michael
   Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle,
   Owen DeLong and other members of the internet community.

Manning & Vixie              Informational                      [Page 6]
RFC 2010                    DNSSVR Criteria                 October 1996

7 - Authors' Addresses

     Bill Manning
     USC/ISI
     4676 Admiralty Way
     Marina del Rey, CA 90292

     Phone: +1 310 822 1511
     EMail: bmanning@isi.edu

     Paul Vixie
     Internet Software Consortium
     Star Route Box 159A
     Woodside, CA 94062

     Phone: +1 415 747 0204
     EMail: paul@vix.com

Manning & Vixie              Informational                      [Page 7]