draft-ietf-dnsop-root-opreq-03.txt   draft-ietf-dnsop-root-opreq-04.txt 
dnsop Randy Bush dnsop Randy Bush
INTERNET-DRAFT Verio INTERNET-DRAFT Verio
draft-ietf-dnsop-root-opreq-03.txt Daniel Karrenberg draft-ietf-dnsop-root-opreq-04.txt Daniel Karrenberg
December 1999 RIPE/NCC March 2000 RIPE/NCC
Mark Kosters Mark Kosters
Network Solutions Network Solutions
Raymond Plzak Raymond Plzak
SAIC SAIC
Root Name Server Operational Requirements Root Name Server Operational Requirements
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
volunteers. This document does not propose to change that, but volunteers. This document does not propose to change that, but
merely to provide formal guidelines so that the community understands merely to provide formal guidelines so that the community understands
how and why this is done. how and why this is done.
1.1 The ICANN has become responsible for the operation of the root 1.1 The ICANN has become responsible for the operation of the root
servers. The ICANN has appointed a Root Server System Advisory servers. The ICANN has appointed a Root Server System Advisory
Committee (RSSAC) to give technical and operational advice to the Committee (RSSAC) to give technical and operational advice to the
ICANN board. The ICANN and the RSSAC look to the IETF to provide ICANN board. The ICANN and the RSSAC look to the IETF to provide
engineering standards. engineering standards.
1.2 The root servers serve the root, aka 'dot', zone. Although today 1.2 The root servers serve the root, aka ".", zone. Although today
some of the root servers also serve some TLDs (top level domains) some of the root servers also serve some TLDs (top level domains)
such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as
INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE
for Sweden), this is likely to change (see 2.5). for Sweden), this is likely to change (see 2.5).
1.3 The root servers are neither involved with nor dependent upon the 1.3 The root servers are neither involved with nor dependent upon the
'whois' data. 'whois' data.
1.4 The domain name system has proven to be sufficiently robust that 1.4 The domain name system has proven to be sufficiently robust that
we are confident that the, presumably temporary, loss of most of we are confident that the, presumably temporary, loss of most of
skipping to change at page 4, line 6 skipping to change at page 4, line 6
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers. This queries from clients other than other root servers. This
restriction is intended to, among other things, prevent restriction is intended to, among other things, prevent
unnecessary load on the root servers as advice has been heard unnecessary load on the root servers as advice has been heard
such as "To avoid having a corruptable cache, make your server a such as "To avoid having a corruptable cache, make your server a
stealth secondary for the root zone." The root servers MAY put stealth secondary for the root zone." The root servers MAY put
the root zone up for ftp or other access on one or more less the root zone up for ftp or other access on one or more less
critical servers. critical servers.
2.8 Servers MUST generate checksums when sending UDP datagrams and 2.8 Servers MUST generate checksums when sending UDP datagrams and
MUST verify checksums when receiving UDP datagrams. MUST verify checksums when receiving UDP datagrams containing a
non-zero checksum.
3. Security Considerations 3. Security Considerations
The servers need both physical and protocol security as well as The servers need both physical and protocol security as well as
unambiguous authentication of their responses. unambiguous authentication of their responses.
3.1 Physical security MUST be ensured in a manner expected of data 3.1 Physical security MUST be ensured in a manner expected of data
centers critical to a major enterprise. centers critical to a major enterprise.
3.1.1 Whether or not the overall site in which a root server is 3.1.1 Whether or not the overall site in which a root server is
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/