idnits 2.17.00 (12 Aug 2021) /tmp/idnits49935/draft-wkumari-dnsop-dist-root-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 30, 2014) is 2913 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari, Ed. 3 Internet-Draft Google 4 Intended status: Informational P. Hoffman, Ed. 5 Expires: December 1, 2014 VPN Consortium 6 May 30, 2014 8 Distributing the DNS Root 9 draft-wkumari-dnsop-dist-root-00 11 Abstract 13 This document recommends that recursive DNS resolvers transfer the 14 root zone, securely validate it and then populate their caches with 15 the information. 17 [[ Note: This document is largely a discussion starting point. ]] 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 1, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 55 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Pros and Cons of this Technique . . . . . . . . . . . . . . . 5 57 3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Transfer Mechanism . . . . . . . . . . . . . . . . . . . 6 61 4.2. Transfer Source . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Channel / Object Security . . . . . . . . . . . . . . . . 7 63 4.4. Load Esitmates . . . . . . . . . . . . . . . . . . . . . 7 64 4.5. Behavior on Failures. . . . . . . . . . . . . . . . . . . 8 65 4.5.1. Bad Zone Data / Scaling . . . . . . . . . . . . . . . 8 66 4.5.2. Failover to the Next Transfer Server . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 One of the main advantages of a DNSSEC-signed root zone is that it 78 doesn't matter where you get the data from, as long as you validate 79 the contents of the zone using DNSSEC information. 81 When a recursive resolver starts up, it has an empty cache and 82 addresses of the root servers. As it begins answering queries, it 83 populates its cache by making a number of queries to the set of root 84 servers, and caching the results. This is a somewhat inefficient 85 process, and a large number of the queries that hit the root are so 86 called "junk" queries, such as queries for second-level domains in 87 non-existent TLDs. 89 This document is describes a means to populate caches in recursive 90 resolvers with the contents of the full root zone so that the 91 recursive resolvers have the root zone content cached. This 92 decreases latency for requests to the resolver, increases reliability 93 and stability of the DNS, and increases DoS resilience for the root 94 servers. 96 This technique can be viewed as pre-populating a resolver's cache 97 with the root zone information, using a transfer operation to do the 98 transfer. 100 1.1. Requirements notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Requirements 108 [[ Note: We have tried to keep this document easily readable, and to 109 drive discussions. This means that we might be somewhat loose in 110 terminology at the moment. I will firm that up later. ]] 112 [[ Note: (Written as a separate note for emphasis!): This document 113 proposes one way to do populate caches with the root zone 114 information. It is a starting point - we have made some choices / 115 trade offs, and written the doc as though they are the right answer. 116 We did this to make reading the document easier - reading a simple 117 (but possibly) wrong solution is easier than having multiple "You 118 could do X, Y, Z" choices at each point. There is a section of open 119 questions at the end of this document. ]] 121 In order to follow these guidelines, a recursive server MUST support 122 DNSSEC, and MUST have an up-to-date copy of the DNS root key. 124 On startup, recursive servers follow these steps: 126 1. The resolver SHOULD perform a priming query to get the full list 127 and addresses of root zone transfer servers. If a priming query 128 is not performed, the resolver MUST have pre-configured knowledge 129 of a list of root zone transfer servers, and (for stability 130 purposes) that list MUST have at least four servers listed. 132 2. The resolver SHOULD randomly sort the list of answers from the 133 priming query. 135 3. The resolver SHOULD attempt to transfer the root zone using AXFR 136 from each one of the servers until either success is achieved or 137 the list has been exhausted. If the root zone cannot be 138 transferred, the resolver logs this as an error, and falls back 139 to "legacy" operation. The resolver MAY attempt to transfer in 140 parallel to minimize startup latency. The resolver MAY store the 141 contents of the root zone to disk. If the resolver has a stored 142 copy of the root zone, and the data in the zone is not expired, 143 and that copy was written within the refresh time listed in the 144 zone, the resolver MAY and load that zone instead of 145 transferring. 147 4. The resolver MUST validate the records in the zone using DNSSEC 148 before relying on any of the records. If any of the records do 149 not validate, the resolver MUST log an error and SHOULD try the 150 next server in the list. 152 Until the server has transferred (and validated) the zone, it MUST 153 NOT act as though it is a copy of the root zone. Once the resolver 154 has transferred and validated the zone, it MUST act as though it is a 155 copy of the root zone. This includes following the refresh, retry, 156 expire logic, with certain modifications: 158 1. If the zone expires (for example, because it cannot retransfer 159 because of blocked TCP connections), it MUST fall back to 160 "legacy" operation and MUST log an error. It MUST NOT return 161 SERVFAIL to queries simply because its copy of the root zone 162 expired. 164 2. The resolver MUST validate the contents of the records in the 165 zone using DNSSEC for every transfer. The resolver SHOULD try 166 alternate servers if the validation fails. If the resolver is 167 unable to transfer a copy of the zone that validates, it MUST 168 treat this as an error, MUST discard the received records, and 169 fail back to "legacy" operation. The resolver SHOULD attempt to 170 restart this process at every retry interval for the root zone. 172 3. The resolver SHOULD set the AD bit on responses to queries for 173 records in the root zone. This action is the same as if it had 174 inserted the entry into its cache through a "normal" query. 176 4. The resolver MUST validate all of the zone contents, and MUST NOT 177 start using the new contents until all have been validated; the 178 resolver MUST NOT use "lazy validation". This means that the 179 replacement of the existing zone data with the refreshed data 180 MUST be an atomic operation. 182 Compliant nameservers software MUST include an option to securely 183 cache the root zone (an example name for this option could be 184 "transfer-and-validate-root [yes|no]"). That is, the mechanism 185 described in this document MUST be optional, and the cache operator 186 MUST be able to turn it off and on. 188 [[ Note: TODO: define "legacy operation" - this basically mans "just 189 how things operate now; you go ask a root server where each TLD is. 190 ]] 192 [ Ed: This fallback to legacy operation solution might only work 193 until most people are doing this. As the number of folk querying the 194 root directly decreases, the scale of the root will presumably 195 decrease. Once this happens, if there is a large failure and 196 everyone falls back to "legacy" operation, will the root still be big 197 enough to cope with the load? Should we address this in this 198 document (e.g: After 10 years from today, the "fallback to legacy" 199 option should be disabled")? Or just note this and suggest that a 200 new document be written, updating this one and disabling the root 201 fallback? ] 203 3. Pros and Cons of this Technique 205 [[ Note: This section likely to be removed or significantly revised 206 before publication. ]] 208 This is primarily a tracking / discussion section, and the text is 209 kept even looser than in the rest of this doc. These are not 210 ordered. 212 3.1. Pros 214 o Decrease in latency to the client - The recursive resolver already 215 knows about all the TLDs and all of their information, so the 216 first query for a particular TLD will always be faster. 218 o DoS against the root servers - By distributing the root to many 219 recursive resolvers, the DoS protection for the root servers is 220 significantly increased. A DDoS may still be able to take down 221 some recursive servers, but there is no root infrastructure to 222 attack. Of course, there is still a zone distribution system that 223 could be attacked (but it would need to be kept down for a much 224 longer time to cause significant damage, and so far the root has 225 stood up just fine to DDoS. 227 o No central monitoring point (see also Cons!) - This proposal 228 provides a small increase to privacy of requests, and removes a 229 place where attackers could collect information. Although query 230 name minimization also achieves some of this, it does still leak 231 the TLDs that people behind a resolver are querying for, which may 232 in itself be a concern (for example someone in a homophobic 233 country who is querying for a name in .gay). 235 o Junk queries / negative caching - Currently, a significant number 236 of queries to the root servers are "junk" queries. Many of these 237 queries are TLDs that do not (and may never) exist in the root 238 Another significant source of junk is queries where the negative 239 TLD answer did not get cached because the queries are for second- 240 level domains (a negative cache entry for "foo.example" will not 241 cover a subsequent query for "bar.example"). 243 o More use of DNSSEC - In order for a recursive resolver to use this 244 system, it needs to fully deploy DNSSEC. Many large ISP-run 245 resolvers do so today, but many smaller resolvers do not. This 246 might be the impetus for them to do so. 248 3.2. Cons 250 o No central monitoring point (also see Pros!) - DNS operators lose 251 the ability to monitor the root system. While there is work 252 underway to implement better instrumentation of the root server 253 system, this (potentially) removes the thing to monitor. 255 o Loss of agility in making root zone changes - Currently, if there 256 is an error in the root zone (or someone needs to make an 257 emergency change), a new root zone can be created, and the root 258 server operators can be notified and start serving the new zone 259 quickly. Of course, this does not invalidate the bad information 260 in (long TTL) cached answers. Notifying every recursive resolver 261 is not feasible. 263 o Increased complexity in nameserver software and their operations - 264 Any proposal for recursive servers to copy and serve the root 265 inherently means more code to write and execute. Note that many 266 recursive resolvers are on inexpensive home routers that are 267 rarely (if ever) updated. 269 o Changes the nature and distribution of traffic hitting the root 270 servers - If all the "good" recursive resolvers deploy root 271 copying, then root servers end up servicing only "bad" recursive 272 resolvers and attack traffic. The roots (could) become what AS112 273 is for RFC1918. 275 4. Open Questions 277 [[ Lots of food for thought here. ]] 279 4.1. Transfer Mechanism 281 The current document uses AXFR as the way to get the zone. This may 282 be not be the best way to transfer the data. AXFR is an easy way to 283 explain what we are trying to achieve, and everyone in the DNS world 284 is familiar with transferring a copy of a zone with AXFR. There are 285 many technologies that might be better for distributing this type of 286 data to lots of locations. A short list of alternatives includes 287 FTP, HTTP, and BitTorrent. The whole point of DNSSEC is that it 288 doesn't matter where the data comes from. 290 4.2. Transfer Source 292 We need a source for the data. Currently, some of root operators 293 allow open AXFR (B, C, F, G, K), and IANA provides a service as well. 294 Should we continue to use the root servers as a source, or should 295 there be a new infrastructure created for getting copies of the full 296 root zone? Will the current set of operators / nodes be willing / 297 able to scale to the number of transfers? Will additional letters be 298 willing to enable AXFR? What if we changed the transfer mechanism? 299 Should we stand up a new service? 301 4.3. Channel / Object Security 303 Currently the root zone is signed. Unfortunately the way DNSSEC 304 works, it only signs the authoritative information in the zone, and 305 non-authoritative information, particularly glue records, are not 306 signed. 308 Does this matter? 310 o No. The non-authoritative information is not signed in the 311 current design. All that the "copy the root zone" idea does it 312 pre-populate the cache en mass, and so we should do exactly what 313 we currently do. 315 o Yes. It would be good to be able to get all the zone information 316 from anywhere. An attacker might be stripping or modifying the 317 non-authoritative information. 319 An option that has been mentioned would be to wrap the AXFR transfers 320 in SIG(0), but this has serious load implications for the transfer 321 servers. A simple solution would be to sort the records into a 322 canonical format, make a hash of that, and then append and sign the 323 result. This would require a new protocol, but it is something that 324 has been done many times in areas outside the DNS. 326 4.4. Load Esitmates 328 [[ Note: these are quick, on the back of an envelope calculations. 329 They could be very wrong. ]] 331 People estimate that there are roughly 180,000 "real" recursive 332 servers that talk to the root server. To account for restarts, we'll 333 call it 200,000. We like to keep something like the current agility 334 of the root, so we should try transfer twice a day. This is 400,000 335 transfers per day, or less than 5 transfers per second. The root 336 zone is currently around 550KB. At 5qps this is roughly 21Mbps. 337 That's quite a low number relative to what the root servers currently 338 serve. Yes, the root zone is growing in size, but even a few orders 339 of magnitude is still reasonable. 341 While this could be handled by a single box, it (obviously!) 342 shouldn't be. We still need DoS protection, redundancy, overhead, 343 etc - but as a scaling number this is interesting. 345 4.5. Behavior on Failures. 347 This is actually 2 questions: 349 4.5.1. Bad Zone Data / Scaling 351 Once most recursive servers start using this, the load on the root 352 will be significantly less and / or different. This means that the 353 root might no longer be adequately scaled to deal with *everyone* 354 suddenly querying it if there is a bad root zone pushed out. This is 355 a longer term issue, but how should we address it? After N years 356 remove the legacy fallback? What is N? Or, in a few years someone 357 writes a new doc that updates this one and removes the legacy 358 fallback? 360 4.5.2. Failover to the Next Transfer Server 362 If you try transfer from a transfer server and get bad data, you 363 should try another one -- but, how do we avoid causing a DoS if a bad 364 root zone is pushed out? We could solve this with something like 365 "try the next N server, then start exponential backoff, capping at 366 M". This seems like it might be another form of an existing issue - 367 what happens if someone published a bad DS in the root for a very 368 popular TLD - does everyone start hammering on the door demanding 369 better data? 371 5. IANA Considerations 373 Currently this document requires no action from the IANA. Depending 374 on some of the Open Questions discussions this may change. 376 6. Security Considerations 378 [[ Note: This needs to be filled in more when there is agreement on 379 the actual mechanism. ]] 381 7. Acknowledgements 383 The editors fully acknowledge that this is not a new concept, and 384 that we have chatted with many people about this. If we have spoken 385 to you and your name is not listed below, let us know. 387 8. Contributors 389 The general concept in this document is not new; there have been 390 discussions regarding recursive resolvers copying the root zone for 391 many years. The fact that the root zone is now signed with DNSSEC 392 makes implementing some of these techniques more feasible. 394 The following is an unordered list of individuals have contributed 395 text and / or significant discussions to this document. 397 Steve Crocker - Shinkuro 399 Jaap Akkerhuis - NLnet Labs 401 David Conrad - Virtualized, LLC. 403 Lars-Johan Liman - Netnod 405 Suzanne Woolf - Individual 407 Roy Arends - Nominet 409 Olaf Kolkman - NLnet Labs 411 Danny McPherson - Verisign 413 Joe Abley - Dyn 415 Jim Martin - ISC 417 Jared Mauch - NTT America 419 Rob Austien - Dragon Research Labs 421 Sam Weiler - Parsons 423 Duane Wessels - Verisign 425 9. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 Appendix A. Changes / Author Notes. 432 [RFC Editor: Please remove this section before publication ] 434 Initial to -00 436 o Text! 438 Authors' Addresses 440 Warren Kumari (editor) 441 Google 442 1600 Amphitheatre Parkway 443 Mountain View, Ca 94043 444 US 446 Email: Warren@kumari.net 448 Paul Hoffman (editor) 449 VPN Consortium 451 Email: paul.hoffman@vpnc.org