idnits 2.17.1 draft-ietf-dnsop-7706bis-01.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 : ---------------------------------------------------------------------------- ** 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 22 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. -- The draft header indicates that this document updates RFC7706, but the abstract doesn't seem to directly say this. It does mention RFC7706 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 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 ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 Updates: 7706 (if approved) P. Hoffman 5 Intended status: Informational ICANN 6 Expires: April 25, 2019 October 22, 2018 8 Decreasing Access Time to Root Servers by Running One On The Same Server 9 draft-ietf-dnsop-7706bis-01 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 the same server, such as on a loopback 19 address. This document shows how to start and maintain such a copy 20 of the root zone that does not pose a threat to other users of the 21 DNS, at the cost of adding some operational fragility for the 22 operator. 24 This draft will update RFC 7706. See Section 1.1 for a list of 25 topics that will be added in the update. 27 [ Ed note: Text inside square brackets ([]) is additional background 28 information, answers to freqently asked questions, general musings, 29 etc. They will be removed before publication.] 31 [ This document is being collaborated on in Github at: 32 https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent 33 version of the document, open issues, and so on should all be 34 available there. The authors gratefully accept pull requests. ] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 25, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 72 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 73 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Operation of the Root Zone on the Local Server . . . . . . . 5 75 4. Using the Root Zone Server on the Same Host . . . . . . . . . 7 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 6.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 81 Appendix B. Example Configurations of Common Implementations . . 9 82 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9 83 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 84 B.3. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10 85 B.4. Example Configuration: Microsoft Windows Server 2012 . . 11 86 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 DNS recursive resolvers have to provide answers to all queries from 92 their customers, even those for domain names that do not exist. For 93 each queried name that has a top-level domain (TLD) that is not in 94 the recursive resolver's cache, the resolver must send a query to a 95 root server to get the information for that TLD, or to find out that 96 the TLD does not exist. Research shows that the vast majority of 97 queries going to the root are for names that do not exist in the root 98 zone, partially because the negative answers are cached for a much 99 shorter period of time. A slow path between the recursive resolver 100 and the closest root server has a negative effect on the resolver's 101 customers. 103 Many of the queries from recursive resolvers to root servers get 104 answers that are referrals to other servers. Malicious third parties 105 might be able to observe that traffic on the network between the 106 recursive resolver and root servers. 108 This document describes a method for the operator of a recursive 109 resolver to greatly speed these queries and to hide them from 110 outsiders. The basic idea is to create an up-to-date root zone 111 server on the same host as the recursive server, and use that server 112 when the recursive resolver looks up root information. The recursive 113 resolver validates all responses from the root server on the same 114 host, just as it would all responses from a remote root server. 116 The primary goals of this design are to provide faster negative 117 responses to stub resolver queries that contain queries that result 118 in NXDOMAIN responses, and to prevent queries and responses from 119 being visible on the network. This design will probably have little 120 effect on getting faster positive responses to stub resolver for good 121 queries on TLDs, because the TTL for most TLDs is usually long-lived 122 (on the order of a day or two) and is thus usually already in the 123 cache of the recursive resolver. 125 This design explicitly only allows the new root zone server to be run 126 on the same server as the recursive resolver, in order to prevent the 127 server from serving authoritative answers to any other system. 128 Specifically, the root server on the local system MUST be configured 129 to only answer queries from the resolvers on the same host, and MUST 130 NOT answer queries from any other resolver. 132 It is important to note that the design described in this document is 133 controversial. There is not consensus on whether this is a "best 134 practice". In fact, many people feel that it is an excessively risky 135 practice because it introduces a new operational piece to local DNS 136 operations where there was not one before. The advantages listed 137 above do not come free: if this new system does not work correctly, 138 users can get bad data, or the entire recursive resolution system 139 might fail in ways that are hard to diagnose. 141 This design requires the addition of authoritative name server 142 software running on the same machine as the recursive resolver. 143 Thus, recursive resolver software such as BIND or modern versions of 144 Unbound do not need to add new functionality, but other recursive 145 resolver software might need to be able to talk to an authoritative 146 server running on the same host. More recursive resolver software 147 are expected add the capabilities described in this document in th 148 future. 150 A different approach to solving the problems discussed in this 151 document is described in [RFC8198]. 153 1.1. Updates from RFC 7706 155 RFC 7706 explicitly required that the root server instance be run on 156 the loopback interface of the host running the validating resolver. 157 However, RFC 7706 also had examples of how to set up common software 158 that did not use the loopback interface. Thus, this document loosens 159 the restriction on the interface but keeps the requirement that only 160 systems running on that single host be able to query that root server 161 instance. 163 Removed the prohibition on distribution of recursive DNS servers 164 including configurations for this design because some already do, and 165 others have expressed an interest in doing so. 167 Added the idea that a recursive resolver using this design might 168 switch to using the normal (remote) root servers if the local root 169 server fails. 171 [ This section will list all the changes from RFC 7706. For this 172 draft, it is also the list of changes that we will make in future 173 versions of the daft. ] 175 [ Give a clearer comparison of software that allows slaving the root 176 zone in the software (such as BIND or modern Unbound) versus resolver 177 software that requires a local slaved root zone (older Unbound). ] 179 [ Add a description of Knot's cache-prefilling as way to get the data 180 without having a local authoritative. ] 182 [ Add examples of other resolvers such as Knot Resolver and PowerDNS 183 Recusor, and maybe Windows Server. ] 185 [ Add discussion of BIND slaving the root zone in the same view 186 instead of using different views. ] 188 [ Make the use cases explicit. Be clearer that a real use case is 189 folks who are worried that root server unavailabilty due to DDoS 190 against them is a reason some people would use the mechanisms here. 191 ] 193 [ Describe how slaving the root zone from root zone servers does not 194 fully remove the reliance on the root servers being available. ] 196 [ Refresh list of where one can get copies of the root zone. ] 198 [ Other new topics might go here. ] 200 1.2. Requirements Notation 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 2. Requirements 208 In order to implement the mechanism described in this document: 210 o The system MUST be able to validate a zone with DNSSEC [RFC4033]. 212 o The system MUST have an up-to-date copy of the key used to sign 213 the DNS root. 215 o The system MUST be able to retrieve a copy of the entire root zone 216 (including all DNSSEC-related records). 218 o The system MUST be able to run an authoritative server for the 219 root zone on the same host. The root server instance MUST only 220 respond to queries from the same host. One way to assure not 221 responding to queries from other hosts is to make the address of 222 the authoritative server one of the IPv4 loopback addresses (that 223 is, an address in the range 127/8 for IPv4 or ::1 in IPv6). 225 A corollary of the above list is that authoritative data in the root 226 zone used on the local authoritative server MUST be identical to the 227 same data in the root zone for the DNS. It is possible to change the 228 unsigned data (the glue records) in the copy of the root zone, but 229 such changes could cause problems for the recursive server that 230 accesses the local root zone, and therefore any changes to the glue 231 records SHOULD NOT be made. 233 3. Operation of the Root Zone on the Local Server 235 The operation of an authoritative server for the root in the system 236 described here can be done separately from the operation of the 237 recursive resolver, or it might be part of the configuration of the 238 recursive resolver system. 240 The steps to set up the root zone are: 242 1. Retrieve a copy of the root zone. (See Appendix A for some 243 current locations of sources.) 245 2. Start the authoritative server with the root zone on an address 246 on the host that is not in use. For IPv4, this could be 247 127.0.0.1, but if that address is in use, any address in 127/8 is 248 acceptable. For IPv6, this would be ::1. It can also be a 249 publicly-visible address on the host, but only if the 250 authoritative server software allows restricting the addresses 251 that can access the authoritative server, and the software is 252 configured to only allow access from addresses on this single 253 host. 255 The contents of the root zone MUST be refreshed using the timers from 256 the SOA record in the root zone, as described in [RFC1035]. This 257 inherently means that the contents of the local root zone will likely 258 be a little behind those of the global root servers because those 259 servers are updated when triggered by NOTIFY messages. 261 If the contents of the root zone cannot be refreshed before the 262 expire time in the SOA, the local root server MUST return a SERVFAIL 263 error response for all queries sent to it until the zone can be 264 successfully be set up again. Because this would cause a recursive 265 resolver on the same host that is relying on this root server to also 266 fail, a resolver might be configured to immediatly switch to using 267 other (non-local) root servers if the resolver receives a SERVFAIL 268 response from a local root server. 270 In the event that refreshing the contents of the root zone fails, the 271 results can be disastrous. For example, sometimes all the NS records 272 for a TLD are changed in a short period of time (such as 2 days); if 273 the refreshing of the local root zone is broken during that time, the 274 recursive resolver will have bad data for the entire TLD zone. 276 An administrator using the procedure in this document SHOULD have an 277 automated method to check that the contents of the local root zone 278 are being refreshed; this might be part of the resolver software. 279 One way to do this is to have a separate process that periodically 280 checks the SOA of the root zone from the local root zone and makes 281 sure that it is changing. At the time that this document is 282 published, the SOA for the root zone is the digital representation of 283 the current date with a two-digit counter appended, and the SOA is 284 changed every day even if the contents of the root zone are 285 unchanged. For example, the SOA of the root zone on January 2, 2018 286 was 2018010201. A process can use this fact to create a check for 287 the contents of the local root zone (using a program not specified in 288 this document). 290 4. Using the Root Zone Server on the Same Host 292 A recursive resolver that wants to use a root zone server operating 293 as described in Section 3 simply specifies the local address as the 294 place to look when it is looking for information from the root. All 295 responses from the root server MUST be validated using DNSSEC. 297 Note that using this simplistic configuration will cause the 298 recursive resolver to fail if the local root zone server fails. A 299 more robust configuration would cause the resolver to start using the 300 normal remote root servers when the local root server fails (such as 301 if it does not respond or gives SERVFAIL responses). 303 See Appendix B for more discussion of this for specific software. 305 To test the proper operation of the recursive resolver with the local 306 root server, use a DNS client to send a query for the SOA of the root 307 to the recursive server. Make sure the response that comes back has 308 the AA bit in the message header set to 0. 310 5. Security Considerations 312 A system that does not follow the DNSSEC-related requirements given 313 in Section 2 can be fooled into giving bad responses in the same way 314 as any recursive resolver that does not do DNSSEC validation on 315 responses from a remote root server. Anyone deploying the method 316 described in this document should be familiar with the operational 317 benefits and costs of deploying DNSSEC [RFC4033]. 319 As stated in Section 1, this design explicitly only allows the new 320 root zone server to be run on the same host, answering queries only 321 from resolvers on that host, in order to prevent the server from 322 serving authoritative answers to any system other than the recursive 323 resolver. This has the security property of limiting damage to any 324 other system that might try to rely on an altered copy of the root. 326 6. References 328 6.1. Normative References 330 [RFC1035] Mockapetris, P., "Domain names - implementation and 331 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 332 November 1987, . 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 340 Rose, "DNS Security Introduction and Requirements", 341 RFC 4033, DOI 10.17487/RFC4033, March 2005, 342 . 344 6.2. Informative References 346 [Manning2013] 347 Manning, W., "Client Based Naming", 2013, 348 . 350 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 351 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 352 July 2017, . 354 Appendix A. Current Sources of the Root Zone 356 The root zone can be retrieved from anywhere as long as it comes with 357 all the DNSSEC records needed for validation. Currently, one can get 358 the root zone from ICANN by zone transfer (AXFR) over TCP from DNS 359 servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. 361 Currently, the root can also be retrieved by AXFR over TCP from the 362 following root server operators: 364 o b.root-servers.net 366 o c.root-servers.net 368 o f.root-servers.net 370 o g.root-servers.net 372 o k.root-servers.net 374 It is crucial to note that none of the above services are guaranteed 375 to be available. It is possible that ICANN or some of the root 376 server operators will turn off the AXFR capability on the servers 377 listed above. Using AXFR over TCP to addresses that are likely to be 378 anycast (as the ones above are) may conceivably have transfer 379 problems due to anycast, but current practice shows that to be 380 unlikely. 382 To repeat the requirement from earlier in this document: if the 383 contents of the zone cannot be refreshed before the expire time, the 384 server MUST return a SERVFAIL error response for all queries until 385 the zone can be successfully be set up again. 387 Appendix B. Example Configurations of Common Implementations 389 This section shows fragments of configurations for some popular 390 recursive server software that is believed to correctly implement the 391 requirements given in this document. 393 The IPv4 and IPv6 addresses in this section were checked recently by 394 testing for AXFR over TCP from each address for the known single- 395 letter names in the root-servers.net zone. 397 The examples here use a loopback address of 127.12.12.12, but typical 398 installations will use 127.0.0.1. The different address is used in 399 order to emphasize that the root server does not need to be on the 400 device at the name "localhost" which is often locally served as 401 127.0.0.1. 403 B.1. Example Configuration: BIND 9.9 405 BIND acts both as a recursive resolver and an authoritative server. 406 Because of this, there is "fate-sharing" between the two servers in 407 the following configuration. That is, if the root server dies, it is 408 likely that all of BIND is dead. 410 Using this configuration, queries for information in the root zone 411 are returned with the AA bit not set. 413 When slaving a zone, BIND will treat zone data differently if the 414 zone is slaved into a separate view (or a separate instance of the 415 software) versus slaved into the same view or instance that is also 416 performing the recursion. 418 Validation: When using separate views or separate instances, the DS 419 records in the slaved zone will be validated as the zone data is 420 accessed by the recursive server. When using the same view, this 421 validation does not occur for the slaved zone. 423 Caching: When using separate views or instances, the recursive 424 server will cache all of the queries for the slaved zone, just as 425 it would using the traditional "root hints" method. Thus, as the 426 zone in the other view or instance is refreshed or updated, 427 changed information will not appear in the recursive server until 428 the TTL of the old record times out. Currently, the TTL for DS 429 and delegation NS records is two days. When using the same view, 430 all zone data in the recursive server will be updated as soon as 431 it receives its copy of the zone. 433 view root { 434 match-destinations { 127.12.12.12; }; 435 zone "." { 436 type slave; 437 file "rootzone.db"; 438 notify no; 439 masters { 440 192.228.79.201; # b.root-servers.net 441 192.33.4.12; # c.root-servers.net 442 192.5.5.241; # f.root-servers.net 443 192.112.36.4; # g.root-servers.net 444 193.0.14.129; # k.root-servers.net 445 192.0.47.132; # xfr.cjr.dns.icann.org 446 192.0.32.132; # xfr.lax.dns.icann.org 447 2001:500:84::b; # b.root-servers.net 448 2001:500:2f::f; # f.root-servers.net 449 2001:7fd::1; # k.root-servers.net 450 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 451 2620:0:2d0:202::132; # xfr.lax.dns.icann.org 452 }; 453 }; 454 }; 456 view recursive { 457 dnssec-validation auto; 458 allow-recursion { any; }; 459 recursion yes; 460 zone "." { 461 type static-stub; 462 server-addresses { 127.12.12.12; }; 463 }; 464 }; 466 B.2. Example Configuration: Unbound 1.8 468 [ Add a description of Unbound 1.8's "auth-zone" configuration ] 470 B.3. Example Configuration: Unbound 1.4 and NSD 4 472 [ Do we still want this section? If so, maybe use Know without 473 cache-prefilling. ]] 475 Unbound and NSD are separate software packages. Because of this, 476 there is no "fate-sharing" between the two servers in the following 477 configurations. That is, if the root server instance (NSD) dies, the 478 recursive resolver instance (Unbound) will probably keep running but 479 will not be able to resolve any queries for the root zone. 480 Therefore, the administrator of this configuration might want to 481 carefully monitor the NSD instance and restart it immediately if it 482 dies. 484 Using this configuration, queries for information in the root zone 485 are returned with the AA bit not set. 487 # Configuration for Unbound 488 server: 489 do-not-query-localhost: no 490 stub-zone: 491 name: "." 492 stub-prime: no 493 stub-addr: 127.12.12.12 495 # Configuration for NSD 496 server: 497 ip-address: 127.12.12.12 498 zone: 499 name: "." 500 request-xfr: 192.228.79.201 NOKEY # b.root-servers.net 501 request-xfr: 192.33.4.12 NOKEY # c.root-servers.net 502 request-xfr: 192.5.5.241 NOKEY # f.root-servers.net 503 request-xfr: 192.112.36.4 NOKEY # g.root-servers.net 504 request-xfr: 193.0.14.129 NOKEY # k.root-servers.net 505 request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org 506 request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org 507 request-xfr: 2001:500:84::b NOKEY # b.root-servers.net 508 request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net 509 request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net 510 request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org 511 request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org 513 B.4. Example Configuration: Microsoft Windows Server 2012 515 Windows Server 2012 contains a DNS server in the "DNS Manager" 516 component. When activated, that component acts as a recursive 517 server. DNS Manager can also act as an authoritative server. 519 Using this configuration, queries for information in the root zone 520 are returned with the AA bit set. 522 The steps to configure DNS Manager to implement the requirements in 523 this document are: 525 1. Launch the DNS Manager GUI. This can be done from the command 526 line ("dnsmgmt.msc") or from the Service Manager (the "DNS" 527 command in the "Tools" menu). 529 2. In the hierarchy under the server on which the service is 530 running, right-click on the "Forward Lookup Zones", and select 531 "New Zone". This brings up a succession of dialog boxes. 533 3. In the "Zone Type" dialog box, select "Secondary zone". 535 4. In the "Zone Name" dialog box, enter ".". 537 5. In the "Master DNS Servers" dialog box, enter 538 "b.root-servers.net". The system validates that it can do a zone 539 transfer from that server. (After this configuration is 540 completed, the DNS Manager will attempt to transfer from all of 541 the root zone servers.) 543 6. In the "Completing the New Zone Wizard" dialog box, click 544 "Finish". 546 7. Verify that the DNS Manager is acting as a recursive resolver. 547 Right-click on the server name in the hierarchy, choosing the 548 "Advanced" tab in the dialog box. See that "Disable recursion 549 (also disables forwarders)" is not selected, and that "Enable 550 DNSSEC validation for remote responses" is selected. 552 Acknowledgements 554 The authors fully acknowledge that running a copy of the root zone on 555 the loopback address is not a new concept, and that we have chatted 556 with many people about that idea over time. For example, Bill 557 Manning described a similar solution but to a very different problem 558 (intermittent connectivity, instead of constant but slow 559 connectivity) in his doctoral dissertation in 2013 [Manning2013]. 561 Evan Hunt contributed greatly to the logic in the requirements. 562 Other significant contributors include Wouter Wijngaards, Tony Hain, 563 Doug Barton, Greg Lindsay, and Akira Kato. The authors also received 564 many offline comments about making the document clear that this is 565 just a description of a way to operate a root zone on the same host, 566 and not a recommendation to do so. 568 Authors' Addresses 570 Warren Kumari 571 Google 573 Email: Warren@kumari.net 574 Paul Hoffman 575 ICANN 577 Email: paul.hoffman@icann.org