idnits 2.17.1 draft-rssac-dnsop-rfc2870bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 586 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 117 instances of too long lines in the document, the longest one being 24 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 255 has weird spacing: '... likely there...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (06 February 2012) is 4457 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TSIG-7' is mentioned on line 133, but not defined == Missing Reference: 'ROOTSERVERS' is mentioned on line 154, but not defined == Missing Reference: 'RFC2136' is mentioned on line 198, but not defined == Missing Reference: 'RFC3007' is mentioned on line 199, but not defined ** Obsolete normative reference: RFC 2845 (ref. '4') (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '6') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4330 (ref. '7') (Obsoleted by RFC 5905) -- Duplicate reference: RFC4035, mentioned in '14', was also mentioned in '10'. Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Operations Root Server System Advisory Committee 2 Internet-Draft 3 Intended status: Informational 4 Expires: 2012 July 24 06 February 2012 5 Replaces RFCs 2010, 2870 7 Root Name Server Operational Requirements 8 draft-rssac-dnsop-rfc2870bis-04 10 Status of this Memo 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on July 24, 2012. 30 IETF Legal Notices 32 Copyright (c) 2011 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 "This document is subject to the rights, licenses and restrictions 45 contained in BCP 78, and except as set forth therein, the authors 46 retain all their rights." 48 "This document and the information contained herein are provided on an 49 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 50 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 51 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 52 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 53 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 54 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 55 FOR A PARTICULAR PURPOSE." 57 "The IETF takes no position regarding the validity or scope of any 58 Intellectual Property Rights or other rights that might be claimed 59 to pertain to the implementation or use of the technology described 60 in this document or the extent to which any license under such 61 rights might or might not be available; nor does it represent that 62 it has made any independent effort to identify any such rights. 63 Information on the procedures with respect to rights in RFC 64 documents can be found in BCP 78 and BCP 79." 66 "Copies of IPR disclosures made to the IETF Secretariat and any 67 assurances of licenses to be made available, or the result of an 68 attempt made to obtain a general license or permission for the use 69 of such proprietary rights by implementers or users of this 70 specification can be obtained from the IETF on-line IPR repository 71 at http://www.ietf.org/ipr." 73 "The IETF invites any interested party to bring to its attention any 74 copyrights, patents or patent applications, or other proprietary 75 rights that may cover technology that may be required to implement 76 this standard. Please address the information to the IETF at 77 ietf-ipr@ietf.org." 79 Abstract 81 As the Internet has become critical to the world's social and economic 82 infrastructure, attention has focused on the correct, safe, reliable, and 83 secure operation of the Internet infrastructure itself. The DNS is considered 84 a crucial part of that technical infrastructure. The root domain and its 85 authoritative name servers are a part of that technical infrastructure. 87 The primary focus of this document is to provide guidelines for secure, stable, 88 and resilient authoritative name service for the root zone. Additionally it will 89 look into some specifics for the operation of the name servers. Other operators 90 of authoritative name servers such as those for generic top-level domains (gTLDs), 91 country code top-level domains (ccTLDs) and other zones may also find this 92 document useful. 94 1. Background 96 The resolution of domain names on the Internet is critically 97 dependent on the proper, safe and secure operation of the root domain 98 name servers. The Internet Assigned Numbers Authority functions operator (IANA) 99 publishes the "root hints" file [HINTS] which lists the names and 100 IP addresses of the thirteen authoritative root name servers that are the focus of 101 this document. This document uses the term "server" to refer to the many ways a root 102 operator provisions to provide root name service, irrespective of 103 physical platform, IP address family or number of concurrent processes. This document 104 provides guidelines for the operation of these root name servers to enable robust 105 and resilient DNS service for the root zone. The root zone service is provided by 106 the root servers operating under the following general characteristics. It is expected 107 that current practice will continue to evolve and we expect future revisions to this 108 work. 110 1.1 The Internet Corporation for Names and Numbers (ICANN) has appointed 111 a Root Server System Advisory Committee 112 (RSSAC) (http://www.icann.org/committees/dns-root/) to give 113 technical and operational advice to the ICANN board. ICANN and 114 RSSAC expect to use engineering standards developed within the IETF. 116 1.2 The root servers serve the root (".") and ROOT-SERVERS.NET 117 zones. For legacy reasons, some of the root servers have also 118 served other important zones. In the future, the data served by root 119 servers may change after careful review by RSSAC and ICANN. 121 1.3 The root servers are neither involved with nor dependent upon 122 any WHOIS [5] data. 124 1.4 The domain name system has proven to be sufficiently robust 125 that the temporary simultaneous loss of a number of the root server instances 126 has not significantly affect secure and stable operation of the Internet. 128 1.5 Experience has shown that the Internet is quite vulnerable to 129 incorrect data in the root zone or top-level domain (TLD) 130 zones. Authentication, validation, and security of these data and the 131 communications channels they transit are to be considered possible 132 vulnerabilities. The root server operators have taken steps to harden the 133 communications channels these data transit. [TSIG-7] 135 1.6 Many of the root operators provision more than one physical or logical host 136 to provide root name service. [ROOTSERVERS] In such configurations, incoming 137 DNS queries to the IP address providing root name service are distributed to 138 multiple hosts using a variety of architectural techniques, including 139 layer-three load balancing devices, equal-cost multipath routing and Anycast 140 routing. (Anycast is discussed further in Section 4.) 142 Since this document is not normative, the key word "MUST", "MUST NOT", "REQUIRED", 143 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 144 in this document MAY be interpreted as described in RFC 2119 [1]. 146 2. The Servers Themselves 148 The following are current practice for the technical details of the root 149 servers themselves: 151 2.1 Maintaining overall robustness and resilience of the root server system is 152 accomplished by the root server operators by coordinating a heterogeneity of 153 hardware, operating systems, topology, or name serving software across all 154 of the root name server nodes. [ROOTSERVERS] 156 2.2 Each server runs software which correctly implements the 157 IETF standards for the DNS, currently RFC1035 [2], RFC2181 158 [3] and RFC4035[14]. While there are no accepted, formal test suites 159 for standards compliance, the maintainers of software used on root servers 160 are expected to take all reasonable actions to conform to the 161 IETF's then-current documented expectations. 163 2.3 At any time, each server should be able to handle a load of 164 requests for root data which is at least ten times the measured 165 average number of requests on that server in then-current 166 normal conditions. This capacity is usually expressed in 167 queries per second. This specification is intended to ensure 168 continued operation of root services in the event of extreme 169 scenarios, such as distributed denial-of-service (DDoS) attacks 170 and other operational anomalies. 172 2.4 Each root server should have sufficient connectivity to the 173 Internet to support the bandwidth needs of the above 174 specification. Connectivity to the Internet should be as diverse 175 as possible. While reasonable efforts to ensure that the service is 176 available Internet-wide, events do occur which prevent some nodes from 177 receiving the Root DNS service. These events are out of scope of this 178 document. They may include ISP or end-site misconfiguration, route 179 hi-jacking, routing system problems, DNS redirection or blocking, and 180 congestion in the intermediate ISPs. This is not an exaustive list. 182 2.5 Servers must provide authoritative responses only from the 183 zones they serve. The servers must disable recursive lookup, 184 forwarding or any other function that might allow them to 185 provide cached answers. For root servers, there IS no place 186 to recurse to and they get no answers from other servers to cache. 187 The response packets should have reasonable IP TTL/IPv6 Hop-Limit 188 values. 64 is current suggested value. The value may be modified by 189 future events. 191 2.6 Root servers must answer queries from any Internet host, i.e. 192 root servers may not block root name resolution from any valid 193 IP address regardless of address family, except in the case of 194 queries causing operational problems, in which case the blocking 195 should last only as long as the problem, and be as specific as 196 reasonably possible. Root servers must answer queries from the 197 same address family as the query. Root servers may filter any Dynamic 198 Update requests [RFC2136]. They must not accept requested changes unless 199 sent from an authorized sources with appropriate authentication [RFC3007]. 201 2.7 Root servers may choose to disallow AXFR, or other zone transfer, 202 queries from clients other than other root servers. This 203 restriction is intended to prevent unnecessary load on the root servers. 204 Operators may choose to rate limit traffic bases on protocol. 206 2.8 Servers must generate checksums when sending UDP datagrams and 207 must verify checksums when receiving UDP datagrams containing a 208 non-zero checksum. 210 3. Security Considerations 212 The servers need both physical and protocol security as well as 213 unambiguous authentication of their responses. Physical security focuses 214 on the machines and their locations, Protocol security and response 215 authentication are covered by Internet Protocol standards. 217 3.1. Physical Security 219 Physical security will be commensurate to a level expected of data 220 centers housing mission critical services. Given the global distribution 221 of hardware platforms, these levels may vary. 223 3.1.1 Whether or not the overall site in which a root server instance 224 is located has access control, the specific area in which the 225 root server is located must have positive access control. 226 At a minimum control measures should be either mechanical or electronic 227 locks. Physical security may be enhanced by the use of 228 intrusion detection and motion sensors, multiple serial 229 access points, security personnel, etc. 231 3.1.2 Power continuity for at least 24 hours should be assured, 232 whether through on-site batteries, on-site power generation 233 or some combination thereof. There must be procedures that ensure 234 the power fallback mechanisms and supplies are tested no less 235 frequently than the specifications and recommendations of the manufacturer. 237 3.1.3 Fire detection and/or retardation must be provided. 239 3.1.4 Provision must be made for rapid return to operation after a 240 system outage. Such provision should involve backup of 241 system software and configuration but may also involve 242 backup hardware which is pre-configured and ready to take 243 over operation, which may require manual procedures. 245 3.2. Network Security 247 Network security should be of the level provided for critical 248 infrastructure of a major commercial enterprise. 250 3.2.1 The root servers should not provide services other 251 than DNS name service, secure shell for management, and network time 252 for TSIG and DNSSEC synchronization, e.g. 253 protocols such as HTTP, Telnet, rlogin, FTP, routing daemons, 254 etc. The rational for this argument is that the fewer services running, 255 the less likely there will be interference from non-DNS related events. 256 The only login accounts permitted should be for the server administrator(s). 258 Servers should have a secure mechanism for remote 259 administrative access and maintenance. Failures happen; 260 there will be times when something breaks badly enough that 261 administrators will need to connect remotely. Remote logins 262 should be protected by a secure means that is strongly 263 authenticated and encrypted, and locations from which remote 264 login is allowed should be protected and hardened. Remote 265 logins should be restricted to a list of discrete IP 266 addresses or address ranges. 268 3.2.2 Root name servers should not trust other hosts, except 269 servers presenting validated credentials, for matters of 270 network time, authentication, encryption keys, or other access 271 or security information. If a root operator uses Kerberos authentication 272 to manage access to the root server, then the associated 273 Kerberos key server must be protected with the same prudence 274 as the root server itself. This applies to all related 275 services which are trusted in any manner. 277 3.2.3 The broadcast domain on which a root server node is located should not 278 also have other Internet-reachable hosts. Secure monitoring 279 hosts that passively monitor network traffic to and from the 280 root server may be placed in the same broadcast domain. Broadcast domains 281 should be switched or routed so there is less possibility of masquerading. 283 3.2.4 The broadcast domain(s) in which a root server node is located should 284 be separately firewalled or packet filtered to prohibit network access 285 to any port other than those needed for name service and administration. 286 State-based firewalls for filters should be avoided as they create a DoS 287 point in DNS resolution. 289 3.2.5 The root servers should have their clocks synchronized via 290 NTP [6], SNTP [7] or similar mechanisms, in as secure manner 291 as possible. For this purpose, servers and their associated 292 firewalls should allow the root servers to be NTP clients. 293 Root servers must not act as NTP peers or servers. 295 3.2.6 All attempts at intrusion or other compromise should be 296 logged, and all such logs from all root servers may be 297 analyzed by a cooperative security team communicating with 298 all server operators to look for patterns, serious attempts, 299 etc. Logs must available in UTC to facilitate log comparison. 301 3.2.7 Server logging may be to separate hosts which should be 302 protected similarly to the root servers themselves. 304 3.2.8 The server should be protected from attacks based on source 305 routing. The server must not solely rely on address- or name-based 306 authentication. 308 3.2.9 The network on which the server is located should have accurate 309 reverse maps in both in-addr.arpa and ip6.arpa. This is to ensure a 310 valid PTR is returned for the root name servers. 312 3.3. Protocol Authentication and Security 314 Protocol authentication and security should be to ensure that data 315 presented by the root servers are those created by those authorized 316 to maintain the root zone data. 318 3.3.1 The root zone should be signed and maintained by the US Depoartment of 319 Commerce contractor in accordance with current DNSSEC specifications 320 ([8], [9] and [10]) and practice. 322 3.3.2 The root servers must be DNSSEC-capable so that queries may be 323 authenticated by clients with security and authentication concerns. 325 3.3.3 Transfer of the root zone between root servers must be 326 authenticated and be as secure as reasonably possible. Out 327 of band security validation of updates should be supported. 328 Root server operators have agreed to use TSIG [4] to authenticate 329 root zone distribution from authorized sources. 331 3.3.4 A "distribution" server, which only allows access by the 332 authorized secondary root servers, may be used. 334 3.3.5 Root zone updates should only progress after one or more 335 heuristic checks designed to detect erroneous updates have 336 been passed. In case the update fails the tests, human 337 intervention must be requested and the last known good zone 338 published. This is to mitigate the rare but occasional error 339 root zone generation / transmission. 341 3.3.6 Root zone updates should normally be effective no later than 342 one fourth of the time between root zone updates from notification 343 of the root server operator, based on the current update cycle of 344 a scheduled update every 12 hours. 346 3.3.7 A special procedure for emergency updates of the root zone should 347 be defined by either the root server operators and/or RSSAC. 348 Updates initiated by the emergency procedure should be made 349 no later than 12 hours after notification. 351 3.3.8 In the event of a critical network failure, each root server 352 must have a method to update the root zone data via a medium 353 which is delivered through an alternative, non-network, 354 path. In the event that the root server cannot serve 355 current data, it must cease offering DNS service. See also 356 Paragraph 4.3. 358 3.3.9 Each root should keep global statistics on the amount and 359 types of queries received/answered on a daily basis. These 360 statistics may be made available to RSSAC and RSSAC- 361 sponsored researchers to help determine how to better deploy 362 these machines more efficiently across the Internet. Each 363 root may collect data snapshots to help determine data 364 points such as DNS query storms, significant implementation 365 bugs, etc. This would be a first step in developing a consistent 366 data collection profile for the root zone. 368 3.3.10 Each root operator must monitor its server to detect operational 369 problems, such as a host being down, a host not running a 370 name server, a name server not returning authoritative 371 answers for the root zone, etc. Servers may also be 372 monitored from an external network. These monitoring 373 processes could be automated. If problems are detected, 374 the appropriate staff should be notified to troubleshoot and 375 remedy the problem. 377 4. Anycast and Network Considerations 379 The root zone has been available via shared unicast as described in 380 RFC 3258 [11] from several of the authoritative root name servers 381 since 2002. This technique is now commonly referred to as "anycast", 382 despite its differences from the definition of that term in RFC 4786 383 [12]. Anycast has proven to be a successful method for increasing 384 the capacity and geographic distribution of the root server system. 385 For a root server to offer service successfully using anycast, 386 several current practices should be followed. 388 4.1 A root server should be anycast using IPv4 address space that is a 389 /24 from pre-RIR allocations. Using any prefix longer than a /20 that 390 is not from the this range risks reachability problems because of 391 filtering by ISPs who won't route such address space. IPv6 address space 392 should be at least a /48. Root server nodes be numbered (v4 and v6) using 393 addresses covered by routes that have been tested and are believed to 394 propagate globally. 396 4.2 Each of a root server's anycast instances may be sourced 397 from a consistent origin autonomous system (AS). That is, the 398 BGP routing announcement for all instances of a given root 399 server's service address (i.e., the IPv4 address corresponding 400 to the RDATA of that root name server's NS record) should have 401 the same origin AS. 403 4.3 Each anycast instance of a root server must withdraw its BGP 404 routing announcement upon service failure. Each anycast 405 instance must monitor its ability to provide root name service 406 and withdraw its route if it detects itself unable to provide 407 service. Such monitoring may be automatic and not dependent 408 on a human noticing a service failure. 410 4.4 Anycast instances using BGP should not use the BGP MULTI_EXIT_DISC (MED) 411 attribute because of possible inter-domain routing (IDR) 412 oscillation in networks using route reflectors or AS 413 confederations. Suggested better alternatives are BGP origin 414 code, altering AS path length (i.e., prepending), adjusting 415 local preference and communities. Specific route oscillation 416 scenarios and mitigations are described in detail in RFC 3345 417 [13]. 419 4.5 Some root operators provision different kinds of anycast 420 instances for a given root server. Some instances are 421 designated to be local to particular autonomous systems and 422 thus advertise their routes with the BGP no-export community 423 attribute. Other instances are designated "global" and 424 reachable from anywhere on the Internet; these instances do not 425 advertise with no-export. In the event of this configuration, 426 the local and global instances should not advertise routes with 427 the same prefix length. The global instances should advertise 428 a shorter covering prefix. 430 Failure to advertise a shorter covering prefix from the global 431 instances can result in unreachability in certain scenarios. 432 For example, consider AS A with a local root server anycast 433 instance (i.e., advertising its route with the no-export 434 attribute) announced as prefix P1. AS A prefers its local 435 route to P1 over the other paths to P1 it may have received 436 (corresponding to any global nodes). Now consider AS B that 437 peers only with AS A. Since the local instance of prefix P1 is 438 the best path and is marked no-export, AS A does not send this 439 prefix to AS B. AS B thus has no route to prefix P1 and cannot 440 reach any instances of this root server. 442 Instead, consider if the root server operator advertised a 443 shorter covering prefix P2 for its global instances. In the 444 scenario above, AS A would send prefix P2 to AS B, making any 445 of this root server's global instances reachable from AS B. 447 For IPv4, if the root server prefix is a globally routable /24, and the 448 operator does not have the necessary adjacent address space to 449 aggregate and advertise a shorter prefix, the /24 itself should 450 be advertised globally and a longer prefix (i.e., /25 or 451 longer) designated local-only. Such a longer local-only prefix 452 will not typically be passed across peering boundaries, which 453 eliminates the need to tag this prefix as no-export. 455 4.6 Root server nodes should be deployed with the highest "splay" possible 456 from other root server nodes. Such deployments will ensure the highest 457 level of service since there will be less fate sharing due to common 458 topology failures, power grid shutdowns, seismic events or other localized 459 disruptions. RFC 1281 describe failures due to fate sharing. Root server 460 operators monitor performance of their service from many locations, and 461 take appropriate steps to maximize their service availability. 463 5. Communications 465 Communications and coordination between root server operators and 466 between the operators and IANA and ICANN are necessary. 468 5.1 Planned outages and other scheduled maintenance times should be coordinated 469 between root server operators to ensure that a significant 470 number of the root servers are not all unavailable at the same time. 471 Announcement of planned outages also keeps other operators from 472 investigated a scheduled maintenance window. 474 5.2 Root server operators may exchange log files, particularly 475 as they relate to security, loading, and other significant 476 events. This may be through a central log coordination point, 477 or may be informal. 479 5.3 Statistics as they concern usage rates, loading, and resource 480 utilization may be exchanged between operators, and may 481 be reported to IANA for planning and reporting purposes. 483 5.4 Root name server administrative personnel must be available to 484 provide service 24 hours a day, 7 days per week. On call 485 personnel may be used to provide this service outside of normal 486 working hours. 488 6. IANA considerations 490 There are no new IANA considerations introduced by this memo. 492 7. Internationalization considerations 494 There are no new internationalization considerations introduced by 495 this memo. 497 8. Acknowledgements 499 This work originated with the original root server requirements document and 500 has been substantially updated and revised. Thanks to Bill Manning, Paul Vixie, 501 Mark Kosters and Matt Larson for much of the text and RSSAC for its review. 502 Specific comments were received from Howard Kash, Jim Cassells, Akira Kato, 503 Shinta Sato, Dave Swager, Terry Manderson, David Conrad, Warren Kumari, Ed Lewis, 504 and John Dickinson. 506 9. References 508 9.1. Normative References 510 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 511 Levels", BCP 14, RFC 2119, March 1997. 513 [2] Mockapetris, P., "Domain names - implementation and 514 specification", STD 13, RFC 1035, November 1987. 516 [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 517 RFC 2181, July 1997. 519 [4] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 520 "Secret Key Transaction Authentication for DNS (TSIG)", 521 RFC 2845, May 2000. 523 9.2. Informative References 525 [5] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 526 September 2004. 528 [6] Mills, D., "Network Time Protocol (Version 3) Specification, 529 Implementation", RFC 1305, March 1992. 531 [7] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 532 IPv4, IPv6 and OSI", RFC 4330, January 2006. 534 [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 535 "DNS Security Introduction and Requirements", RFC 4033, 536 March 2005. 538 [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 539 "Resource Records for the DNS Security Extensions", RFC 4034, 540 March 2005. 542 [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 543 "Protocol Modifications for the DNS Security Extensions", 544 RFC 4035, March 2005. 546 [11] Hardie, T., "Distributing Authoritative Name Servers via Shared 547 Unicast Addresses", RFC 3258, April 2002. 549 [12] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting 550 Service", RFC 1546, November 1993. 552 [13] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border 553 Gateway Protocol (BGP) Persistent Route Oscillation Condition", 554 RFC 3345, August 2002. 556 [14] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Protocol 557 Modifications for the DNS Security Extensions", RFC 4035, March 2005 559 [HINTS] Root Hints authoritative source: http://www.internic.net/zones/named.root 560 checked 20120125 562 Authors' Addresses 564 Root Server System Advisory Committee (RSSAC) 565 567 Bill Manning, Editor 568 PO Box 12317 569 Marina del Rey, CA 90295 570 USA