To:
Lars-Johan Liman <liman@sunet.se>
Cc:
dnsop@cafax.se
From:
Randy Bush <randy@psg.com>
Date:
Wed, 01 Dec 1999 07:49:23 -0800
Sender:
owner-dnsop@cafax.se
Subject:
Re: Last WG call for draft-ietf-dnsop-root-opreq-02.txt.
> draft-ietf-dnsop-root-opreq-02.txt steve bellovin had some comments which have caused an -03 version which i will be sending in later today. the changes are minor. *************** *** 233,242 **** as http, telnet, rlogin, ftp, etc. The only login accounts permitted should be for the server administrator(s). "Root" or "privileged user" access MUST NOT be permitted ! except through an intermediate user account. If remote ! access is required for administration and maintenance then ! the login MUST be protected by a secure means that is ! strongly authenticated and encrypted. 3.2.2 Root name servers SHOULD NOT trust other hosts, except secondary servers trusting the primary server, for matters --- 233,248 ---- as http, telnet, rlogin, ftp, etc. The only login accounts permitted should be for the server administrator(s). "Root" or "privileged user" access MUST NOT be permitted ! except through an intermediate user account. ! ! Servers MUST have a secure mechanism for remote ! 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 secondary servers trusting the primary server, for matters *************** *** 248,254 **** 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 switched or routed so there is no possibility of ! masquerading. 3.2.4 The LAN segment(s) on which a root server is homed SHOULD be separately firewalled or packet filtered to discourage --- 254,263 ---- 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 switched or routed so there is no possibility of ! 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 be separately firewalled or packet filtered to discourage *************** *** 268,289 **** attempts, etc. Servers SHOULD log in GMT to facilitate log comparison. 3.2.7 Server logging SHOULD be to separate hosts which SHOULD be protected similarly to the root servers themselves. 3.2.8 The server SHOULD be protected from attacks based on source ! routing. 3.2.9 The network on which the server is homed SHOULD have in- addr.arpa service. 3.3 Protocol authentication and security are required to ensure that data presented by the root servers are those created by those authorized to maintain the root zone data. --- 277,299 ---- attempts, etc. Servers SHOULD log in GMT to facilitate log comparison. 3.2.7 Server logging SHOULD be to separate hosts which SHOULD be protected similarly to the root servers themselves. 3.2.8 The server SHOULD be protected from attacks based on source ! 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- addr.arpa service. 3.3 Protocol authentication and security are required to ensure that data presented by the root servers are those created by those authorized to maintain the root zone data. *************** *** 300,306 **** when supported. 3.3.3 Transfer of the root zone between root servers MUST be ! authenticated and be as secure as reasonably possible. Servers MUST use DNSSEC to authenticate root zones received from other servers. It is understood that DNSSEC is not yet deployable on some common platforms, but will be --- 310,317 ---- when supported. 3.3.3 Transfer of the root zone between root servers MUST be ! 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 from other servers. It is understood that DNSSEC is not yet deployable on some common platforms, but will be *************** *** 422,428 **** Singel 258 NL-1016-AB Amsterdam Netherlands ! EMail: dfk@ripe.net Mark Kosters Network Solutions --- 432,438 ---- Singel 258 NL-1016-AB Amsterdam Netherlands ! EMail: daniel.karrenberg@ripe.net Mark Kosters Network Solutions ***************