draft-ietf-dnsop-root-opreq-02.txt   draft-ietf-dnsop-root-opreq-03.txt 
dnsop Randy Bush dnsop Randy Bush
INTERNET-DRAFT Verio INTERNET-DRAFT Verio
draft-ietf-dnsop-root-opreq-02.txt Daniel Karrenberg draft-ietf-dnsop-root-opreq-03.txt Daniel Karrenberg
November 1999 RIPE/NCC December 1999 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 5, line 10 skipping to change at page 5, line 10
operation, which MAY require manual procedures. operation, which MAY require manual procedures.
3.2 Network security should be of the level provided for critical 3.2 Network security should be of the level provided for critical
infrastructure of a major commercial enterprise. infrastructure of a major commercial enterprise.
3.2.1 The root servers themselves MUST NOT provide services other 3.2.1 The root servers themselves MUST NOT provide services other
than root name service e.g. remote internet protocols such than root name service e.g. remote internet protocols such
as http, telnet, rlogin, ftp, etc. The only login accounts as http, telnet, rlogin, ftp, etc. The only login accounts
permitted should be for the server administrator(s). permitted should be for the server administrator(s).
"Root" or "privileged user" access MUST NOT be permitted "Root" or "privileged user" access MUST NOT be permitted
except through an intermediate user account. If remote except through an intermediate user account.
access is required for administration and maintenance then
the login MUST be protected by a secure means that is Servers MUST have a secure mechanism for remote
strongly authenticated and encrypted. administrative access and maintenance. Failures happen;
given the 24x7 support requirement (per 4.5), there will be
times when something breaks badly enough that senior
wizards will have to connect remotely. Remote logins login
MUST be protected by a secure means that is strongly
authenticated and encrypted, and sites from which remote
login is allowed MUST be protected and hardened.
3.2.2 Root name servers SHOULD NOT trust other hosts, except 3.2.2 Root name servers SHOULD NOT trust other hosts, except
secondary servers trusting the primary server, for matters secondary servers trusting the primary server, for matters
of authentication, encryption keys, or other access or of authentication, encryption keys, or other access or
security information. Trusted key servers for Kerberos, security information. Trusted key servers for Kerberos,
IPSEC, etc, MUST be protected with the same prudence as the IPSEC, etc, MUST be protected with the same prudence as the
root servers. root servers.
3.2.3 The LAN segment(s) on which a root server is homed MUST NOT 3.2.3 The LAN segment(s) on which a root server is homed MUST NOT
also home crackable hosts. I.e. the LAN segments should be also home crackable hosts. I.e. the LAN segments should be
switched or routed so there is no possibility of switched or routed so there is no possibility of
masquerading. masquerading. Some LAN switches aren't suitable for
security purposes, there have been published attacks on
their filtering. While these can often be prevented by
careful configuration, extreme prudence is recommended.
3.2.4 The LAN segment(s) on which a root server is homed SHOULD 3.2.4 The LAN segment(s) on which a root server is homed SHOULD
be separately firewalled or packet filtered to discourage be separately firewalled or packet filtered to discourage
network access to any port other than those needed for name network access to any port other than those needed for name
service. service.
3.2.5 The root servers SHOULD have their clocks synchronized via 3.2.5 The root servers SHOULD have their clocks synchronized via
NTP [RFC1305] [RFC2030] or similar mechanisms. For this NTP [RFC1305] [RFC2030] or similar mechanisms. For this
purpose, servers and their associated firewalls SHOULD purpose, servers and their associated firewalls SHOULD
allow the root servers to be NTP clients. Root servers allow the root servers to be NTP clients. Root servers
skipping to change at page 5, line 49 skipping to change at page 6, line 9
logged, and all such logs from all root servers SHOULD be logged, and all such logs from all root servers SHOULD be
analysed by a cooperative security team communicating with analysed by a cooperative security team communicating with
all server operators to look for patterns, serious all server operators to look for patterns, serious
attempts, etc. Servers SHOULD log in GMT to facilitate log attempts, etc. Servers SHOULD log in GMT to facilitate log
comparison. comparison.
3.2.7 Server logging SHOULD be to separate hosts which SHOULD be 3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
protected similarly to the root servers themselves. protected similarly to the root servers themselves.
3.2.8 The server SHOULD be protected from attacks based on source 3.2.8 The server SHOULD be protected from attacks based on source
routing. routing. The server MUST NOT rely on address- or name-
based authentication.
3.2.9 The network on which the server is homed SHOULD have in- 3.2.9 The network on which the server is homed SHOULD have in-
addr.arpa service. addr.arpa service.
3.3 Protocol authentication and security are required to ensure that 3.3 Protocol authentication and security are required to ensure that
data presented by the root servers are those created by those data presented by the root servers are those created by those
authorized to maintain the root zone data. authorized to maintain the root zone data.
3.3.1 The root zone MUST be signed by the IANA in accordance with 3.3.1 The root zone MUST be signed by the IANA in accordance with
DNSSEC, see [RFC2535] or its replacements. It is DNSSEC, see [RFC2535] or its replacements. It is
understood that DNSSEC is not yet deployable on some common understood that DNSSEC is not yet deployable on some common
platforms, but will be deployed when supported. platforms, but will be deployed when supported.
3.3.2 Root servers MUST be DNSSEC-capable so that queries may be 3.3.2 Root servers MUST be DNSSEC-capable so that queries may be
authenticated by clients with security and authentication authenticated by clients with security and authentication
concerns. It is understood that DNSSEC is not yet concerns. It is understood that DNSSEC is not yet
deployable on some common platforms, but will be deployed deployable on some common platforms, but will be deployed
when supported. when supported.
3.3.3 Transfer of the root zone between root servers MUST be 3.3.3 Transfer of the root zone between root servers MUST be
authenticated and be as secure as reasonably possible. authenticated and be as secure as reasonably possible. Out
of band security validation of updates MUST be supported.
Servers MUST use DNSSEC to authenticate root zones received Servers MUST use DNSSEC to authenticate root zones received
from other servers. It is understood that DNSSEC is not from other servers. It is understood that DNSSEC is not
yet deployable on some common platforms, but will be yet deployable on some common platforms, but will be
deployed when supported. deployed when supported.
3.3.4 A 'hidden primary' server, which only allows access by the 3.3.4 A 'hidden primary' server, which only allows access by the
authorized secondary root servers, MAY be used. authorized secondary root servers, MAY be used.
3.3.5 Root zone updates SHOULD only progress after a number of 3.3.5 Root zone updates SHOULD only progress after a number of
heuristic checks designed to detect erroneous updates have heuristic checks designed to detect erroneous updates have
skipping to change at page 7, line 39 skipping to change at page 7, line 51
reported to the IANA for planning and reporting purposes. reported to the IANA for planning and reporting purposes.
4.5 Root name server administrative personnel MUST be available to 4.5 Root name server administrative personnel MUST be available to
provide service 24 hours a day, 7 days per week. On call provide service 24 hours a day, 7 days per week. On call
personnel MAY be used to provide this service outside of normal personnel MAY be used to provide this service outside of normal
working hours. working hours.
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Scott Bradner, Robert Elz, Chris The authors would like to thank Scott Bradner, Robert Elz, Chris
Fletcher, and John Klensin for their constructive comments. Fletcher, John Klensin, and Steve Bellovin for their constructive
comments.
6. References 6. References
[RFC1035] [RFC1035]
Domain names - implementation and specification. P.V. Mockapetris. Domain names - implementation and specification. P.V. Mockapetris.
Nov 1987. Nov 1987.
[RFC1305] [RFC1305]
Network Time Protocol (Version 3) Specification, Implementation. Network Time Protocol (Version 3) Specification, Implementation.
David L. Mills. Mar 1992 David L. Mills. Mar 1992
skipping to change at page 8, line 31 skipping to change at page 8, line 41
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, WA US-98110 Bainbridge Island, WA US-98110
+1 206 780 0431 +1 206 780 0431
randy@psg.com randy@psg.com
Daniel Karrenberg Daniel Karrenberg
RIPE Network Coordination Centre (NCC) RIPE Network Coordination Centre (NCC)
Singel 258 Singel 258
NL-1016-AB Amsterdam NL-1016-AB Amsterdam
Netherlands Netherlands
EMail: dfk@ripe.net EMail: daniel.karrenberg@ripe.net
Mark Kosters Mark Kosters
Network Solutions Network Solutions
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070-5100 Herndon, VA 22070-5100
+1 703 742 0400 +1 703 742 0400
markk@internic.net markk@internic.net
Raymond Plzak Raymond Plzak
SAIC SAIC
1710 Goodridge Drive 1710 Goodridge Drive
McLean, Virginia 22102 McLean, Virginia 22102
+1 703 821 6535 +1 703 821 6535
plzakr@saic.com plzakr@saic.com
8. Specification of Requirements 8. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 End of changes. 

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