idnits 2.17.1 draft-hardie-dnsop-shared-root-server-00.txt: 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 309 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 49 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Work-in-progress', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- The document date (June 1999) is 9080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 62 looks like a reference -- Missing reference section? '6' on line 210 looks like a reference -- Missing reference section? 'NTP' on line 278 looks like a reference -- Missing reference section? 'DNS' on line 278 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF DNSOPS working group E.Hardie 2 Internet draft Equinix, Inc 3 Category: Work-in-progress June 1999 5 draft-hardie-dnsop-shared-root-server-00.txt 7 Distributing Root Name Servers via Shared Unicast Addresses 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society 1999. All Rights Reserved. 35 Abstract 37 This memo describes a set of practices designed to enable the 38 distribution of a root DNS server to multiple geographically and 39 topologically distinct network locations. These practices presume 40 that a single entity remains administratively and operationally 41 responsible for each of the distributed servers. 43 The primary motivation for the development of these practices is to 44 increase the availability of root servers. The current root servers 45 already provide a highly distributed mesh, but the concentration of 46 servers in U.S-based networks limits their availbility for users 47 outside North America. These practices should enable the 48 distribution of root servers to areas not historically well-served 49 by the current mesh without disrupting the operation of the DNS. 51 Discussion of methods like those outlined below date back at least 52 to the December 1996 meeting of the IEPG. Recent discussions have 53 taken place on the dnsop@cafax.se mailing list, and an internet 54 draft "Root Name Servers Sharing Administratively Scoped Shared 55 Unicast Addresses" was distributed there by Masataka Ohta. 57 1. Architecture 59 1.1 Server Requirements 61 In addition to meeting the host requirements for root servers listed 62 in [1], each of the hosts should be configured with two network 63 interfaces. One of the network interfaces should use the shared 64 unicast address associated with the root name server. The other 65 interface, referred to as the AS-internal interface below, should 66 use a distinct address specific to that host. The host should 67 respond to DNS queries only on the shared-unicast interface. The 68 host should use the AS-internal interface and address for all mesh 69 coordination. 71 1.2 Zone file delivery 73 In order to minimize the risk of man-in-the-middle attacks, zone 74 files should be delivered to the AS-internal interface of the 75 servers participating in the mesh. Secure file transfer methods and 76 strong authentication should be used for all transfers. 78 1.3 Synchronization 80 As noted below in section 3.2, lack of synchronization among servers 81 could create problems for users of this service. In order to 82 minimize the risk, switch-overs from one data set to another data 83 set should be coordinated. The use of synchronized clocks on the 84 participating hosts and set times for switch-overs provides a basic 85 level of coordination. The full coordination process would involve 86 transferring new data, checking for full receipt of data on all 87 participating hosts, setting switch-over times for all participating 88 hosts, and instituting a failure process to ensure that hosts 89 which did not succeed in switching over ceased to respond to 90 incoming queries. 92 1.4 Server Placement 94 Though the geographic diversity of server placement helps reduce the 95 effects of service disruptions due to local problems, it is 96 diversity of placement in the network topology which is the driving 97 force behind these distribution practices. Server placement should 98 emphasize that diversity. Ideally, servers should be placed 99 topologically near the points at which the operator exchanges routes 100 and traffic with other networks. 102 1.5 Routing 104 The organization administering the mesh of servers sharing a unicast 105 address must have an autonomous system number and speak BGP to its 106 peers. To those peers, the organization announces a route to the 107 network containing the shared-unicast address of the root name 108 server. The organization's border routers must then deliver the 109 traffic destined for the root name server to the nearest 110 instantiation. To avoid internal routing difficulties, a static 111 route to that network is recommended. Routing to the AS-internal 112 interfaces for the servers can use the normal routing methods for 113 the administering organization, but care should be taken that 114 traffic for the AS-internal interfaces does not leak onto the 115 internal networks. 117 Appendix A. contains an ASCII diagram of a simple implementation of 118 this system. In it, the odd numbered routers deliver traffic to the 119 shared-unicast interface network and filter traffic from the 120 AS-internal network; the even numbered routers deliver traffic to 121 the AS-internal network and filter traffic from the shared-unicast 122 network. These are depicted as seperate routers for the ease this 123 gives in explanation, but they could easily be seperate interfaces 124 on the same router. Similarly, a local NTP source is depicted for 125 synchronization, but the level of synchronization needed would not 126 require that source to be either local or a stratum one NTP server. 128 2. Administration 130 2.1 Points of Contact 132 A single point of contact for reporting problems is crucial to the 133 correct administration of this system. If an external user of the 134 system needs to report a problem related to the service, there must 135 be no ambiguity about whom to contact. If internal monitoring does 136 not indicate a problem, the contact may, of course, need to work 137 with the external user to identify which server generated the 138 error. 140 3. Security Considerations 142 As a core piece of internet infrastructure, the root servers are a 143 common target of attack. The practices outlined here increase the 144 risk of certain kinds of attack and reduce the risk of others. 146 3.1 Increased Risks 148 As a first principal, it should be recognized that the architecture 149 outlined in this document increases the number of physical servers 150 acting as roots, which increases the possibility that a server 151 mis-configuration will occur which allows for a security breach. If 152 the mechanism used to distribute zone files among the servers is not 153 well secured, a man-in-the-middle attack could result in the injection 154 of false information. Digital signatures will alleviate this risk, 155 but encrypted transport and tight access lists are a necessary adjunct 156 to them. 158 A fundamental risk in the distribution of data using the methods 159 outlined above is that the servers in the mesh will fall out of 160 synch with one another. The use of ntp to provide a synchronized 161 time for switch-over elminates some aspects of this problem, but 162 mechanisms to handle failure during the switchover are required. 163 In particular, a server which cannot make the switchover must not 164 roll-back to a previous version; it must cease to respond to 165 queries so that other root servers are queried. 167 3.2 Decreased Risks 169 The increase in number of physical servers reduces, however, the 170 likelihood that a denial-of-service attack will take out a 171 significant portion of the DNS infrastructure. The increase in 172 servers also reduces the effect of machine crashes, fiber cuts, and 173 localized disasters by reducing the number of users dependent on on 174 a specific machine. 176 4. Full copyright statement 178 Copyright (C) The Internet Society 1999. All Rights Reserved. 180 This document and translations of it may be copied and furnished to 181 others, and derivative works that comment on or otherwise explain 182 it or assist in its implementation may be prepared, copied, 183 published and distributed, in whole or in part, without restriction 184 of any kind, provided that the above copyright notice and this 185 paragraph are included on all such copies and derivative works. 186 However, this document itself may not be modified in any way, such 187 as by removing the copyright notice or references to the Internet 188 Society or other Internet organizations, except as needed for the 189 purpose of developing Internet standards in which case the 190 procedures for copyrights defined in the Internet Standards process 191 must be followed, or as required to translate it into languages 192 other than English. 194 The limited permissions granted above are perpetual and will not be 195 revoked by the Internet Society or its successors or assigns. 197 This document and the information contained herein is provided on 198 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 199 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 200 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 201 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 202 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 204 5. Acknowledgements 206 Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, 207 Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, and Akira 208 Kato all provided input and commentary on this work. 210 [6]. References 212 1 "Root Name Server Operational Requirements", Randy Bush. 213 ftp://ftp.ietf.org/internet-drafts/draft-bush-dnsop-root-opreq-00.txt 215 7. Editor's address 217 Edward (Ted) Hardie 218 Equinix, Inc. 219 901 Marshall St. 220 Redwood City, CA 94063 221 hardie@equinix.com 222 Tel: 1.650.817.2226 223 Fax: 1.650.298.0420 225 Appendix A. 227 __________________ 228 Peer 1-| | 229 Peer 2-| | 230 Peer 3-| Switch | 231 Transit| | _________ _________ 232 etc | |--|Router1|---|----|--------------|Router2|---WAN-| 233 | | --------- | | --------- | 234 | | | | | 235 | | | | | 236 ------------------ [NTP] [DNS] | 237 | 238 | 239 | 240 | 241 __________________ | 242 Peer 1-| | | 243 Peer 2-| | | 244 Peer 3-| Switch | | 245 Transit| | _________ _________ | 246 etc | |--|Router3|---|----|--------------|Router4|---WAN-| 247 | | --------- | | --------- | 248 | | | | | 249 | | | | | 250 ------------------ [NTP] [DNS] | 251 | 252 | 253 | 254 | 255 __________________ | 256 Peer 1-| | | 257 Peer 2-| | | 258 Peer 3-| Switch | | 259 Transit| | _________ _________ | 260 etc | |--|Router5|---|----|--------------|Router6|---WAN-| 261 | | --------- | | --------- | 262 | | | | | 263 | | | | | 264 ------------------ [NTP] [DNS] | 265 | 266 | 267 | 268 | 269 __________________ | 270 Peer 1-| | | 271 Peer 2-| | | 272 Peer 3-| Switch | | 273 Transit| | _________ _________ | 274 etc | |--|Router7|---|----|--------------|Router8|---WAN-| 275 | | --------- | | --------- 276 | | | | 277 | | | | 278 ------------------ [NTP] [DNS]