idnits 2.17.1 draft-ietf-dnsop-7706bis-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 : ---------------------------------------------------------------------------- ** 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 18 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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 26, 2019) is 1677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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 Updates: 7706 (if approved) P. Hoffman 5 Intended status: Informational ICANN 6 Expires: February 27, 2020 August 26, 2019 8 Running a Root Server Local to a Resolver 9 draft-ietf-dnsop-7706bis-05 11 Abstract 13 Some DNS recursive resolvers have longer-than-desired round-trip 14 times to the closest DNS root server such as during a network attack. 15 Some DNS recursive resolver operators want to prevent snooping by 16 third parties of requests sent to DNS root servers. Such resolvers 17 can greatly decrease the round-trip time and prevent observation of 18 requests by serving a copy of the full root zone on the same server, 19 such as on a loopback address or in the resolver software. This 20 document shows how to start and maintain such a copy of the root zone 21 that does not cause problems for other users of the DNS, at the cost 22 of adding some operational fragility for the operator. 24 [ This document is being collaborated on in Github at: 25 https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent 26 version of the document, open issues, and so on should all be 27 available there. The authors gratefully accept pull requests. ] 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 27, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 65 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 66 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Operation of the Root Zone on the Local Server . . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 5.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7 73 A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 8 74 Appendix B. Example Configurations of Common Implementations . . 8 75 B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 76 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 77 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11 78 B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11 79 B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12 80 B.6. Example Configuration: Microsoft Windows Server 2012 . . 12 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 DNS recursive resolvers have to provide answers to all queries from 87 their customers, even those for domain names that do not exist. For 88 each queried name that is within a top-level domain (TLD) that is not 89 in the recursive resolver's cache, the resolver must send a query to 90 a root server to get the information for that TLD, or to find out 91 that the TLD does not exist. Research shows that the vast majority 92 of queries going to the root are for names that do not exist in the 93 root zone because negative answers are sometimes cached for a much 94 shorter period of time. 96 Many of the queries from recursive resolvers to root servers get 97 answers that are referrals to other servers. Malicious third parties 98 might be able to observe that traffic on the network between the 99 recursive resolver and root servers. 101 The primary goals of this design are to provide more reliable answers 102 for queries to the root zone during network attacks, and to prevent 103 queries and responses from being visible on the network. This design 104 will probably have little effect on getting faster responses to stub 105 resolver for good queries on TLDs, because the TTL for most TLDs is 106 usually long-lived (on the order of a day or two) and is thus usually 107 already in the cache of the recursive resolver; the same is true for 108 the TTL for negative answers from the root servers. (Although the 109 primary goal of the design is for serving the root zone, the method 110 can be used for any zone.) 112 This document describes a method for the operator of a recursive 113 resolver to have a complete root zone locally, and to hide queries 114 for the root zone from outsiders. The basic idea is to create an up- 115 to-date root zone service on the same host as the recursive server, 116 and use that service when the recursive resolver looks up root 117 information. The recursive resolver validates all responses from the 118 root service on the same host, just as it would all responses from a 119 remote root server. 121 This design explicitly only allows the new root zone service to be 122 run on the same server as the recursive resolver, in order to prevent 123 the server from serving authoritative answers to any other system. 124 Specifically, the root service on the local system MUST be configured 125 to only answer queries from resolvers on the same host, and MUST NOT 126 answer queries from any other resolver. 128 At the time that RFC 7706 was published, it was considered 129 controversial: there was not consensus on whether this was a "best 130 practice". In fact, many people felt that it is an excessively risky 131 practice because it introduced a new operational piece to local DNS 132 operations where there was not one before. Since then, the DNS 133 operational community has largely shifted to believing that local 134 serving of the root zone for an individual resolver is a reasonable 135 practice. The advantages listed above do not come free: if this new 136 system does not work correctly, users can get bad data, or the entire 137 recursive resolution system might fail in ways that are hard to 138 diagnose. 140 This design uses authoritative service running on the same machine as 141 the recursive resolver. Common open source recursive resolver 142 software does not need to add new functionality to act as an 143 authoritative server for some zones, but other recursive resolver 144 software might need to be able to talk to an authoritative server 145 running on the same host. 147 A different approach to solving some of the problems discussed in 148 this document is described in [RFC8198]. 150 1.1. Updates from RFC 7706 152 RFC 7706 explicitly required that a root server instance be run on 153 the loopback interface of the host running the validating resolver. 154 However, RFC 7706 also had examples of how to set up common software 155 that did not use the loopback interface. This document loosens the 156 restriction on using the loopback interface and in fact allows the 157 use of a local service, not necessarily an authoritative server. 158 However, the document keeps the requirement that only systems running 159 on that single host be able to query that authoritatve root server or 160 service. 162 This document changes the use cases for running a local root service 163 more consistent with the reasons operators said they had for using 164 RFC 7706. 166 Removed the prohibition on distribution of recursive DNS servers 167 including configurations for this design because some already do, and 168 others have expressed an interest in doing so. 170 Added the idea that a recursive resolver using this design might 171 switch to using the normal (remote) root servers if the local root 172 server fails. 174 Refreshed the list of where one can get copies of the root zone. 176 Added examples of other resolvers and updated the existing examples. 178 1.2. Requirements Notation 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in BCP 14 [RFC2119] 183 [RFC8174] when, and only when, they appear in all capitals, as shown 184 here. 186 2. Requirements 188 In order to implement the mechanism described in this document: 190 o The system MUST be able to validate every signed record in a zone 191 with DNSSEC [RFC4033]. 193 o The system MUST have an up-to-date copy of the key used to sign 194 the DNS root. 196 o The system MUST be able to retrieve a copy of the entire root zone 197 (including all DNSSEC-related records). 199 o The system MUST be able to run an authoritative service for the 200 root zone on the same host. The authoritative root service MUST 201 only respond to queries from the same host. One way to assure not 202 responding to queries from other hosts is to run an authoritative 203 server for the root that responds only on one of the loopback 204 addresses (that is, an address in the range 127/8 for IPv4 or ::1 205 in IPv6). Another method to have the resolver software also act 206 as an authoritative server for the root zone, but only for 207 answering queries from itself. 209 A corollary of the above list is that authoritative data in the root 210 zone used on the local authoritative server MUST be identical to the 211 same data in the root zone for the DNS. It is possible to change the 212 unsigned data (the glue records) in the copy of the root zone, but 213 such changes could cause problems for the recursive server that 214 accesses the local root zone, and therefore any changes to the glue 215 records SHOULD NOT be made. 217 3. Operation of the Root Zone on the Local Server 219 The operation of an authoritative server for the root in the system 220 described here can be done separately from the operation of the 221 recursive resolver, or it might be part of the configuration of the 222 recursive resolver system. 224 The steps to set up the root zone are: 226 1. Retrieve a copy of the root zone. (See Appendix A for some 227 current locations of sources.) 229 2. Start the authoritative service for the root zone in a manner 230 that prevents any system other than a recursive resolver on the 231 same host from accessing it. 233 The contents of the root zone MUST be refreshed using the timers from 234 the SOA record in the root zone, as described in [RFC1035]. This 235 inherently means that the contents of the local root zone will likely 236 be a little behind those of the global root servers because those 237 servers are updated when triggered by NOTIFY messages. 239 In a system that is using a local authoritative server for the root 240 zone. if the contents of the root zone cannot be refreshed before 241 the expire time in the SOA, the local root server MUST return a 242 SERVFAIL error response for all queries sent to it until the zone can 243 be successfully be set up again. Because this would cause the 244 recursive resolver to also fail, the resolver MUST immediatly switch 245 to using other (non-local) root servers if the resolver receives a 246 SERVFAIL response from a local root server. 248 In a resolver that is using an internal service for the root zone. 249 if the contents of the root zone cannot be refreshed before the 250 expire time in the SOA, the resolver MUST immediatly switch to using 251 non-local root servers. 253 In the event that refreshing the contents of the root zone fails, the 254 results can be disastrous. For example, sometimes all the NS records 255 for a TLD are changed in a short period of time (such as 2 days); if 256 the refreshing of the local root zone is broken during that time, the 257 recursive resolver will have bad data for the entire TLD zone. 259 An administrator using the procedure in this document SHOULD have an 260 automated method to check that the contents of the local root zone 261 are being refreshed; this might be part of the resolver software. 262 One way to do this is to have a separate process that periodically 263 checks the SOA of the local root zone and makes sure that it is 264 changing. At the time that this document is published, the SOA for 265 the root zone is the digital representation of the current date with 266 a two-digit counter appended, and the SOA is changed every day even 267 if the contents of the root zone are unchanged. For example, the SOA 268 of the root zone on January 2, 2019 was 2019010201. A process can 269 use this fact to create a check for the contents of the local root 270 zone (using a program not specified in this document). 272 4. Security Considerations 274 A system that does not follow the DNSSEC-related requirements given 275 in Section 2 can be fooled into giving bad responses in the same way 276 as any recursive resolver that does not do DNSSEC validation on 277 responses from a remote root server. Anyone deploying the method 278 described in this document should be familiar with the operational 279 benefits and costs of deploying DNSSEC [RFC4033]. 281 As stated in Section 1, this design explicitly only allows the new 282 root zone server to be run on the same host, answering queries only 283 from resolvers on that host, in order to prevent the server from 284 serving authoritative answers to any system other than the recursive 285 resolver. This has the security property of limiting damage to any 286 other system that might try to rely on an altered copy of the root. 288 5. References 290 5.1. Normative References 292 [RFC1035] Mockapetris, P., "Domain names - implementation and 293 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 294 November 1987, . 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 302 Rose, "DNS Security Introduction and Requirements", 303 RFC 4033, DOI 10.17487/RFC4033, March 2005, 304 . 306 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 307 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 308 May 2017, . 310 5.2. Informative References 312 [Manning2013] 313 Manning, W., "Client Based Naming", 2013, 314 . 316 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 317 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 318 July 2017, . 320 Appendix A. Current Sources of the Root Zone 322 The root zone can be retrieved from anywhere as long as it comes with 323 all the DNSSEC records needed for validation. Currently, one can get 324 the root zone from ICANN by zone transfer (AXFR) over TCP from DNS 325 servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. One can 326 also get the root zone from IANA as a text file over HTTPS at 327 . 329 Currently, the root can also be retrieved by AXFR over TCP from the 330 following root server operators: 332 o b.root-servers.net 334 o c.root-servers.net 336 o d.root-servers.net 338 o f.root-servers.net 340 o g.root-servers.net 342 o k.root-servers.net 344 It is crucial to note that none of the above services are guaranteed 345 to be available. It is possible that ICANN or some of the root 346 server operators will turn off the AXFR capability on the servers 347 listed above. Using AXFR over TCP to addresses that are likely to be 348 anycast (as the ones above are) may conceivably have transfer 349 problems due to anycast, but current practice shows that to be 350 unlikely. 352 A.1. Root Zone Services 354 At the time that this document is published, there is one root zone 355 service that is active, and one that has been announced as in the 356 planning stages. This section describes all known active services. 358 LocalRoot () is an experimental service 359 that embodies many of the ideas in this document. It distributes the 360 root zone by AXFR, and also offers DNS NOTIFY messages when the 361 LocalRoot system sees that the root zone has changed. 363 Appendix B. Example Configurations of Common Implementations 365 This section shows fragments of configurations for some popular 366 recursive server software that is believed to correctly implement the 367 requirements given in this document. The examples have been updated 368 since the publication of RFC 7706. 370 The IPv4 and IPv6 addresses in this section were checked recently by 371 testing for AXFR over TCP from each address for the known single- 372 letter names in the root-servers.net zone. 374 B.1. Example Configuration: BIND 9.12 376 BIND 9.12 acts both as a recursive resolver and an authoritative 377 server. Because of this, there is "fate-sharing" between the two 378 servers in the following configuration. That is, if the root server 379 dies, it is likely that all of BIND is dead. 381 Note that a future version of BIND will support a much more robust 382 method for creating a local mirror of the root or other zones; see 383 Appendix B.3. 385 Using this configuration, queries for information in the root zone 386 are returned with the AA bit not set. 388 When slaving a zone, BIND 9.12 will treat zone data differently if 389 the zone is slaved into a separate view (or a separate instance of 390 the software) versus slaved into the same view or instance that is 391 also performing the recursion. 393 Validation: When using separate views or separate instances, the DS 394 records in the slaved zone will be validated as the zone data is 395 accessed by the recursive server. When using the same view, this 396 validation does not occur for the slaved zone. 398 Caching: When using separate views or instances, the recursive 399 server will cache all of the queries for the slaved zone, just as 400 it would using the traditional "root hints" method. Thus, as the 401 zone in the other view or instance is refreshed or updated, 402 changed information will not appear in the recursive server until 403 the TTL of the old record times out. Currently, the TTL for DS 404 and delegation NS records is two days. When using the same view, 405 all zone data in the recursive server will be updated as soon as 406 it receives its copy of the zone. 408 view root { 409 match-destinations { 127.12.12.12; }; 410 zone "." { 411 type slave; 412 file "rootzone.db"; 413 notify no; 414 masters { 415 199.9.14.201; # b.root-servers.net 416 192.33.4.12; # c.root-servers.net 417 199.7.91.13; # d.root-servers.net 418 192.5.5.241; # f.root-servers.net 419 192.112.36.4; # g.root-servers.net 420 193.0.14.129; # k.root-servers.net 421 192.0.47.132; # xfr.cjr.dns.icann.org 422 192.0.32.132; # xfr.lax.dns.icann.org 423 2001:500:200::b; # b.root-servers.net 424 2001:500:2::c; # c.root-servers.net 425 2001:500:2d::d; # d.root-servers.net 426 2001:500:2f::f; # f.root-servers.net 427 2001:500:12::d0d; # g.root-servers.net 428 2001:7fd::1; # k.root-servers.net 429 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 430 2620:0:2d0:202::132; # xfr.lax.dns.icann.org 431 }; 432 }; 433 }; 435 view recursive { 436 dnssec-validation auto; 437 allow-recursion { any; }; 438 recursion yes; 439 zone "." { 440 type static-stub; 441 server-addresses { 127.12.12.12; }; 442 }; 443 }; 445 B.2. Example Configuration: Unbound 1.8 447 Similar to BIND, Unbound starting with version 1.8 can act both as a 448 recursive resolver and an authoritative server. 450 auth-zone: 451 name: "." 452 master: 199.9.14.201 # b.root-servers.net 453 master: 192.33.4.12 # c.root-servers.net 454 master: 199.7.91.13 # d.root-servers.net 455 master: 192.5.5.241 # f.root-servers.net 456 master: 192.112.36.4 # g.root-servers.net 457 master: 193.0.14.129 # k.root-servers.net 458 master: 192.0.47.132 # xfr.cjr.dns.icann.org 459 master: 192.0.32.132 # xfr.lax.dns.icann.org 460 master: 2001:500:200::b # b.root-servers.net 461 master: 2001:500:2::c # c.root-servers.net 462 master: 2001:500:2d::d # d.root-servers.net 463 master: 2001:500:2f::f # f.root-servers.net 464 master: 2001:500:12::d0d # g.root-servers.net 465 master: 2001:7fd::1 # k.root-servers.net 466 master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org 467 master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org 468 fallback-enabled: yes 469 for-downstream: no 470 for-upstream: yes 472 B.3. Example Configuration: BIND 9.14 474 BIND 9.14 (which, at the time of publication of this document is a 475 future release) can set up a local mirror of the root zone with a 476 small configuration option: 478 zone "." { 479 type mirror; 480 }; 482 The simple "type mirror" configuration for the root zone works for 483 the root zone because a default list of primary servers for the IANA 484 root zone is built into BIND 9.14. In order to set up mirroring of 485 any other zone, an explicit list of primary servers needs to be 486 provided. 488 See the documentation for BIND 9.14 (when it is released) for more 489 detail about how to use this simplified configuration 491 B.4. Example Configuration: Unbound 1.9 493 Recent versions of Unbound have a "auth-zone" feature that allows 494 local mirroring of the root zone. Configuration looks like: 496 auth-zone: 497 name: "." 498 master: "b.root-servers.net" 499 master: "c.root-servers.net" 500 master: "d.root-servers.net" 501 master: "f.root-servers.net" 502 master: "g.root-servers.net" 503 master: "k.root-servers.net" 504 fallback-enabled: yes 505 for-downstream: no 506 for-upstream: yes 507 zonefile: "root.zone" 509 B.5. Example Configuration: Knot Resolver 511 Knot Resolver uses its "prefill" module to load the root zone 512 information. This is described at . 516 B.6. Example Configuration: Microsoft Windows Server 2012 518 Windows Server 2012 contains a DNS server in the "DNS Manager" 519 component. When activated, that component acts as a recursive 520 server. DNS Manager can also act as an authoritative server. 522 Using this configuration, queries for information in the root zone 523 are returned with the AA bit set. 525 The steps to configure DNS Manager to implement the requirements in 526 this document are: 528 1. Launch the DNS Manager GUI. This can be done from the command 529 line ("dnsmgmt.msc") or from the Service Manager (the "DNS" 530 command in the "Tools" menu). 532 2. In the hierarchy under the server on which the service is 533 running, right-click on the "Forward Lookup Zones", and select 534 "New Zone". This brings up a succession of dialog boxes. 536 3. In the "Zone Type" dialog box, select "Secondary zone". 538 4. In the "Zone Name" dialog box, enter ".". 540 5. In the "Master DNS Servers" dialog box, enter 541 "b.root-servers.net". The system validates that it can do a zone 542 transfer from that server. (After this configuration is 543 completed, the DNS Manager will attempt to transfer from all of 544 the root zone servers.) 546 6. In the "Completing the New Zone Wizard" dialog box, click 547 "Finish". 549 7. Verify that the DNS Manager is acting as a recursive resolver. 550 Right-click on the server name in the hierarchy, choosing the 551 "Advanced" tab in the dialog box. See that "Disable recursion 552 (also disables forwarders)" is not selected, and that "Enable 553 DNSSEC validation for remote responses" is selected. 555 Acknowledgements 557 The authors fully acknowledge that running a copy of the root zone on 558 the loopback address is not a new concept, and that we have chatted 559 with many people about that idea over time. For example, Bill 560 Manning described a similar solution to the problems in his doctoral 561 dissertation in 2013 [Manning2013]. 563 Evan Hunt contributed greatly to the logic in the requirements. 564 Other significant contributors include Wouter Wijngaards, Tony Hain, 565 Doug Barton, Greg Lindsay, and Akira Kato. The authors also received 566 many offline comments about making the document clear that this is 567 just a description of a way to operate a root zone on the same host, 568 and not a recommendation to do so. 570 People who contributed to this update to RFC 7706 include: Florian 571 Obser, nusenu, Wouter Wijngaards, and Mukund Sivaraman. 573 Authors' Addresses 575 Warren Kumari 576 Google 578 Email: Warren@kumari.net 580 Paul Hoffman 581 ICANN 583 Email: paul.hoffman@icann.org