As per Relevance of the word requirement, we have this rfc below:
Network Working Group R.
Request for Comments: 2870
Obsoletes: 2010 D.
BCP: 40 RIPE
Category: Best Current Practice M.
Network
R.
June 2000
Root Name Server Operational
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
As the internet becomes increasingly critical to the world's
and economic infrastructure, attention has rightly focused on
correct, safe, reliable, and secure operation of the
infrastructure itself. The root domain name servers are seen as
crucial part of that technical infrastructure. The primary focus
this document is to provide guidelines for operation of the root
servers. Other major zone server operators (gTLDs, ccTLDs,
zones) may also find it useful. These guidelines are intended
meet the perceived societal needs without overly
technical details
1.
The resolution of domain names on the internet is
dependent on the proper, safe, and secure operation of the
domain name servers. Currently, these dozen or so servers
provided and operated by a very competent and trusted group
volunteers. This document does not propose to change that,
merely to provide formal guidelines so that the community
how and why this is done
Bush, et al. Best Current Practice [Page 1]
RFC 2870 Root Name Server Operational Requirements June 2000
1.1 The Internet Corporation for Assigned Names and Numbers (ICANN
has become responsible for the operation of the root servers
The ICANN has appointed a Root Server System Advisory
(RSSAC) to give technical and operational advice to the
board. The ICANN and the RSSAC look to the IETF to
engineering standards
1.2 The root servers serve the root, aka ".", zone. Although
some of the root servers also serve some TLDs (top level domains
such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such
INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g.
for Sweden), this is likely to change (see 2.5).
1.3 The root servers are neither involved with nor dependent upon
'whois' data
1.4 The domain name system has proven to be sufficiently robust
we are confident that the, presumably temporary, loss of most
the root servers should not significantly affect operation of
internet
1.5 Experience has shown that the internet is quite vulnerable
incorrect data in the root zone or TLDs. Hence authentication
validation, and security of these data are of great concern
2. The Servers
The following are requirements for the technical details of the
servers themselves
2.1 It would be short-sighted of this document to specify
hardware, operating systems, or name serving software
Variations in these areas would actually add overall robustness
2.2 Each server MUST run software which correctly implements the
standards for the DNS, currently [RFC1035] [RFC2181].
there are no formal test suites for standards compliance,
maintainers of software used on root servers are expected to
all reasonable actions to conform to the IETF's then
documented expectations
2.3 At any time, each server MUST be able to handle a load
requests for root data which is three times the measured peak
such requests on the most loaded server in then current
conditions. This is usually expressed in requests per second
This is intended to ensure continued operation of root
should two thirds of the servers be taken out of operation
whether by intent, accident, or malice
Bush, et al. Best Current Practice [Page 2]
RFC 2870 Root Name Server Operational Requirements June 2000
2.4 Each root server should have sufficient connectivity to
internet to support the bandwidth needs of the above requirement
Connectivity to the internet SHOULD be as diverse as possible
Root servers SHOULD have mechanisms in place to accept
connectivity to the root server from any internet
delivering connectivity at their own cost
2.5 Servers MUST provide authoritative responses only from the
they serve. The servers MUST disable recursive lookup
forwarding, or any other function that may allow them to
cached answers. They also MUST NOT provide secondary service
any zones other than the root and root-servers.net zones.
restrictions help prevent undue load on the root servers
reduce the chance of their caching incorrect data
2.6 Root servers MUST answer queries from any internet host, i.e.
not block root name resolution from any valid IP address,
in the case of queries causing operational problems, in
case the blocking SHOULD last only as long as the problem, and
as specific as reasonably possible
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer
queries from clients other than other root servers.
restriction is intended to, among other things,
unnecessary load on the root servers as advice has been
such as "To avoid having a corruptible cache, make your server
stealth secondary for the root zone." The root servers MAY
the root zone up for ftp or other access on one or more
critical servers
2.8 Servers MUST generate checksums when sending UDP datagrams
MUST verify checksums when receiving UDP datagrams containing
non-zero checksum
3. Security
The servers need both physical and protocol security as well
unambiguous authentication of their responses
3.1 Physical security MUST be ensured in a manner expected of
centers critical to a major enterprise
3.1.1 Whether or not the overall site in which a root server
located has access control, the specific area in which
root server is located MUST have positive access control
i.e. the number of individuals permitted access to
area MUST be limited, controlled, and recorded. At
Bush, et al. Best Current Practice [Page 3]
RFC 2870 Root Name Server Operational Requirements June 2000
minimum, control measures SHOULD be either mechanical
electronic locks. Physical security MAY be enhanced
the use of intrusion detection and motion sensors
multiple serial access points, security personnel, etc
3.1.2 Unless there is documentable experience that the
power grid is more reliable than the MTBF of a UPS (i.e
five to ten years), power continuity for at least 48
MUST be assured, whether through on-site batteries, on
site power generation, or some combination thereof.
MUST supply the server itself, as well as
infrastructure necessary to connect the server to
internet. There MUST be procedures which ensure
power fallback mechanisms and supplies are tested no
frequently than the specifications and recommendations
the manufacturer
3.1.3 Fire detection and/or retardation MUST be provided
3.1.4 Provision MUST be made for rapid return to operation
a system outage. This SHOULD involve backup of
software and configuration. But SHOULD also
backup hardware which is pre-configured and ready to
over operation, which MAY require manual procedures
3.2 Network security should be of the level provided for
infrastructure of a major commercial enterprise
3.2.1 The root servers themselves MUST NOT provide
other than root name service e.g. remote
protocols such as http, telnet, rlogin, ftp, etc.
only login accounts permitted should be for the
administrator(s). "Root" or "privileged user" access
NOT be permitted except through an intermediate
account
Servers MUST have a secure mechanism for
administrative access and maintenance. Failures happen
given the 24x7 support requirement (per 4.5), there
be times when something breaks badly enough that
wizards will have to connect remotely. Remote logins
be protected by a secure means that is
authenticated and encrypted, and sites from which
login is allowed MUST be protected and hardened
3.2.2 Root name servers SHOULD NOT trust other hosts,
secondary servers trusting the primary server, for
of authentication, encryption keys, or other access
Bush, et al. Best Current Practice [Page 4]
RFC 2870 Root Name Server Operational Requirements June 2000
security information. If a root operator uses
authentication to manage access to the root server,
the associated kerberos key server MUST be protected
the same prudence as the root server itself. This
to all related services which are trusted in any manner
3.2.3 The LAN segment(s) on which a root server is homed
NOT also home crackable hosts. I.e. the LAN
should be switched or routed so there is no possibility
masquerading. Some LAN switches aren't suitable
security purposes, there have been published attacks
their filtering. While these can often be prevented
careful configuration, extreme prudence is recommended
It is best if the LAN segment simply does not have
other hosts on it
3.2.4 The LAN segment(s) on which a root server is homed
be separately firewalled or packet filtered to
network access to any port other than those needed
name service
3.2.5 The root servers SHOULD have their clocks synchronized
NTP [RFC1305] [RFC2030] or similar mechanisms, in
secure manner as possible. For this purpose, servers
their associated firewalls SHOULD allow the root
to be NTP clients. Root servers MUST NOT act as NTP
or servers
3.2.6 All attempts at intrusion or other compromise SHOULD
logged, and all such logs from all root servers SHOULD
analyzed by a cooperative security team communicating
all server operators to look for patterns,
attempts, etc. Servers SHOULD log in GMT to
log comparison
3.2.7 Server logging SHOULD be to separate hosts which SHOULD
protected similarly to the root servers themselves
3.2.8 The server SHOULD be protected from attacks based
source routing. The server MUST NOT rely on address-
name-based authentication
3.2.9 The network on which the server is homed SHOULD
in-addr.arpa service
3.3 Protocol authentication and security are required to ensure
data presented by the root servers are those created by
authorized to maintain the root zone data
Bush, et al. Best Current Practice [Page 5]
RFC 2870 Root Name Server Operational Requirements June 2000
3.3.1 The root zone MUST be signed by the Internet
Numbers Authority (IANA) in accordance with DNSSEC,
[RFC2535] or its replacements. It is understood
DNSSEC is not yet deployable on some common platforms,
will be deployed when supported
3.3.2 Root servers MUST be DNSSEC-capable so that queries may
authenticated by clients with security and
concerns. It is understood that DNSSEC is not
deployable on some common platforms, but will be
when supported
3.3.3 Transfer of the root zone between root servers MUST
authenticated and be as secure as reasonably possible
Out of band security validation of updates MUST
supported. Servers MUST use DNSSEC to authenticate
zones received from other servers. It is understood
DNSSEC is not yet deployable on some common platforms,
will be deployed when supported
3.3.4 A 'hidden primary' server, which only allows access by
authorized secondary root servers, MAY be used
3.3.5 Root zone updates SHOULD only progress after a number
heuristic checks designed to detect erroneous updates
been passed. In case the update fails the tests,
intervention MUST be requested
3.3.6 Root zone updates SHOULD normally be effective no
than 6 hours from notification of the root
operator
3.3.7 A special procedure for emergency updates SHOULD
defined. Updates initiated by the emergency
SHOULD be made no later than 12 hours after notification
3.3.8 In the advent of a critical network failure, each
server MUST have a method to update the root zone data
a medium which is delivered through an alternative, non
network, path
3.3.9 Each root MUST keep global statistics on the amount
types of queries received/answered on a daily basis.
statistics must be made available to RSSAC and
sponsored researchers to help determine how to
deploy these machines more efficiently across
Bush, et al. Best Current Practice [Page 6]
RFC 2870 Root Name Server Operational Requirements June 2000
internet. Each root MAY collect data snapshots to
determine data points such as DNS query storms
significant implementation bugs, etc
4.
Communications and coordination between root server operators
between the operators and the IANA and ICANN are necessary
4.1 Planned outages and other down times SHOULD be
between root server operators to ensure that a significant
of the root servers are not all down at the same time
Preannouncement of planned outages also keeps other
from wasting time wondering about any anomalies
4.2 Root server operators SHOULD coordinate backup timing so
many servers are not off-line being backed up at the same time
Backups SHOULD be frequently transferred off site
4.3 Root server operators SHOULD exchange log files, particularly
they relate to security, loading, and other significant events
This MAY be through a central log coordination point, or MAY
informal
4.4 Statistics as they concern usage rates, loading, and
utilization SHOULD be exchanged between operators, and MUST
reported to the IANA for planning and reporting purposes
4.5 Root name server administrative personnel MUST be available
provide service 24 hours a day, 7 days per week. On
personnel MAY be used to provide this service outside of
working hours
5.
The authors would like to thank Scott Bradner, Robert Elz,
Fletcher, John Klensin, Steve Bellovin, and Vern Paxson for
constructive comments
Bush, et al. Best Current Practice [Page 7]
RFC 2870 Root Name Server Operational Requirements June 2000
6.
[RFC1035] Mockapetris, P., "Domain names - implementation
specification", STD 13, RFC 1035, November 1987.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the
Specification", RFC 2181, July 1997.
[RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System
Extensions", RFC 2535, March 1999.
Bush, et al. Best Current Practice [Page 8]
RFC 2870 Root Name Server Operational Requirements June 2000
7. Authors'
Randy
Verio, Inc
5147 Crystal
Bainbridge Island, WA US-98110
Phone: +1 206 780 0431
EMail: randy@psg.
Daniel
RIPE Network Coordination Centre (NCC
Singel 258
NL-1016 AB
Phone: +31 20 535 4444
EMail: daniel.karrenberg@ripe.
Mark
Network
505 Huntmar Park
Herndon, VA 22070-5100
Phone: +1 703 742 0400
EMail: markk@netsol.
Raymond
1710 Goodridge
McLean, Virginia 22102
+1 703 821 6535
EMail: plzakr@saic.
8. Specification of
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
Bush, et al. Best Current Practice [Page 9]
RFC 2870 Root Name Server Operational Requirements June 2000
9. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Bush, et al. Best Current Practice [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
