idnits 2.17.00 (12 Aug 2021) /tmp/idnits29341/draft-ietf-dnsop-root-loopback-05.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 : ---------------------------------------------------------------------------- == There are 21 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 1, 2015) is 2417 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-fujiwara-dnsop-nsec-aggressiveuse-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational P. Hoffman 5 Expires: April 3, 2016 ICANN 6 October 1, 2015 8 Decreasing Access Time to Root Servers by Running One on Loopback 9 draft-ietf-dnsop-root-loopback-05 11 Abstract 13 Some DNS recursive resolvers have longer-than-desired round trip 14 times to the closest DNS root server. Some DNS recursive resolver 15 operators want to prevent snooping of requests sent to DNS root 16 servers by third parties. Such resolvers can greatly decrease the 17 round trip time and prevent observation of requests by running a copy 18 of the full root zone on a loopback address (such as 127.0.0.1). 19 This document shows how to start and maintain such a copy of the root 20 zone that does not pose a threat to other users of the DNS, at the 21 cost of adding some operational fragility for the operator. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 3, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 59 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Operation of the Root Zone on the Loopback Address . . . . . 4 61 4. Using the Root Zone Server on the Loopback Address . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7 69 Appendix B. Example Configurations of Common Implementations . . 8 70 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 8 71 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 9 72 B.3. Example Configuration: Microsoft Windows Server 2012 . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 DNS recursive resolvers have to provide answers to all queries from 78 their customers, even those which are for domain names that do not 79 exist. For each queried name that has a top level domain (TLD) that 80 is not in the recursive resolver's cache, the resolver must send a 81 query to a root server to get the information for that TLD, or to 82 find out that the TLD does not exist. Typically, the vast majority 83 of queries going to the root are for names that do not exist in the 84 root zone, and the negative answers are cached for a much shorter 85 period of time. A slow path between the recursive resolver and the 86 closest root server has a negative effect on the resolver's 87 customers. 89 Recursive resolvers currently send queries for all TLDs that are not 90 in their caches to root servers, even though most of those queries 91 get answers that are referrals to other servers. Malicious third 92 parties might be able to observe that traffic on the network between 93 the recursive resolver and one or more of the DNS roots. 95 This document describes a method for the operator of a recursive 96 resolver to greatly speed these queries and to hide them from 97 outsiders. The basic idea is to create an up-to-date root zone 98 server on a loopback address on the same host as the recursive 99 server, and use that server when the recursive resolver looks up root 100 information. The recursive resolver validates all responses from the 101 root server on the loopback address, just as it would all responses 102 from a remote root server. 104 The primary goals of this design is to provide faster negative 105 responses to stub resolver queries that contain junk queries, and to 106 prevent queries and responses from being visible on the network. 107 This design will probably have little effect on getting faster 108 positive responses to stub resolver for good queries on TLDs, because 109 the data for those zones is usually long-lived and already in the 110 cache of the recursive resolver; thus, getting faster positive 111 responses is a non-goal of this design. 113 This design explicitly only allows the new root zone server to be run 114 on a loopback address, in order to prevent the server from serving 115 authoritative answers to any system other than the recursive 116 resolver. 118 It is important to note that this design is being described here is 119 not considered a "best practice". In fact, many people feel that it 120 is an excessively risky practice because it introduces a new 121 operational piece to local DNS operations where there was not one 122 before. The advantages listed above do not come free: if this new 123 system does not work correctly, users can get bad data, or the entire 124 recursive resolution system might fail in ways that are hard to 125 diagnose. 127 This design requires the addition of authoritative name server 128 software running on the same machine as the recursive resolver. 129 Thus, recursive resolver software such as BIND will not need to add 130 much new functionality, but recursive resolver software such as 131 Unbound will need to be able to talk to an authoritative server (such 132 as NSD) running on the same host. 134 Because of the significant operational risks described in this 135 document, distributions of recursive DNS servers MUST NOT include 136 configuration for the design described here. It is acceptable to 137 point to this document, but not to indicate that this configuration 138 is something that should be considered without reading the entire 139 document. 141 A different approach to solving the problems discussed in this 142 document is described in [AggressiveNSEC]. 144 1.1. Requirements Notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 2. Requirements 152 In order to implement the mechanism described in this document: 154 o The system MUST be able to validate a zone with DNSSEC [RFC4033]. 156 o The system MUST have an up-to-date copy of the DNS root key. 158 o The system MUST be able to retrieve a copy of the entire root zone 159 (including all DNSSEC-related records). 161 o The system MUST be able to run an authoritative server on one of 162 the IPv4 loopback addresses (that is, an address in the range 163 127/8 for IPv4 or ::1 in IPv6). 165 A corollary of the above list is that authoritative data in the root 166 zone used on the local authoritative server MUST be identical to the 167 same data in the root zone for the DNS. It is possible to change the 168 unsigned data (the glue records) in the copy of the root zone, but 169 such changes could cause problems for the recursive server that 170 accesses the local root zone, and therefore any changes to the glue 171 records SHOULD NOT be made. 173 3. Operation of the Root Zone on the Loopback Address 175 The operation of an authoritative server for the root in the system 176 described here can be done separately from the operation of the 177 recursive resolver. 179 The steps to set up the root zone are: 181 1. Retrieve a copy of the root zone. (See Appendix A for some 182 current locations of sources.) 184 2. Start the authoritative server with the root zone on a loopback 185 address that is not in use. For IPv4, this would typically be 186 127.0.0.1, but if that address is in use, any address in 127/8 is 187 acceptable. For IPv6, this would be ::1. 189 The contents of the root zone MUST be refreshed using the timers from 190 the SOA record in root zone, as described in [RFC1035]. This 191 inherently means that the conents of the local root zone will likely 192 be a little behind those of the global root servers because those 193 servers are updated triggered by NOTIFY messages. If the contents of 194 the zone cannot be refreshed before the expire time, the server MUST 195 return a SERVFAIL error response for all queries until the zone can 196 be successfully be set up again. 198 In the event that refreshing the contents of the root zone fails, the 199 results can be disastrous. For example, sometimes all the NS records 200 for a TLD are changed in a short period of time; if the local root 201 zone refreshing is broken during that time, the recursive resolver 202 will have bad data for the entire TLD zone. 204 An administrator using the procedure in this document SHOULD have an 205 automated method to check that the contents of the local root zone 206 are being refreshed. One way to do this is to have a separate 207 process that periodically checks the SOA of the root zone from the 208 local root zone and makes sure that they are changing. At the time 209 that this document is published, the SOA for the root zone is the 210 digital representation of the current date with a two-digit counter 211 appended, and the SOA is changed every day even if the contents of 212 the root zone are unchanged. For example, the SOA of the root zone 213 on January 2, 2015 was 2015010201. A process can use this fact to 214 create a check for the contents of the local root zone (using a 215 program not specified in this document). 217 4. Using the Root Zone Server on the Loopback Address 219 A recursive resolver that wants to use a root zone server operating 220 as described in Section 3 simply specifies the local address as the 221 place to look when it is looking for information from the root. All 222 responses from the root server must be validated using DNSSEC. 224 Note that using this configuration will cause the recursive resolver 225 to fail if the local root zone server fails. See Appendix B for more 226 discussion of this for specific software. 228 To test the proper operation of the recursive resolver with the local 229 root server, use a DNS client to send a query for the SOA of the root 230 to the recursive server. Make sure the response that comes back has 231 the AA bit in the message header set to 0. 233 5. IANA Considerations 235 This document requires no action from the IANA. 237 6. Security Considerations 239 A system that does not follow the DNSSEC-related requirements given 240 in Section 2 can be fooled into giving bad responses in the same way 241 as any recursive resolver that does not do DNSSEC validation on 242 responses from a remote root server. Anyone deploying the method 243 described in this document should be familiar with the operational 244 benefits and costs of deploying DNSSEC [RFC4033]. 246 As stated in Section 1, this design explicitly only allows the new 247 root zone server to be run on a loopback address, in order to prevent 248 the server from serving authoritative answers to any system other 249 than the recursive resolver. This has the security property of 250 limiting damage to any other system that might try to rely on the 251 copy of the root in case that copy becomes altered. 253 7. Acknowledgements 255 The editors fully acknowledge that this is not a new concept, and 256 that we have chatted with many people about this. In fact, this 257 concept may already have been implemented without the knowledge of 258 the authors. For example, Bill Manning described a similar solution 259 but to a very different problem (intermittent connectivity, instead 260 of constant but slow connectivity) in his doctoral dissertation in 261 2013 [Manning2013]. 263 Evan Hunt contributed greatly to the logic in the requirements. 264 Other significant contributors include Wouter Wijngaards, Tony Hain, 265 Doug Barton, Greg Lindsay, and Akira Kato. The authors also received 266 many off-line comments about making the document clear that this was 267 just a description of a way to operate a root zone on localhost, and 268 not a recommendation to do so. 270 8. References 272 8.1. Normative References 274 [RFC1035] Mockapetris, P., "Domain names - implementation and 275 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 276 November 1987, . 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 280 RFC2119, March 1997, 281 . 283 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 284 Rose, "DNS Security Introduction and Requirements", RFC 285 4033, DOI 10.17487/RFC4033, March 2005, 286 . 288 8.2. Informative References 290 [AggressiveNSEC] 291 Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", 292 draft-fujiwara-dnsop-nsec-aggressiveuse-00 (work in 293 progress), 2015. 295 [Manning2013] 296 Maning, W., "Client Based Naming", 2013, 297 . 299 Appendix A. Current Sources of the Root Zone 301 The root zone can be retrieved from anywhere as long as it comes with 302 all the DNSSEC records needed for validation. Currently, one can get 303 the root zone from ICANN by zone transfer (AXFR) over TCP from DNS 304 servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. 306 Currently, the root can also be retrieved by AXFR over TCP from the 307 following root server operators: 309 o b.root-servers.net 311 o c.root-servers.net 313 o f.root-servers.net 315 o g.root-servers.net 317 o k.root-servers.net 319 It is crucial to note that none of the above services are guaranteed 320 to be available. It is possible that ICANN or some of the root 321 server operators will turn off the AXFR capability on the servers 322 listed above. Using AXFR over TCP to addresses that are likely to be 323 anycast (as the the ones above are) may conceivably have transfer 324 problems due to anycast, but current practice shows that to be 325 unlikely. 327 To repeat the requirement from earlier in this document: if the 328 contents of the zone cannot be refreshed before the expire time, the 329 server MUST return a SERVFAIL error response for all queries until 330 the zone can be successfully be set up again. 332 Appendix B. Example Configurations of Common Implementations 334 This section shows fragments of configurations for some popular 335 recursive server software that is believed to correctly implement the 336 requirements given in this document. 338 The IPv4 and IPv6 addresses in this section were checked recently by 339 testing for AXFR over TCP from each address for the known single- 340 letter names in the root-servers.net zone. 342 The examples here use a loopback address of 127.12.12.12, but typical 343 installations will use 127.0.0.1. The different address is used in 344 order to emphasize that the root server does not need to be on the 345 device at "localhost". 347 B.1. Example Configuration: BIND 9.9 349 BIND acts both as a recursive resolver and an authoritative server. 350 Because of this, there is "fate sharing" between the two servers in 351 the following configuration. That is, if the root server dies, it is 352 likely that all of BIND is dead. 354 Using this configuration, queries for information in the root zone 355 are returned with the AA bit not set. 357 When slaving a zone, BIND will treat zone data differently if it is 358 slaved into a separate view (or a separate instance of the software) 359 versus slaving the zone into the same view or instance that is also 360 performing the recursion. 362 Validation: When using separate views or separate instances, the DS 363 records in the slaved zone will be validated as the zone data is 364 accessed by the recursive server. When using the same view, this 365 validation does not occur for the slaved zone. 367 Caching: When using separate views or instances, the recursive 368 server will cache all of the queries for the slaved zone, just as 369 it would using the traditional root hints method. Thus, as the 370 zone in the other view or instance is refreshed or updated, 371 changed information will not appear in the recursive server until 372 the TTL of the old record times out. Currently the TTL for DS and 373 delegation NS records is two days. When using the same view, all 374 zone data in the recursive server will be updated as soon as it 375 receives its copy of the zone. 377 view root { 378 match-destinations { 127.12.12.12; }; 379 zone "." { 380 type slave; 381 file "rootzone.db"; 382 notify no; 383 masters { 384 192.228.79.201; # b.root-servers.net 385 192.33.4.12; # c.root-servers.net 386 192.5.5.241; # f.root-servers.net 387 192.112.36.4; # g.root-servers.net 388 193.0.14.129; # k.root-servers.net 389 192.0.47.132; # xfr.cjr.dns.icann.org 390 192.0.32.132; # xfr.lax.dns.icann.org 391 2001:500:84::b; # b.root-servers.net 392 2001:500:2f::f; # f.root-servers.net 393 2001:7fd::1; # k.root-servers.net 394 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 395 2620:0:2d0:202::132; # xfr.lax.dns.icann.org 396 }; 397 }; 398 }; 400 view recursive { 401 dnssec-validation auto; 402 allow-recursion { any; }; 403 recursion yes; 404 zone "." { 405 type static-stub; 406 server-addresses { 127.12.12.12; }; 407 }; 408 }; 410 B.2. Example Configuration: Unbound 1.4 and NSD 4 412 Unbound and NSD are separate software packages. Because of this, 413 there is no "fate sharing" between the two servers in the following 414 configurations. That is, if the root server instance (NSD) dies, the 415 recursive resolver instance (Unbound) will probably keep running, but 416 will not be able to resolve any queries for the root zone. 417 Therefore, the administrator of this configuration might want to 418 carefully monitor the NSD instance and restart it immediately if it 419 dies. 421 Using this configuration, queries for information in the root zone 422 are returned with the AA bit not set. 424 # Configuration for Unbound 425 server: 426 do-not-query-localhost: no 427 stub-zone: 428 name: "." 429 stub-prime: no 430 stub-addr: 127.12.12.12 432 # Configuration for NSD 433 server: 434 ip-address: 127.12.12.12 435 zone: 436 name: "." 437 request-xfr: 192.228.79.201 NOKEY # b.root-servers.net 438 request-xfr: 192.33.4.12 NOKEY # c.root-servers.net 439 request-xfr: 192.5.5.241 NOKEY # f.root-servers.net 440 request-xfr: 192.112.36.4 NOKEY # g.root-servers.net 441 request-xfr: 193.0.14.129 NOKEY # k.root-servers.net 442 request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org 443 request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org 444 request-xfr: 2001:500:84::b NOKEY # b.root-servers.net 445 request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net 446 request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net 447 request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org 448 request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org 450 B.3. Example Configuration: Microsoft Windows Server 2012 452 Windows Server 2012 contains a DNS server in the "DNS Manager" 453 component. When activated, that component acts as a recursive 454 server. DNS Manager can also act as an authoritative server. 456 Using this configuration, queries for information in the root zone 457 are returned with the AA bit set. 459 The steps to configure DNS Manager to implement the requirements in 460 this document are: 462 1. Launch the DNS Manager GUI. This can be done from the command 463 line ("dnsmgmt.msc") or from the Service Manager (the "DNS" 464 command in the "Tools" menu). 466 2. In the hierarchy under the server on which the service is 467 running, right-click on the "Forward Lookup Zones", and select 468 "New Zone". This brings up a succession of dialog boxes. 470 3. In the "Zone Type" dialog box, select "Secondary zone". 472 4. In the "Zone Name" dialog box, enter ".". 474 5. In the "Master DNS Servers" dialog box, enter "b.root- 475 servers.net". The system validates that it can do a zone 476 transfer from that server. (After this configuration is 477 completed, DNS Manager will attempt to transfer from all of the 478 root zone servers.) 480 6. In the "Completing the New Zone Wizard" dialog box, click 481 "Finish". 483 7. Verify that the DNS Manager is acting as a recursive resolver. 484 Right-click on the server name in the hierarch, choosing the 485 "Advanced" tab in the dialog box. See that "Disable recursion 486 (also disables forwarders)" is not selected, and that "Enable 487 DNSSEC validation for remote responses" is selected. 489 Authors' Addresses 491 Warren Kumari 492 Google 494 Email: Warren@kumari.net 496 Paul Hoffman 497 ICANN 499 Email: paul.hoffman@icann.org