396 lines
14 KiB
Plaintext
396 lines
14 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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]
|
|||
|
|