idnits 2.17.1 draft-lee-dnsop-scalingroot-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 62 lines == It seems as if not all pages are separated by form feeds - found 1 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security considerations' ) ** 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 128 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2014) is 3585 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? 'RFC2119' on line 36 looks like a reference -- Missing reference section? '1' on line 404 looks like a reference -- Missing reference section? '2' on line 406 looks like a reference -- Missing reference section? '3' on line 411 looks like a reference -- Missing reference section? '4' on line 414 looks like a reference -- Missing reference section? '5' on line 417 looks like a reference -- Missing reference section? '6' on line 420 looks like a reference -- Missing reference section? '7' on line 423 looks like a reference -- Missing reference section? '8' on line 426 looks like a reference -- Missing reference section? '9' on line 429 looks like a reference -- Missing reference section? 'Root 3' on line 298 looks like a reference -- Missing reference section? '10' on line 432 looks like a reference -- Missing reference section? '11' on line 436 looks like a reference -- Missing reference section? '12' on line 439 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group Xiaodong Lee 3 Internet Draft CNNIC 4 Expires: January 2015 Vixie Paul 5 Farsight Security, Inc. 6 Zhiwei Yan(Ed.) 7 CNNIC 8 July 3, 2014 10 How to scale the DNS root system? 11 draft-lee-dnsop-scalingroot-00.txt 13 Abstract 15 In Domain Name System (DNS), 13 root servers are deployed in order 16 to provide the entrance of domain name resolution and they are 17 denoted by 13 letters. From 2000 or so, the anycast technology has 18 been adopted to extend the number of root servers with the explosive 19 development of Internet. To date, 11 of the 13 letters are hosted at 20 multiple sites, and the root zone is served at about 380 sites 21 around the globe. However, increasing mirror sites is not a perfect 22 solution to scale the DNS root servers because the geographical 23 distribution of the current 13 root servers is uneven and only 24 increasing mirror sites cannot solve the efficiency and scalability 25 issues caused by that. Then we propose a new DNS root system in this 26 draft based on the widely deployed Domain Name System Security 27 Extensions (DNSSEC). The proposed architecture is scalable and 28 secure enough to meet the current and future needs to scale the DNS 29 root system in an easy-deployment way. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with 40 the provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as 50 reference material or to cite them other than as "work in progress". 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 This Internet-Draft will expire on January, 2015. 60 Copyright Notice 62 Copyright (c) 2010 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with 70 respect to this document. Code Components extracted from this 71 document must include Simplified BSD License text as described in 72 Section 4.e of the Trust Legal Provisions and are provided without 73 warranty as described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction ................................................ 2 78 2. Motivations ................................................. 3 79 3. Proposed architecture........................................ 5 80 4. Management considerations.................................... 8 81 5. Security considerations...................................... 9 82 6. References .................................................. 9 83 Author's Address .............................................. 10 84 Acknowledgment ................................................ 11 86 1. Introduction 88 In Domain Name System (DNS), 13 root servers are deployed and they 89 are denoted by 13 letters from A to M. From 2000 or so, the anycast 90 technology has been adopted to extend the number of root servers 91 with the explosive development of Internet. To date, 11 of the 13 92 letters are hosted at multiple sites, and the root zone is served at 93 about 380 sites around the globe [1,2]. 95 With the continuous development of Internet, more and more DNS root 96 servers have to be deployment in order to meet the efficiency and 97 stability requirements of the DNS root system. On one hand, the DNS 98 resolution efficiency should be high enough to support more and more 99 Internet users and their sophisticated applications. On the other 100 hand, the DNS root system has to be stable enough to face the cyber 101 attacks which are becoming more and more serious [3]. Then, how 102 about deploying more anycast mirror sites? Without doubt, this 103 scheme can improve the efficiency and stability of DNS root system 104 as usual, but its problems are: 106 a) This scheme is not open enough to satisfy the special 107 requirements of a country or district or organization (CDO). If a 108 CDO wants to deploy a root server to serve its local users, the 109 current procedure is complex and it is almost impossible for the CDO 110 to control the deployed site no matter the type of the site is local 111 or global. Specially, the current root name servers have respective 112 Root Name Server Operators (RNSOs), to whom IP address blocks have 113 been allocated. The CDO wants a root server mirror site must 114 coordinate anycast routing configuration and server placement with 115 the corresponding RNSO. 117 b) This scheme is not stable enough. When one root server is 118 attacked and fails down, its anycast mirrors cannot do the zone file 119 synchronization and the DNS root service may be affected. 121 2. Motivations 123 During recent years, many CDOs declare their anticipation to host a 124 DNS root server. And how to adjust the placement of the current 13 125 DNS root servers also drew a lot of attention from both academic and 126 technical worlds [2]. However, it's very difficult to change the 127 current belonging situation of DNS root servers. If possible, it's a 128 good idea to deploy more root servers (not just the mirror sites) to 129 solve or relieve the above problems. 131 In the IPv4 based Internet, only 13 root servers are allowed due to 132 the 512-byte limitation. However, adding the IPv6 address 133 information for more than two root name servers will increase the 134 size of the DNS priming response to exceed this maximum. Ultimately, 135 when all 13 root name servers assign IPv6 addresses, the priming 136 response will be increased to 811 bytes [3]. Specially, if a message 137 cannot fit in the 512 bytes, the server must set a special flag 138 indicating that the message was truncated. When receiving such a 139 message, a DNS resolver will normally retry the transaction using 140 TCP instead of UDP [4]. However, the costs of using TCP rather than 141 UDP, in terms of system and network resources, are much higher and 142 can have significant impact on systems such as name servers that may 143 receive several thousands of queries per second during normal 144 operations. At the same time, with the promotion from ICANN, work is 145 in progress to put forward a recommendation that will enable the 146 publication of IPv6 addresses for, at least, DNS root servers in as 147 short a time as possible. Besides, with the exhaustion of IPv4 148 address, the IPv6 is promoted from all parties in the community. 149 Currently, 10 IPv6 addresses have been configured on the root 150 servers and the total size of the DNS priming response message has 151 been increased to above 512 bytes (We even do not consider the 152 DNSSEC herein, which increases the DNS response message more 153 tremendously). 155 Above background means that the 512-byte limitation does not 156 actually exist anymore in the DNS [5]. Then how many DNS root server 157 can be increased further? We take the IPv6 supported Internet as an 158 example, then the DNS priming response message structure is shown in 159 the following if we set the maximum number of root servers is N [6]. 161 --Required Header: 12 bytes 163 --Query: 5 bytes 165 --Answer: 31+15*(N-1) [the first answer is 31 bytes, the sequent 166 answers are reduced by 16 bytes due to compression] 168 --Additional Records: 16*N [each A record is 16 bytes] 170 --Additional Records: 28*N [each AAAA record is 28 bytes] 172 The IPv6 supported node is not required to reduce the size of 173 subsequent packets to less than 1280 bytes, but must include a 174 "Fragment Header" in those packets so that the IPv6-to-IPv4 175 translating router can obtain a suitable "Identification" value to 176 use in resulted IPv4 fragments. Note that this means the payload may 177 have to be reduced to 1232 bytes (1280 minus 40 for the IPv6 header 178 and 8 for the Fragment header) [7]. 180 Then we get the following formula, 182 12+5+31+15*(N-1)+16*N+28*N<1232 184 Accordingly, N=20, which means that the root servers can only be 185 increased by 7 more in the IPv6 transport environment (without EDNS0 186 [8] and TCP supporting). 188 In advance, DNSSEC should be considered because it is necessary to 189 guarantee the security of the DNS information and it has been widely 190 deployed (and will be more widely deployed in the future). If only 191 one kind of signature algorithm is used to generate the RRSIG 192 resource record, the size of DNS response message will be increased 193 to about 7 to 10 times comparing with the original one without 194 signing [9]. It means that it is unpromising to increase the root 195 servers further in the current architecture. 197 In the security aspect, criticisms of the current and historical 198 root name server system is lack of resistance to DDoS attack, noting 199 that even with the current wide scale anycasting by every RNSO, 200 there are still only a few hundred name servers in the world to 201 answer authoritatively for the DNS root zone. We are also concerned 202 that reachability of the root name server system is required even 203 for purely local communication, since otherwise local clients have 204 no way to discover local services. In a world sized distributed 205 system like the Internet, critical services such as DNS root system 206 ought to be extremely well distributed. 208 In a word, we have to design a new architecture to scale the DNS 209 root name server system and in this way the root server deployment 210 balance can be reconsidered (the future deployment can refer the 211 actual requirements such as the number of Internet users, amount of 212 Internet traffic and so on). Besides, this architecture should scale 213 the DNS root servers without the technology limitations as 214 illustrated above. 216 3. Proposed architecture 218 The proposed architecture is strongly based on the widely deployed 219 DNSSEC and shown in Figure 1. With DNSSEC, it is now possible for 220 recursive name server operators to configure DNSSEC validation, such 221 that any gTLD information heard from a root server (or mirror site) 222 must be IANA-approved as indicated by DNSSEC signatures made with 223 IANA's root Zone Signing Key (ZSK). 225 For the universal anycast root server nodes deployment, we here 226 provide two actual solutions: 228 1) 229 The DNS root service manager (may still be the IANA) would 230 generate and digitally sign (with DNSSEC) an additional version of 231 the root zone that has a different set of NS records at its apex. 232 These NS records will denote name servers whose addresses are not 233 assigned to any current RNSO but are instead held in trust by IANA 234 for use by any or all interested CDOs (Global Root X in Figure 1). 235 IANA would request infrastructure micro-allocations from an RIR 236 (such as ARIN or APNIC), as several IPv4 24-bit prefixes and 237 several IPv6 48-bit prefixes, for use in universal anycasting of 238 the root zone. For example, the following configuration can be 239 used corresponding to the universal root server (Global Root X): 241 . IN NS anycast-X1.iana-servers.net. 243 . IN NS anycast-X2.iana-servers.net. 245 $ORIGIN iana-servers.net. 247 anycast-x1 IN AAAA 2001:?:1::1 249 anycast-x1 IN A ?.?.1.1 251 anycast-x2 IN AAAA 2001:?:2::2 253 anycast-x2 IN A ?.?.2.2 255 2) Based on the contract or approval of one or multiple RNSO, the 256 related root server can also be globally anycasted or locally 257 deployed and totally managed and controlled by a CDO (Root A1 in 258 Figure 1). This case is backward-compatible and does not need to 259 change the current DNS root system. 261 +-----------------------+ 262 | Distribution Master | 263 +-----------------------+ 264 / / \ \ 265 / / \ \ 266 +------+ +-------+...+------+ +------+ 267 |Root A|...|Global | |Root M|...|Global| 268 +------+ |Root A1| +------+ |Root X| 269 / +-------+ +------+ 270 / \ \ 271 / \ \ 272 +-------+ +-------+ +------+ 273 |Local | |Local | |Local | 274 |Root A | |Root A1| |Root X| 275 +-------+ +-------+ +------+ 277 Figure 1. DNS root server architecture 279 We herein assume that the DNSSEC is widely deployed. In this way, 280 the root zone file will not be tampered or misused. If the DNS root 281 server is a local site (Local Root A) and only serve for the 282 restricted area, it may be unnecessary for holding the global 283 anycast address. Still in this case, the local site (Local Root A) 284 can also expand its site to multiple mirrors within the local area 285 (for example, within one ISP's coverage) as the global node (Global 286 Root A1) does. 288 Accordingly, the DNS request message may be served by any root sever 289 during its transmission and the possible scenarios are shown in 290 Figure 2. 292 +---------------+ 293 +----+ ( ) 294 |ISP3|--( Backbone ) 295 +----+ ( ) 296 | +---------------+ 297 | | | 298 [Root 3] | | 299 | | 300 | | 301 | | 302 +----+ +----+ 303 [Root 1]--|ISP1|----------|ISP2|--[Root 2] 304 +----+ +----+ 305 Figure 2. DNS resolution scenarios 307 We assume that one ISP only holds one DNS root server. In the first 308 case, the DNS request message originated from the edge user is 309 served by the root server deployed in the local network within the 310 same ISP (Root 1) and then the response can be served as soon as 311 possible. In the second case, the DNS request is transmitted to the 312 nearby ISP due to the routing protocol and responded by the root 313 server in the nearby ISP (Root 2). In the third case, the request 314 may travel all the way to the Internet backbone without having been 315 answered closely, in which case it may be answered by an RNSO who 316 has decided to advertise a route to the well known address of the 317 CDO root server (Root 3). 319 For the data synchronization, the current scheme can be used. After 320 the root zone file is produced, the Distribution Master (DM) (such 321 as the current hidden server) sends a DNS notify message to all root 322 servers and then every root server responds with an acknowledgement 323 to the DM. The DNS notify triggers the Start of Authority (SOA) 324 request. The DM replies with a message which includes the serial 325 number. If this serial number is higher than the number that is 326 currently operated by the root server, the root server starts the 327 Zone Transfer (XFR) to retrieve the new root zone file. If this 328 serial number in the SOA response is not higher than the root 329 server's currently used version, the root server will take no 330 further action. If this scheme is adopted, each CDO root server has 331 to register with the DM in order to receive the notify message and 332 which is the requirement of the first deployment solution 333 illustrated above. While, for the second deployment solution, the DM 334 function may be the root server managed by the current RNSO. 336 Of course, a more open scheme is needed in the future for the root 337 zone file synchronization. Because the root zone file data is solid 338 and cannot be tampered, the CDO can actively fetch the root zone 339 file data according to its special requirement and configuration. We 340 mention this synchronization type because the CDO root servers may 341 be increased significantly in the future and the traditional scheme 342 explained above is not flexible and efficient enough. 344 In a word, DNSSEC makes it possible to deploy the DNS root servers 345 in a more distributed and flat manner, because any server can 346 synchronize the root zone file without modification. 348 4. Management considerations 350 Considering the deployment of the architecture proposed in this 351 draft, the following management questions should be answered: 353 1) How to manage the universal anycast DNS root servers? 355 We introduce the idea to globally distribute the root servers and 356 locally deploy multiple local nodes. In the routing aspect, the 357 anycast addresses will be broadcasted more widely for the global 358 nodes to be accessed anywhere. However, the addresses of the local 359 nodes have to be controlled in the local area (with the no-export 360 attribute in BGP routing protocol) to serve the requests from the 361 particular local area. 363 2) What are the principles to deploy the universal DNS root servers? 365 The principles or rules to select the service provider (CDO) and 366 deploy the root servers can refer to [10,11]. Besides, more actual 367 aspects can be considered in this new architecture due to its 368 minimized limitation to deploy a root server. 370 Other management and deployment issues will be added further. 372 5. Security considerations 374 Although this architecture maintains the basic operations of the 375 current DNS root system and follows the standard DNS protocols, it 376 changes the current DNS root system because we want this mature 377 system to be flexibly scaled with the Internet. Then the following 378 issues related to security and stability may be caused: 380 1) Routing table: according to this architecture, more than 13 root 381 servers may broadcast their IP addresses globally. This will 382 increase the entries of the BGP routing table (even maybe only one 383 pair of additional anycast addresses (IPv4 and IPv6)). 385 2) Attack defense: due to the deployment of anycast servers is more 386 widely and the anycast nodes are increased a lot. How to secure 387 these nodes will be harder and more important. In order to manage 388 the increased global/local nodes, more sophisticated tools (such as 389 CHOAS resource record, Traceroute command, special monitoring and 390 analyzing platform) should be adopted and developed. In this way, 391 the anycast nodes can be identified and monitored effectively and 392 efficiently. 394 Of course, we believe that the future DNS root service provider 395 (many ccTLD and gTLD have deployed anycast service and manage it 396 well) for the global or local anycast nodes will have the experience 397 and ability to monitor and manage the servers and the possible 398 attack (such as DDoS) can be effectively detected and defended [12]. 400 Other security issues will be discussed and detailed further. 402 6. References 404 [1] http://www.root-servers.org/. 406 [2] T. Lee, B. Huffaker, M. Fomenkov, and k. claffy. On the 407 problem of optimization of DNS root servers' placement. In 408 Proc. of Passive and Active Network Measurement Workshop (PAM). 409 April 2003. 411 [3] P. Vixie and A. Kato. DNS Response Size Issues. draft-ietf- 412 dnsop-respsize-15.txt. February 2014. 414 [4] R. Bellis. DNS Transport over TCP - Implementation 415 Requirements. IETF RFC 5966. August 2010. 417 [5] CAIDA. Analysis of the DNS root and gTLD nameserver system: 418 status and progress report. May 2008. 420 [6] ICANN. Accommodating IP Version 6 Address Resource Records for 421 the Root of the Domain Name System. January 2007. 423 [7] S. Deering, and R. Hinden. Internet Protocol, Version 6 (IPv6) 424 Specification. IETF RFC 2460. December 1998. 426 [8] P. Vixie. Extension Mechanisms for DNS (EDNS0). IETF RFC 2671. 427 August 1999. 429 [9] http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj 430 _7-2/dnssec.html. 432 [10] S. Sato, T. Matsuura, and Y. Morishita. BGP Anycast Node 433 Requirements for Authoritative Name Servers draft-sato-dnsop- 434 anycast-node-requirements-02.txt. September 2007. 436 [11] R. Bush, D. Karrenberg, M. Kosters, and R. Plzak. Root Name 437 Server Operational Requirements. IETF RFC 2870. June 2000. 439 [12] USC/ISI Technical Report. Identifying and Characterizing 440 Anycast in the Domain Name System. May 2011. 442 Author's Address 444 Xiaodong Lee 445 China Internet Network Information Center 446 No.4 South 4th Street, Zhongguancun 447 Beijing, P. R. China 448 Email: xl@cnnic.cn 450 Paul Vixie 451 Farsight Security, Inc. 452 155 Bovet Road, #476 453 San Mateo, CA 94402, USA 454 Email: vixie@farsightsecurity.com 456 Zhiwei Yan 457 China Internet Network Information Center 458 No.4 South 4th Street, Zhongguancun 459 Beijing, P. R. China 460 Email: yanzhiwei@cnnic.cn 462 Acknowledgment 464 Funding for the RFC Editor function is currently provided by the 465 Internet Society.