idnits 2.17.1 draft-ietf-dnsop-root-opreq-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2030 (Obsoleted by RFC 4330) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 dnsop Randy Bush 2 INTERNET-DRAFT Verio 3 draft-ietf-dnsop-root-opreq-04.txt Daniel Karrenberg 4 March 2000 RIPE/NCC 5 Mark Kosters 6 Network Solutions 7 Raymond Plzak 8 SAIC 10 Root Name Server Operational Requirements 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 0. Abstract 33 As the internet becomes increasingly critical to the world's social 34 and economic infrastructure, attention has rightly focused on the 35 correct, safe, reliable, and secure operation of the internet 36 infrastructure itself. The root domain name servers are seen as a 37 crucial part of that technical infrastructure. The primary focus of 38 this document is to provide guidelines for operation of the root name 39 servers. Other major zone server operators (gTLDs, ccTLDs, major 40 zones) may also find it useful. These guidelines are intended to 41 meet the perceived societal needs without overly prescribing 42 technical details. 44 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 46 1. Background 48 The resolution of domain names on the internet is critically 49 dependent on the proper, safe, and secure operation of the root 50 domain name servers. Currently, these dozen or so servers are 51 provided and operated by a very competent and trusted group of 52 volunteers. This document does not propose to change that, but 53 merely to provide formal guidelines so that the community understands 54 how and why this is done. 56 1.1 The ICANN has become responsible for the operation of the root 57 servers. The ICANN has appointed a Root Server System Advisory 58 Committee (RSSAC) to give technical and operational advice to the 59 ICANN board. The ICANN and the RSSAC look to the IETF to provide 60 engineering standards. 62 1.2 The root servers serve the root, aka ".", zone. Although today 63 some of the root servers also serve some TLDs (top level domains) 64 such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as 65 INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE 66 for Sweden), this is likely to change (see 2.5). 68 1.3 The root servers are neither involved with nor dependent upon the 69 'whois' data. 71 1.4 The domain name system has proven to be sufficiently robust that 72 we are confident that the, presumably temporary, loss of most of 73 the root servers should not significantly affect operation of the 74 internet. 76 1.5 Experience has shown that the internet is quite vulnerable to 77 incorrect data in the root zone or TLDs. Hence authentication, 78 validation, and security of these data are of great concern. 80 2. The Servers Themselves 82 The following are requirements for the technical details of the root 83 servers themselves: 85 2.1 It would be short-sighted of this document to specify particular 86 hardware, operating systems, or name serving software. 87 Variations in these areas would actually add overall robustness. 89 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 91 2.2 Each server MUST run software which correctly implements the IETF 92 standards for the DNS, currently [RFC1035] [RFC2181]. While 93 there are no formal test suites for standards compliance, the 94 maintainers of software used on root servers are expected to take 95 all reasonable actions to conform to the IETF's then current 96 documented expectations. 98 2.3 At any time, each server MUST be able to handle a load of 99 requests for root data which is three times the measured peak of 100 such requests on the most loaded server in then current normal 101 conditions. This is usually expressed in requests per second. 102 This is intended to ensure continued operation of root services 103 should two thirds of the servers be taken out of operation, 104 whether by intent, accident, or malice. 106 2.4 Each root server should have sufficient connectivity to the 107 internet to support the bandwidth needs of the above requirement. 108 Connectivity to the internet SHOULD be as diverse as possible. 110 Root servers SHOULD have mechanisms in place to accept IP 111 connectivity to the root server from any internet provider 112 delivering connectivity at their own cost. 114 2.5 Servers MUST provide authoritative responses only from the zones 115 they serve. The servers MUST disable recursive lookup, 116 forwarding, or any other function that may allow them to provide 117 cached answers. They also MUST NOT provide secondary service for 118 any zones other than the root and root-servers.net zones. These 119 restrictions help prevent undue load on the root servers and 120 reduce the chance of their caching incorrect data. 122 2.6 Root servers MUST answer queries from any internet host, i.e. may 123 not block root name resolution from any valid IP address, except 124 in the case of queries causing operational problems, in which 125 case the blocking SHOULD last only as long as the problem, and be 126 as specific as reasonably possible. 128 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, 129 queries from clients other than other root servers. This 130 restriction is intended to, among other things, prevent 131 unnecessary load on the root servers as advice has been heard 132 such as "To avoid having a corruptable cache, make your server a 133 stealth secondary for the root zone." The root servers MAY put 134 the root zone up for ftp or other access on one or more less 135 critical servers. 137 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 139 2.8 Servers MUST generate checksums when sending UDP datagrams and 140 MUST verify checksums when receiving UDP datagrams containing a 141 non-zero checksum. 143 3. Security Considerations 145 The servers need both physical and protocol security as well as 146 unambiguous authentication of their responses. 148 3.1 Physical security MUST be ensured in a manner expected of data 149 centers critical to a major enterprise. 151 3.1.1 Whether or not the overall site in which a root server is 152 located has access control, the specific area in which the 153 root server is located MUST have positive access control, 154 i.e. the number of individuals permitted access to the area 155 MUST be limited, controlled, and recorded. At a minimum, 156 control measures SHOULD be either mechanical or electronic 157 locks. Physical security MAY be enhanced by the use of 158 intrusion detection and motion sensors, multiple serial 159 access points, security personnel, etc. 161 3.1.2 Unless there is documentable experience that the local 162 power grid is more reliable than the MTBF of a UPS (i.e. 163 five to ten years), power continuity for at least 48 hours 164 MUST be assured, whether through on-site batteries, on-site 165 power generation, or some combination thereof. This MUST 166 supply the server itself, as well as the infrastructure 167 necessary to connect the server to the internet. There 168 MUST be procedures which ensure that power fallback 169 mechanisms and supplies are tested no less frequently than 170 the specifications and recommendations of the maufacturer. 172 3.1.3 Fire detection and/or retardation MUST be provided. 174 3.1.4 Provision MUST be made for rapid return to operation after 175 an system outage. This SHOULD involve backup of systems 176 software and configuration. But SHOULD also involve backup 177 hardware which is pre-configured and ready to take over 178 operation, which MAY require manual procedures. 180 3.2 Network security should be of the level provided for critical 181 infrastructure of a major commercial enterprise. 183 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 185 3.2.1 The root servers themselves MUST NOT provide services other 186 than root name service e.g. remote internet protocols such 187 as http, telnet, rlogin, ftp, etc. The only login accounts 188 permitted should be for the server administrator(s). 189 "Root" or "privileged user" access MUST NOT be permitted 190 except through an intermediate user account. 192 Servers MUST have a secure mechanism for remote 193 administrative access and maintenance. Failures happen; 194 given the 24x7 support requirement (per 4.5), there will be 195 times when something breaks badly enough that senior 196 wizards will have to connect remotely. Remote logins login 197 MUST be protected by a secure means that is strongly 198 authenticated and encrypted, and sites from which remote 199 login is allowed MUST be protected and hardened. 201 3.2.2 Root name servers SHOULD NOT trust other hosts, except 202 secondary servers trusting the primary server, for matters 203 of authentication, encryption keys, or other access or 204 security information. Trusted key servers for Kerberos, 205 IPSEC, etc, MUST be protected with the same prudence as the 206 root servers. 208 3.2.3 The LAN segment(s) on which a root server is homed MUST NOT 209 also home crackable hosts. I.e. the LAN segments should be 210 switched or routed so there is no possibility of 211 masquerading. Some LAN switches aren't suitable for 212 security purposes, there have been published attacks on 213 their filtering. While these can often be prevented by 214 careful configuration, extreme prudence is recommended. 216 3.2.4 The LAN segment(s) on which a root server is homed SHOULD 217 be separately firewalled or packet filtered to discourage 218 network access to any port other than those needed for name 219 service. 221 3.2.5 The root servers SHOULD have their clocks synchronized via 222 NTP [RFC1305] [RFC2030] or similar mechanisms. For this 223 purpose, servers and their associated firewalls SHOULD 224 allow the root servers to be NTP clients. Root servers 225 MUST NOT act as NTP peers or servers. 227 3.2.6 All attempts at intrusion or other compromise SHOULD be 228 logged, and all such logs from all root servers SHOULD be 229 analysed by a cooperative security team communicating with 230 all server operators to look for patterns, serious 231 attempts, etc. Servers SHOULD log in GMT to facilitate log 232 comparison. 234 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 236 3.2.7 Server logging SHOULD be to separate hosts which SHOULD be 237 protected similarly to the root servers themselves. 239 3.2.8 The server SHOULD be protected from attacks based on source 240 routing. The server MUST NOT rely on address- or name- 241 based authentication. 243 3.2.9 The network on which the server is homed SHOULD have in- 244 addr.arpa service. 246 3.3 Protocol authentication and security are required to ensure that 247 data presented by the root servers are those created by those 248 authorized to maintain the root zone data. 250 3.3.1 The root zone MUST be signed by the IANA in accordance with 251 DNSSEC, see [RFC2535] or its replacements. It is 252 understood that DNSSEC is not yet deployable on some common 253 platforms, but will be deployed when supported. 255 3.3.2 Root servers MUST be DNSSEC-capable so that queries may be 256 authenticated by clients with security and authentication 257 concerns. It is understood that DNSSEC is not yet 258 deployable on some common platforms, but will be deployed 259 when supported. 261 3.3.3 Transfer of the root zone between root servers MUST be 262 authenticated and be as secure as reasonably possible. Out 263 of band security validation of updates MUST be supported. 264 Servers MUST use DNSSEC to authenticate root zones received 265 from other servers. It is understood that DNSSEC is not 266 yet deployable on some common platforms, but will be 267 deployed when supported. 269 3.3.4 A 'hidden primary' server, which only allows access by the 270 authorized secondary root servers, MAY be used. 272 3.3.5 Root zone updates SHOULD only progress after a number of 273 heuristic checks designed to detect erroneous updates have 274 been passed. In case the update fails the tests, human 275 intervention MUST be requested. 277 3.3.6 Root zone updates SHOULD normally be effective no later 278 than 6 hours from notification of the root server operator. 280 3.3.7 A special procedure for emergency updates SHOULD be 281 defined. Updates initiated by the emergency procedure 282 SHOULD be made no later than 12 hours after notification. 284 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 286 3.3.8 In the advent of a critical network failure, each root 287 server MUST have a method to update the root zone data via 288 a medium which is delivered through an alternative, non- 289 network, path. 291 3.3.9 Each root MUST keep global statistics on the amount and 292 types of queries received/answered on a daily basis. These 293 statistics must be made available to RSSAC and RSSAC 294 sponsored researchers to help determine how to better 295 deploy these machines more efficiently across the internet. 296 Each root MAY collect data snapshots to help determine data 297 points such as DNS query storms, significant implementation 298 bugs, etc. 300 4. Communications 302 Communications and coordination between root server operators and 303 between the operators and the IANA and and ICANN are necessary. 305 4.1 Planned outages and other down times SHOULD be coordinated 306 between root server operators to ensure that a significant number 307 of the root servers are not all down at the same time. 308 Preannouncement of planned outages also keeps other operators 309 from wasting time wondering about any anomalies. 311 4.2 Root server operators SHOULD coordinate backup timing so that 312 many servers are not off-line being backed up at the same time. 313 Backups SHOULD be frequently transferred off site. 315 4.3 Root server operators SHOULD exchange log files, particularly as 316 they relate to security, loading, and other significant events. 317 This MAY be through a central log coordination point, or MAY be 318 informal. 320 4.4 Statistics as they concern usage rates, loading, and resource 321 utilization SHOULD be exchanged between operators, and MUST be 322 reported to the IANA for planning and reporting purposes. 324 4.5 Root name server administrative personnel MUST be available to 325 provide service 24 hours a day, 7 days per week. On call 326 personnel MAY be used to provide this service outside of normal 327 working hours. 329 5. Acknowledgments 331 The authors would like to thank Scott Bradner, Robert Elz, Chris 332 Fletcher, John Klensin, and Steve Bellovin for their constructive 333 comments. 335 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 337 6. References 339 [RFC1035] 340 Domain names - implementation and specification. P.V. Mockapetris. 341 Nov 1987. 343 [RFC1305] 344 Network Time Protocol (Version 3) Specification, Implementation. 345 David L. Mills. Mar 1992 347 [RFC2030] 348 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and 349 OSI. D. Mills. Oct 1996. 351 [RFC2181] 352 Clarifications to the DNS Specification. R. Elz, R. Bush. Jul 353 1997. 355 [RFC2535] 356 Domain Name System Security Extensions. D. Eastlake, 3rd, C. Kauf- 357 man. Mar 1999. 359 7. Authors' Addresses 361 Randy Bush 362 Verio, Inc. 363 5147 Crystal Springs 364 Bainbridge Island, WA US-98110 365 +1 206 780 0431 366 randy@psg.com 368 Daniel Karrenberg 369 RIPE Network Coordination Centre (NCC) 370 Singel 258 371 NL-1016-AB Amsterdam 372 Netherlands 373 EMail: daniel.karrenberg@ripe.net 375 Mark Kosters 376 Network Solutions 377 505 Huntmar Park Drive 378 Herndon, VA 22070-5100 379 +1 703 742 0400 380 markk@internic.net 382 INTERNET-DRAFT Root Name Server Operational Requirements 00.03.04 384 Raymond Plzak 385 SAIC 386 1710 Goodridge Drive 387 McLean, Virginia 22102 388 +1 703 821 6535 389 plzakr@saic.com 391 8. Specification of Requirements 393 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 394 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 395 document are to be interpreted as described in RFC 2119. 397 9. Full Copyright Statement 399 Copyright (C) The Internet Society (1999). All Rights Reserved. 401 This document and translations of it may be copied and furnished to others, 402 and derivative works that comment on or otherwise explain it or assist in 403 its implementation may be prepared, copied, published and distributed, in 404 whole or in part, without restriction of any kind, provided that the above 405 copyright notice and this paragraph are included on all such copies and 406 derivative works. However, this document itself may not be modified in any 407 way, such as by removing the copyright notice or references to the Internet 408 Society or other Internet organizations, except as needed for the purpose of 409 developing Internet standards in which case the procedures for copyrights 410 defined in the Internet Standards process must be followed, or as required 411 to translate it into languages other than English. 413 The limited permissions granted above are perpetual and will not be revoked 414 by the Internet Society or its successors or assigns. 416 This document and the information contained herein is provided on an "AS IS" 417 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 418 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 419 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 420 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 421 PARTICULAR PURPOSE.