home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2010.txt < prev    next >
Text File  |  1996-10-10  |  15KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         B. Manning
  8. Request for Comments: 2010                                           ISI
  9. Category: Informational                                         P. Vixie
  10.                                                                      ISC
  11.                                                             October 1996
  12.  
  13.  
  14.                Operational Criteria for Root Name Servers
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document specifies the operational requirements of root name
  25.    servers, including host hardware capacities, name server software
  26.    revisions, network connectivity, and physical environment.
  27.  
  28. 1 - Rationale and Scope
  29.  
  30.    1.1. Historically, the name servers responsible for the root (".")
  31.    zone have also been responsible for all international top-level
  32.    domains (iTLD's, for example: COM, EDU, INT, ARPA).  These name
  33.    servers have been operated by a cadre of highly capable volunteers,
  34.    and their administration has been loosely coordinated by the NIC
  35.    (first SRI-NIC and now InterNIC).  Ultimate responsibility for the
  36.    correct operation of these servers and for the content of the DNS
  37.    zones they served has always rested with the IANA.
  38.  
  39.    1.2. As described in [Postel96], many new TLD's may be created
  40.    shortly.  Servers for all new and existing iTLD's will be subject to
  41.    the operational requirements given in [Postel96].  The set of servers
  42.    for the root (".")  zone is likely to become disjoint from the set of
  43.    servers for any TLD or group of TLD's, including those maintained by
  44.    the InterNIC.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Manning & Vixie              Informational                      [Page 1]
  59.  
  60. RFC 2010                    DNSSVR Criteria                 October 1996
  61.  
  62.  
  63.    1.3. In spite of the similarities in operational requirements between
  64.    the servers for the iTLD's and the servers for the root (".") zone,
  65.    they are in fact different server sets with different administrators
  66.    and slightly different operational requirements. It is likely that
  67.    many contry code tld servers will have even more divergent
  68.    operational requirements. That said, the requirements set down in
  69.    this document could be successfully applied to any name server
  70.    (whether root, top level, or any other level), but may be more
  71.    draconian than necessary for servers other than those of the root
  72.    (".") zone.
  73.  
  74.    Disclaimer:  The selection of name server locations and
  75.                 administrators, and the procedures for addressing
  76.                 noncompliance with these stated operational
  77.                 requirements, are outside the scope of this document.
  78.  
  79.    Definition:  For the purpose of this document, the term "zone master"
  80.                 shall be used to designate the administrative owner of
  81.                 the content of a zone.  This person is expected to have
  82.                 final responsibility for the selection and correct
  83.                 operation of all of the zone's servers.  For the root
  84.                 (".") zone, this is the IANA.
  85.  
  86. 2 - Operational Requirements
  87.  
  88.    2.1. Name server software.  The zone master shall initially and
  89.    periodically choose a name server package to run on all of the zone's
  90.    servers.  It is expected that the BIND server will be used, at least
  91.    initially, and that new versions or other servers will be specified
  92.    from time to time.
  93.  
  94.      Rationale:  This requirement is based on the wide and free
  95.                  availability of BIND's source code, and the active
  96.                  analysis and development it constantly receives from
  97.                  several members of the IETF.
  98.  
  99.    Name server software upgrades will be specified and scheduled by the
  100.    zone master, and must occur on all of a zone's servers within a
  101.    specified 96 hour window.
  102.  
  103.      Rationale:  In some cases it has proven necessary to "cold start" a
  104.                  zone's servers in order to clear out oscillating bad
  105.                  data.  By forcing all software upgrades to happen at
  106.                  about the same time, it will be possible to coordinate
  107.                  a software change with a zone content change.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Manning & Vixie              Informational                      [Page 2]
  115.  
  116. RFC 2010                    DNSSVR Criteria                 October 1996
  117.  
  118.  
  119.    2.2. UDP checksums.  UDP checksums must be generated when sending
  120.    datagrams, and verified when receiving them.
  121.  
  122.      Rationale:  Some vendors turn off UDP checksums for performance
  123.                  reasons, citing the presence of MAC-level frame checks
  124.                  (CRC, for example) as "strong enough."  This has been
  125.                  a disaster in actual practice.
  126.  
  127.    2.3. Dedicated host.  A name server host should have no other
  128.    function, and no login accounts other than for system or network
  129.    administrators.  No other network protocols should be served by a
  130.    name server host (e.g., SMTP, NNTP, FTP, et al).  If login is
  131.    permitted from other than the system console, then the login service
  132.    must be by encrypted channel (e.g., Kerberized and encrypted
  133.    rlogin/telnet, the secure shell (SSH), or an equivilent).
  134.  
  135.      Rationale:  Each additional service performed by a host makes it
  136.                  less reliable and potentially less secure, as well as
  137.                  complicating fault isolation procedures.  While name
  138.                  service does not consume very much in the way of system
  139.                  resources, it is thought best that a host do a few
  140.                  things well rather than many things poorly.
  141.  
  142.    2.4. Clock synchronization.  A name server host should synchronize
  143.    its clock using the NTP protocol (currnet version) with
  144.    authentication.  At least two NTP servers should be used.  As an
  145.    exception to section 2.3 above, a name server host can be an NTP
  146.    server as well.
  147.  
  148.      Rationale:  For distributed fault isolation reasons, synchronized
  149.                  time stamps in system event logs are quite helpful.
  150.                  NTP is easily spoofed by UDP blast attacks, thus the
  151.                  requirement for authentication between the name server
  152.                  host and its NTP servers.  A name server host is
  153.                  allowed to be an NTP server because it has been
  154.                  observed that a single host running both name service
  155.                  and stratum 1 NTP is still quite reliable and secure.
  156.  
  157.    2.5. Network interfaces.  Name servers must send UDP responses with
  158.    an IP source address (and UDP source port number) equal to the IP
  159.    destination address (and UDP destination port number) of the request.
  160.    Also, a name server might have multiple real interfaces, but only one
  161.    will be advertised in the zone's NS RRset and associated glue A RRs.
  162.    The advertised address should be that of the "best" interface on the
  163.    host, in terms of network performance and reliability to the largest
  164.    number of destinations.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Manning & Vixie              Informational                      [Page 3]
  171.  
  172. RFC 2010                    DNSSVR Criteria                 October 1996
  173.  
  174.  
  175.      Rationale:  While not required by [RFC1035], many extant DNS
  176.                  implementations require the source address and port of
  177.                  a reply to match the destination address and port to
  178.                  which the request was sent.  The number of advertised
  179.                  addresses is limited to one (1) so that DNS delegation
  180.                  responses containing this name server can be as short
  181.                  as possible.
  182.  
  183.    2.6. Physical environment.  A name server host must be located in a
  184.    secure space such as a locked computer room or a data center with
  185.    restricted access.  The power supply should be redundant, using
  186.    batteries, generators or some other means to protect against utility
  187.    power failures.  Network connectivity should be redundant, so that a
  188.    single wide area line failure cannot completely isolate the name
  189.    server host from the rest of the network.
  190.  
  191.    2.7. Network security.  The system and network administrators should
  192.    educate themselves about potential threats, and stay current on CERT
  193.    bulletins regarding network breakins.  The system staff should
  194.    periodically audit the name server host's activity logs and be able
  195.    to detect breakins during or after the fact.
  196.  
  197.    2.8. Host performance.  As of the time of this writing, a name server
  198.    must be able to answer 1,200 UDP transactions per second with less
  199.    than 5 milliseconds of average latency.  Because the network is still
  200.    growing at a high rate, the ability to grow to 2,000 transactions per
  201.    second and still support a 5 millisecond latency is highly desirable.
  202.    Note that this requirement affects both the host and the network
  203.    infrastructure to which that host is attached.
  204.  
  205.    2.9. Response time.  The administrators responsible for a name server
  206.    will respond to e-mail trouble reports within 24 hours.  Personnel
  207.    issues such as vacations and illness will cause responsibilities to
  208.    be delegated and/or reassigned rather than ignored.  After hours
  209.    telephone numbers must be made available to the zone master for
  210.    nonpublished use in emergencies.  An escalation contact name, e-mail
  211.    address, and telephone number will also be made available to the zone
  212.    master in the event of nonresponse through the normal channel.
  213.  
  214.    2.10. Zone transfer access control.  The name server shall be
  215.    configured so that outbound zone transfers are permitted only to
  216.    destinations on the server's local networks, and to whichever
  217.    networks the zone master designates for remote debugging purposes.
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Manning & Vixie              Informational                      [Page 4]
  227.  
  228. RFC 2010                    DNSSVR Criteria                 October 1996
  229.  
  230.  
  231.      Rationale:  Zone transfers can present a significant load on a name
  232.                  server, especially if several transfers are started
  233.                  simultaneously against the same server.  There is no
  234.                  operational reason to allow anyone outside the name
  235.                  server's and zone's administrators to transfer the
  236.                  entire zone.
  237.  
  238.    2.11. Zone transfer protocol.  DNS AXFR shall be used in preference
  239.    to FTP or any other non-DNS transfer protocol.  DNS NOTIFY (see
  240.    [NOTIFY]) and DNS IXFR (see [IXFR]) shall be supported and enabled
  241.    when available.
  242.  
  243.      Rationale:  Historically, the common implementations of DNS
  244.                  (a.k.a., BIND) did not support zone transfer of the
  245.                  root (".") zone due to programming errors.  Thus, FTP
  246.                  was used.  In the future, DNS implementations which do
  247.                  not support zone transfer of all zones will not be
  248.                  considered suitable for use as root name servers.  The
  249.                  benefits of [IXFR] and [NOTIFY] should be obvious.
  250.  
  251.    2.12. Recursion shall be disabled for queries.
  252.  
  253.      Rationale:  Recursion is a major source of cache pollution, and can
  254.                  be a major drain on name server performance.  An
  255.                  organization's recursive DNS needs should be served by
  256.                  some other host than its root name server(s).  An
  257.                  exception is made for missing glue since it's possible
  258.                  that glue needed for some delegations will not be
  259.                  within or beneath any zone for which the server is
  260.                  authoritative.  Such glue must be fetched via
  261.                  recursive lookups to other servers.
  262.  
  263.    2.13. Outages shall be reported.  All outages, scheduled or not,
  264.    shall be reported to the zone master via e-mail.  If an outage is
  265.    unscheduled or if an outage is scheduled less than 24 hours in
  266.    advance, then an additional notification of the zone master shall be
  267.    made via telephone.  Extended or repeated outages may beget special
  268.    handling by the zone master.
  269.  
  270.    2.14. Inverse name lookups.  The PTR RR associated with a server's
  271.    primary interface address (that is, the address shown in in the
  272.    zone's delegation) shall have its target specified by the zone
  273.    master.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Manning & Vixie              Informational                      [Page 5]
  283.  
  284. RFC 2010                    DNSSVR Criteria                 October 1996
  285.  
  286.  
  287.      Rationale:  Since each organization has local control of their
  288.                  network's PTR RRs, and since it is necessary for the
  289.                  correct operation of some software that the forward and
  290.                  reverse lookups have symmetrical results, it is left
  291.                  up to the zone master to select the name for each
  292.                  authority server's primary address.
  293.  
  294. 3 - Possible Selection Criteria
  295.  
  296.    3.1. Host population.  A server's location on the network should be
  297.    such that it has a low IP hop count to a high number of end hosts.
  298.    Duplication of service should be avoided, such that any given set of
  299.    end hosts needs to have a low IP hop count to at most one authority
  300.    server for any given zone.
  301.  
  302.    3.2. Infrastructure diversity.  A server's location on the network
  303.    should be such that most failures capable of isolating it from a
  304.    large number of end hosts are diverse from the failures capable of
  305.    similarly isolating other authority servers for the same zone(s).
  306.  
  307. 4 - Security Considerations
  308.  
  309.    See section 2.7.
  310.  
  311. 5 - References
  312.  
  313.    [RFC1035]
  314.       Mockapetris, P., "Domain Names - Implementation and Specification",
  315.       STD 13, RFC 1035, USC/Information Sciences Institute, November
  316.       1987.
  317.  
  318.    [Postel96]
  319.       Postel, J., "New Registries and the Delegation of International Top
  320.       Level Domains", Work in Progress.
  321.  
  322.    [IXFR]
  323.       Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
  324.  
  325.    [NOTIFY]
  326.       Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
  327.       RFC 1996, August 1996.
  328.  
  329. 6 - Acknowledgements
  330.  
  331.    Constructive comments have been received from:  Jon Postel, Michael
  332.    Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle,
  333.    Owen DeLong and other members of the internet community.
  334.  
  335.  
  336.  
  337.  
  338. Manning & Vixie              Informational                      [Page 6]
  339.  
  340. RFC 2010                    DNSSVR Criteria                 October 1996
  341.  
  342.  
  343. 7 - Authors' Addresses
  344.  
  345.      Bill Manning
  346.      USC/ISI
  347.      4676 Admiralty Way
  348.      Marina del Rey, CA 90292
  349.  
  350.      Phone: +1 310 822 1511
  351.      EMail: bmanning@isi.edu
  352.  
  353.  
  354.      Paul Vixie
  355.      Internet Software Consortium
  356.      Star Route Box 159A
  357.      Woodside, CA 94062
  358.  
  359.      Phone: +1 415 747 0204
  360.      EMail: paul@vix.com
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Manning & Vixie              Informational                      [Page 7]
  395.  
  396.