view Side-By-Side changes
Technical November 1996 May 1996
Operational Criteria for Root and TLD Name Servers
draft-manning-dnssvr-criteria-01.txt
Abstract
This draft proposes criteria for servers and their environments that
will support zones for top level and root domains. It is expected that
the machines running root name service will be different than the machines
running TLD name service. Although there are differences, the same basic
criteria should hold. For example, it is expected that TLD servers may
field more queries and the root servers may be more concerned with cache
pollution.
Although this draft has been discussed in various bodies, it is not
final, it should not be regarded as a consensus document, and it is
presented for open debate in the Internet community.
<draft-manning-dnssvr-criteria-02.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), nic.nordu.net
(Europe), or
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Design Goals:
Define the basic set of requirements for TLD & Root server systems.
Make them all objectively verifiable.
Disclaimer: Coast).
Abstract
This document doesn't discuss actual placement specifies the operational requirements of servers.
Procedures for dealing with non-compliance are not covered in root name
servers, including host hardware capacities, name server software
revisions, network connectivity, and physical environment.
Although this memo.
Selected Operational Qualifications:
1. Modern BIND or equivalents (if any exist).
The upgrade process will draft has been discussed in various bodies, it is not
final, it should not be regarded as a consensus document, and it is
presented for open debate in the Internet community.
Expires November 1996 [Page 1]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
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 with by the zone-master staff NIC (first SRI-NIC
and now InterNIC). Ultimate responsibility for the correct operation of
these servers and will occur within 96 hours for the content of initial notification. Zone-master
senior staff will specify the software DNS zones they served has
always rested with the IANA.
1.2. As described in [Postel96], many new iTLD's will be created
shortly. Servers for all new and version(s) that existing iTLD's will be run in a particular zone.
2. UDP checksums enabled.
Note that this should also apply subject to all machines running DNS.
3. Dedicated host.
No user accounts, just the operations & admin or root account.
No other services except NTP. (remove telnet, SMTP, FTP etc).
This requires support the
operational requirements given in [Postel96]. The set of servers for
the root (``.'') zone is likely to be become disjoint from the console set of
servers for any iTLD or group of iTLD's, including those maintained by
the InterNIC.
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. The requirements set down
in this document could be successfully applied to any name server
(whether root, top level, or any other specified
secure channel. level), but may seem 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 noncompliance with the 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.
Expires November 1996 [Page 2]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
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 one-time tokens the BIND server will be used
for authentication.
4. Singly homed (only one interface). 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 service should always answer 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 interface as requests
come in on. Also, delegations time, it will usually list be possible to coordinate a single
software change with a zone content change.
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 RR, so there name server host should have no other function,
and no login accounts other than for system or network administrators.
No other network protocols should only be served by a single canonical name.
5. Protected.
In general, each name server must be adequately protected against security
threats. The host (e.g.,
SMTP, NNTP, FTP, et al). If login is permitted from other than the
system administrator must stay up-to-date on console, then the latest
security methods and threats and login service must implement reasonable security
countermeasures. Audits be by encrypted channel
(e.g., Kerberized rlogin, Kerberized telnet, the zone administrator secure shell (SSH),
S/Key, or authorized agents
will be permitted an equivilent).
Rationale: Each additional service performed by a host makes it less
reliable and corrective measures will be taken. A good potentially less secure, as well as
complicating fault isolation procedures. While name
service does not consume very much in the way to
keep current of system
resources, it is thought best that a host do a few things
well rather than many things poorly.
Expires November 1996 [Page 3]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
2.4. Clock synchronization. A name server host should synchronize its
clock using the NTP protocol (version 3) with authentication. At least
two NTP servers should be used. As an exception to follow 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 CERT recommendations.
requirement for authentication between the name server
host and its NTP servers. A reasonable
approach name server host is allowed
to only run DNS sw, be an NTP server because it has been observed that a
single host running both name service and ICMP support stratum 1 NTP
is still quite reliable and secure.
2.5. Network interfaces. Name servers must send UDP responses with extensive
logging. Recommended packages an
IP source address (and UDP source port number) equal to assist are tcp_wrappers 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 ipfilter.
Any other package 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.
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 has an acceptable technology is fine.
6. Servers time is synchronized via NTP.
This is useful for supporting functions; e.g. logging. It
the request was sent. The number of advertised addresses
is expected limited to one (1) so that future enhancements 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 dynamic update and security support
will take advantage of accurate clocks. This presumes 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 NTP name server has been secured using strong authentication.
7. Sufficient resources.
Each
host from the rest of the network.
2.7. Network security. The system must 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 support a transaction rate
detect breakins during or after the fact.
Expires November 1996 [Page 4]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
2.8. Host performance. As of 1200/sec and
mean the time to respond of 5 milliseconds per transaction as this writing, a baseline.
There should name server
must be enough extra resources available able to support a 50% growth answer 1,200 UDP transactions per year in the number 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 without affecting the
response time. and
still support a 5 millisecond latency is highly desirable. Note that these numbers involve system selection
this requirement affects both the host and
available the network infrastructure bandwidth.
8. Representatives on TLD/Root administrator list are responsive:
8a. e-mail about required changes to
which that host is attached.
2.9. Response time. The administrators responsible for a name server
will be answered respond to e-mail trouble reports within 24 hours;
8b. hours. Personnel
issues such as vacations and illness will cause responsibilities to be delegated, not ignored;
8c. contact numbers, including after
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 emergency, on file
with zone-master senior staff members;
8d. an escalation/delegation list that has at least three levels of
hierarchy.
9. Named.boot file will specify:
9a. "xfrlist"
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 nets networks, and maybe other roots;
9b. server will use "secondary" from to whichever networks the zone master, master
designates for remote debugging purposes.
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 FTP;
Note that support zone transfer of the root (``.'')
zone due to programming errors. Thus, FTP was used. In
the load future, DNS implementations which do not support zone
transfer of fork & named-xfer for very large all zones will probably block the machine if concurrent AXFRs are done
with the latest version not be considered suitable for
use as root or iTLD name servers. The benefits of BIND (#);
9c. "options no-recursion" and "limit transfers-per-ns 1";
9d. "options no-fetch-glue".
(Equivalences [IXFR]
and [NOTIFY] should be obvious.
Expires November 1996 [Page 5]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
2.12. Recursion shall be disabled for non-BIND servers will apply!)
(#) BIND 4.9.3-R-P1 01may96
10. Network queries.
Rationale: Recursion is a major source of cache pollution, and can
be a major drain on name server outages 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 reported.
10a. To within
or beneath any zone for which the root admin and TLD admin lists whether server is
authoritative. Such glue must be fetched via recursive
lookups to other servers.
2.13. Outages shall be reported. All outages, scheduled or
unscheduled.
10b. via phone not, shall
be reported to the zone-master senior staff if the zone master via e-mail. If an outage is unscheduled
or if the an outage is to occur in scheduled less than 24 hours.
10c. hours in advance, then an
additional notification of the zone master shall be made via telephone.
Extended or repeated outages may result in exceptional beget special handling situations.
11. Name server and its immediate infrastructure are protected against likely
force majeure (power failures, ...).
12. Address by the zone
master.
2.14. Inverse name lookups. The PTR points (only) to ?.root-servers.net, not RR associated with a "local" name.
TLD servers will server's
primary interface address (that is, the address shown in in the zone's
delegation) shall have similar requirements.
Possible Selection Criteria:
1. serves max possible number its target specified by the zone master.
Rationale: Since each organization has local control of low-hopcount endpoints not otherwise served.
2. credibly likely to continuously perform on qualification criteria their
network's PTR RRs, and since it is necessary for the duration
correct operation of some software that the operations contract.
3. stable organization which forward and
reverse lookups have symmetrical results, it is considered likely left up
to survive and prosper.
4. Limited exposure 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 points a high number of failure end hosts.
Duplication of service should be avoided, such that may 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 shared by other, peer
nameservers.
Security considerations such that most failures capable of this memo 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).
Expires November 1996 [Page 6]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
4 - Security Considerations
None.
Acknowledgments
5 - References
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,''
RFC 1035, USC/Information Sciences Institute, November 1987.
[Postel96]
J. Postel, "New Registries and the Delegation of International Top
Level Domains", <draft-postel-iana-itld-admin-00.txt>, May 3, 1996.
[IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February
1996, <draft-ietf-dnsind-ixfr-06.txt>.
[NOTIFY]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,''
Internet Draft, March 1996, <draft-ietf-dnsind-notify-07.txt>.
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.
Authors' Addresses
7 - Author's Address
Bill Manning
USC/ISI
4676 Admiralty Way
Marina del Rey, CA. CA 90292
+1.310.822.1511
bmanning@isi.edu
+1 310 822 1511
<bmanning@isi.edu>
Paul Vixie
Internet Software Consortium (ISC)
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
paul@vix.com
<paul@vix.com>
Expires November 1996 [Page 7]
--
----