idnits 2.17.00 (12 Aug 2021) /tmp/idnits44642/draft-ietf-dnsop-7706bis-07.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 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 (January 12, 2020) is 860 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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 Updates: 7706 (if approved) P. Hoffman 5 Intended status: Informational ICANN 6 Expires: July 15, 2020 January 12, 2020 8 Running a Root Server Local to a Resolver 9 draft-ietf-dnsop-7706bis-07 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 July 15, 2020. 46 Copyright Notice 48 Copyright (c) 2020 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 6.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7 74 A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 8 75 Appendix B. Example Configurations of Common Implementations . . 8 76 B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 77 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 78 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11 79 B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11 80 B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12 81 B.6. Example Configuration: Microsoft Windows Server 2012 . . 12 82 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 DNS recursive resolvers have to provide answers to all queries from 88 their customers, even those for domain names that do not exist. For 89 each queried name that is within a top-level domain (TLD) that is not 90 in the recursive resolver's cache, the resolver must send a query to 91 a root server to get the information for that TLD, or to find out 92 that the TLD does not exist. Research shows that the vast majority 93 of queries going to the root are for names that do not exist in the 94 root zone. 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. Some resolver software supports being both 146 an authoritative server and a resolver but separated by logical 147 "views", allowing a local root to be implemented within a single 148 process; examples of this can be seen in Appendix B. 150 A different approach to solving some of the problems discussed in 151 this document is described in [RFC8198]. 153 1.1. Updates from RFC 7706 155 RFC 7706 explicitly required that a 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. This document loosens the 159 restriction on using the loopback interface and in fact allows the 160 use of a local service, not necessarily an authoritative server. 161 However, the document keeps the requirement that only systems running 162 on that single host be able to query that authoritatve root server or 163 service. 165 This document changes the use cases for running a local root service 166 to be more consistent with the reasons operators said they had for 167 using RFC 7706. 169 Removed the prohibition on distribution of recursive DNS servers 170 including configurations for this design because some already do, and 171 others have expressed an interest in doing so. 173 Added the idea that a recursive resolver using this design might 174 switch to using the normal (remote) root servers if the local root 175 server fails. 177 Refreshed the list of where one can get copies of the root zone. 179 Added examples of other resolvers and updated the existing examples. 181 1.2. Requirements Notation 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in BCP 14 [RFC2119] 186 [RFC8174] when, and only when, they appear in all capitals, as shown 187 here. 189 2. Requirements 191 In order to implement the mechanism described in this document: 193 o The system MUST be able to validate every signed record in a zone 194 with DNSSEC [RFC4033]. 196 o The system MUST have an up-to-date copy of the KSK used to sign 197 the DNS root. 199 o The system MUST be able to retrieve a copy of the entire root zone 200 (including all DNSSEC-related records). 202 o The system MUST be able to run an authoritative service for the 203 root zone on the same host. The authoritative root service MUST 204 only respond to queries from the same host. One way to assure not 205 responding to queries from other hosts is to run an authoritative 206 server for the root that responds only on one of the loopback 207 addresses (that is, an address in the range 127/8 for IPv4 or ::1 208 in IPv6). Another method is to have the resolver software also 209 act as an authoritative server for the root zone, but only for 210 answering queries from itself. 212 A corollary of the above list is that authoritative data in the root 213 zone used on the local authoritative server MUST be identical to the 214 same data in the root zone for the DNS. It is possible to change the 215 unsigned data (the glue records) in the copy of the root zone, but 216 such changes could cause problems for the recursive server that 217 accesses the local root zone, and therefore any changes to the glue 218 records SHOULD NOT be made. 220 3. Operation of the Root Zone on the Local Server 222 The operation of an authoritative server for the root in the system 223 described here can be done separately from the operation of the 224 recursive resolver, or it might be part of the configuration of the 225 recursive resolver system. 227 The steps to set up the root zone are: 229 1. Retrieve a copy of the root zone. (See Appendix A for some 230 current locations of sources.) 232 2. Start the authoritative service for the root zone in a manner 233 that prevents any system other than a recursive resolver on the 234 same host from accessing it. 236 The contents of the root zone MUST be refreshed using the timers from 237 the SOA record in the root zone, as described in [RFC1035]. This 238 inherently means that the contents of the local root zone will likely 239 be a little behind those of the global root servers because those 240 servers are updated when triggered by NOTIFY messages. 242 There is a risk that a system using a local authoritative server for 243 the root zone cannot refresh the contents of the root zone before the 244 expire time in the SOA. A system using a local authoritative server 245 for the root zone MUST NOT serve stale data for the root zone. To 246 mitigate the risk that stale data is served, the local root server 247 MUST immediately switch to using non-local root servers. 249 In a resolver that is using an internal service for the root zone, if 250 the contents of the root zone cannot be refreshed before the expire 251 time in the SOA, the resolver MUST immediately switch to using non- 252 local root servers. 254 In the event that refreshing the contents of the root zone fails, the 255 results can be disastrous. For example, sometimes all the NS records 256 for a TLD are changed in a short period of time (such as 2 days); if 257 the refreshing of the local root zone is broken during that time, the 258 recursive resolver will have bad data for the entire TLD zone. 260 An administrator using the procedure in this document SHOULD have an 261 automated method to check that the contents of the local root zone 262 are being refreshed; this might be part of the resolver software. 263 One way to do this is to have a separate process that periodically 264 checks the SOA of the local root zone and makes sure that it is 265 changing. At the time that this document is published, the SOA for 266 the root zone is the digital representation of the current date with 267 a two-digit counter appended, and the SOA is changed every day even 268 if the contents of the root zone are unchanged. For example, the SOA 269 of the root zone on January 2, 2019 was 2019010201. A process can 270 use this fact to create a check for the contents of the local root 271 zone (using a program not specified in this document). 273 4. Security Considerations 275 A system that does not follow the DNSSEC-related requirements given 276 in Section 2 can be fooled into giving bad responses in the same way 277 as any recursive resolver that does not do DNSSEC validation on 278 responses from a remote root server. Anyone deploying the method 279 described in this document should be familiar with the operational 280 benefits and costs of deploying DNSSEC [RFC4033]. 282 As stated in Section 1, this design explicitly only allows the local 283 copy of the root zone information to be available only from resolvers 284 on that host. This has the security property of limiting damage to 285 clients of any local resolver that might try to rely on an altered 286 copy of the root. 288 5. IANA Considerations 290 This document has no actions for IANA. 292 6. References 294 6.1. Normative References 296 [RFC1035] Mockapetris, P., "Domain names - implementation and 297 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 298 November 1987, . 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, 302 DOI 10.17487/RFC2119, March 1997, 303 . 305 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 306 Rose, "DNS Security Introduction and Requirements", 307 RFC 4033, DOI 10.17487/RFC4033, March 2005, 308 . 310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 312 May 2017, . 314 6.2. Informative References 316 [Manning2013] 317 Manning, W., "Client Based Naming", 2013, 318 . 320 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 321 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 322 July 2017, . 324 Appendix A. Current Sources of the Root Zone 326 The root zone can be retrieved from anywhere as long as it comes with 327 all the DNSSEC records needed for validation. Currently, one can get 328 the root zone from ICANN by zone transfer (AXFR) over TCP from DNS 329 servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. One can 330 also get the root zone from IANA as a text file over HTTPS at 331 . 333 Currently, the root can also be retrieved by AXFR over TCP from the 334 following root server operators: 336 o b.root-servers.net 338 o c.root-servers.net 340 o d.root-servers.net 342 o f.root-servers.net 344 o g.root-servers.net 346 o k.root-servers.net 348 It is crucial to note that none of the above services are guaranteed 349 to be available. It is possible that ICANN or some of the root 350 server operators will turn off the AXFR capability on the servers 351 listed above. Using AXFR over TCP to addresses that are likely to be 352 anycast (as the ones above are) may conceivably have transfer 353 problems due to anycast, but current practice shows that to be 354 unlikely. 356 A.1. Root Zone Services 358 At the time that this document is published, there is one root zone 359 service that is active, and one that has been announced as in the 360 planning stages. This section describes all known active services. 362 LocalRoot () is an experimental service 363 that embodies many of the ideas in this document. It distributes the 364 root zone by AXFR, and also offers DNS NOTIFY messages when the 365 LocalRoot system sees that the root zone has changed. 367 Appendix B. Example Configurations of Common Implementations 369 This section shows fragments of configurations for some popular 370 recursive server software that is believed to correctly implement the 371 requirements given in this document. The examples have been updated 372 since the publication of RFC 7706. 374 The IPv4 and IPv6 addresses in this section were checked recently by 375 testing for AXFR over TCP from each address for the known single- 376 letter names in the root-servers.net zone. 378 B.1. Example Configuration: BIND 9.12 380 BIND 9.12 acts both as a recursive resolver and an authoritative 381 server. Because of this, there is "fate-sharing" between the two 382 servers in the following configuration. That is, if the root server 383 dies, it is likely that all of BIND is dead. 385 Note that a future version of BIND will support a much more robust 386 method for creating a local mirror of the root or other zones; see 387 Appendix B.3. 389 Using this configuration, queries for information in the root zone 390 are returned with the AA bit not set. 392 When slaving a zone, BIND 9.12 will treat zone data differently if 393 the zone is slaved into a separate view (or a separate instance of 394 the software) versus slaved into the same view or instance that is 395 also performing the recursion. 397 Validation: When using separate views or separate instances, the DS 398 records in the slaved zone will be validated as the zone data is 399 accessed by the recursive server. When using the same view, this 400 validation does not occur for the slaved zone. 402 Caching: When using separate views or instances, the recursive 403 server will cache all of the queries for the slaved zone, just as 404 it would using the traditional "root hints" method. Thus, as the 405 zone in the other view or instance is refreshed or updated, 406 changed information will not appear in the recursive server until 407 the TTL of the old record times out. Currently, the TTL for DS 408 and delegation NS records is two days. When using the same view, 409 all zone data in the recursive server will be updated as soon as 410 it receives its copy of the zone. 412 view root { 413 match-destinations { 127.12.12.12; }; 414 zone "." { 415 type slave; 416 file "rootzone.db"; 417 notify no; 418 masters { 419 199.9.14.201; # b.root-servers.net 420 192.33.4.12; # c.root-servers.net 421 199.7.91.13; # d.root-servers.net 422 192.5.5.241; # f.root-servers.net 423 192.112.36.4; # g.root-servers.net 424 193.0.14.129; # k.root-servers.net 425 192.0.47.132; # xfr.cjr.dns.icann.org 426 192.0.32.132; # xfr.lax.dns.icann.org 427 2001:500:200::b; # b.root-servers.net 428 2001:500:2::c; # c.root-servers.net 429 2001:500:2d::d; # d.root-servers.net 430 2001:500:2f::f; # f.root-servers.net 431 2001:500:12::d0d; # g.root-servers.net 432 2001:7fd::1; # k.root-servers.net 433 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 434 2620:0:2d0:202::132; # xfr.lax.dns.icann.org 435 }; 436 }; 437 }; 439 view recursive { 440 dnssec-validation auto; 441 allow-recursion { any; }; 442 recursion yes; 443 zone "." { 444 type static-stub; 445 server-addresses { 127.12.12.12; }; 446 }; 447 }; 449 B.2. Example Configuration: Unbound 1.8 451 Similar to BIND, Unbound starting with version 1.8 can act both as a 452 recursive resolver and an authoritative server. 454 auth-zone: 455 name: "." 456 master: 199.9.14.201 # b.root-servers.net 457 master: 192.33.4.12 # c.root-servers.net 458 master: 199.7.91.13 # d.root-servers.net 459 master: 192.5.5.241 # f.root-servers.net 460 master: 192.112.36.4 # g.root-servers.net 461 master: 193.0.14.129 # k.root-servers.net 462 master: 192.0.47.132 # xfr.cjr.dns.icann.org 463 master: 192.0.32.132 # xfr.lax.dns.icann.org 464 master: 2001:500:200::b # b.root-servers.net 465 master: 2001:500:2::c # c.root-servers.net 466 master: 2001:500:2d::d # d.root-servers.net 467 master: 2001:500:2f::f # f.root-servers.net 468 master: 2001:500:12::d0d # g.root-servers.net 469 master: 2001:7fd::1 # k.root-servers.net 470 master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org 471 master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org 472 fallback-enabled: yes 473 for-downstream: no 474 for-upstream: yes 476 B.3. Example Configuration: BIND 9.14 478 BIND 9.14 can set up a local mirror of the root zone with a small 479 configuration option: 481 zone "." { 482 type mirror; 483 }; 485 The simple "type mirror" configuration for the root zone works for 486 the root zone because a default list of primary servers for the IANA 487 root zone is built into BIND 9.14. In order to set up mirroring of 488 any other zone, an explicit list of primary servers needs to be 489 provided. 491 See the documentation for BIND 9.14 for more detail about how to use 492 this simplified configuration. 494 B.4. Example Configuration: Unbound 1.9 496 Recent versions of Unbound have a "auth-zone" feature that allows 497 local mirroring of the root zone. Configuration looks like: 499 auth-zone: 500 name: "." 501 master: "b.root-servers.net" 502 master: "c.root-servers.net" 503 master: "d.root-servers.net" 504 master: "f.root-servers.net" 505 master: "g.root-servers.net" 506 master: "k.root-servers.net" 507 fallback-enabled: yes 508 for-downstream: no 509 for-upstream: yes 510 zonefile: "root.zone" 512 B.5. Example Configuration: Knot Resolver 514 Knot Resolver uses its "prefill" module to load the root zone 515 information. This is described at . 519 B.6. Example Configuration: Microsoft Windows Server 2012 521 Windows Server 2012 contains a DNS server in the "DNS Manager" 522 component. When activated, that component acts as a recursive 523 server. DNS Manager can also act as an authoritative server. 525 Using this configuration, queries for information in the root zone 526 are returned with the AA bit set. 528 The steps to configure DNS Manager to implement the requirements in 529 this document are: 531 1. Launch the DNS Manager GUI. This can be done from the command 532 line ("dnsmgmt.msc") or from the Service Manager (the "DNS" 533 command in the "Tools" menu). 535 2. In the hierarchy under the server on which the service is 536 running, right-click on the "Forward Lookup Zones", and select 537 "New Zone". This brings up a succession of dialog boxes. 539 3. In the "Zone Type" dialog box, select "Secondary zone". 541 4. In the "Zone Name" dialog box, enter ".". 543 5. In the "Master DNS Servers" dialog box, enter 544 "b.root-servers.net". The system validates that it can do a zone 545 transfer from that server. (After this configuration is 546 completed, the DNS Manager will attempt to transfer from all of 547 the root zone servers.) 549 6. In the "Completing the New Zone Wizard" dialog box, click 550 "Finish". 552 7. Verify that the DNS Manager is acting as a recursive resolver. 553 Right-click on the server name in the hierarchy, choosing the 554 "Advanced" tab in the dialog box. See that "Disable recursion 555 (also disables forwarders)" is not selected, and that "Enable 556 DNSSEC validation for remote responses" is selected. 558 Acknowledgements 560 The authors fully acknowledge that running a copy of the root zone on 561 the loopback address is not a new concept, and that we have chatted 562 with many people about that idea over time. For example, Bill 563 Manning described a similar solution to the problems in his doctoral 564 dissertation in 2013 [Manning2013]. 566 Evan Hunt contributed greatly to the logic in the requirements. 567 Other significant contributors include Wouter Wijngaards, Tony Hain, 568 Doug Barton, Greg Lindsay, and Akira Kato. The authors also received 569 many offline comments about making the document clear that this is 570 just a description of a way to operate a root zone on the same host, 571 and not a recommendation to do so. 573 People who contributed to this update to RFC 7706 include: Florian 574 Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and 575 Leo Vegoda. 577 Authors' Addresses 579 Warren Kumari 580 Google 582 Email: Warren@kumari.net 584 Paul Hoffman 585 ICANN 587 Email: paul.hoffman@icann.org