--- 1/draft-ietf-dnsop-7706bis-02.txt 2019-03-07 15:13:44.154432959 -0800 +++ 2/draft-ietf-dnsop-7706bis-03.txt 2019-03-07 15:13:44.242435117 -0800 @@ -1,19 +1,19 @@ Network Working Group W. Kumari Internet-Draft Google Updates: 7706 (if approved) P. Hoffman Intended status: Informational ICANN -Expires: July 29, 2019 January 25, 2019 +Expires: September 9, 2019 March 8, 2019 Running a Root Server Local to a Resolver - draft-ietf-dnsop-7706bis-02 + draft-ietf-dnsop-7706bis-03 Abstract Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on the same server, such as on a loopback address. This document shows how to start and maintain such a copy @@ -41,21 +41,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 29, 2019. + This Internet-Draft will expire on September 9, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,33 +65,34 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operation of the Root Zone on the Local Server . . . . . . . 5 - 4. Using the Root Zone Server on the Same Host . . . . . . . . . 7 + 4. Using the Root Zone Server on the Same Host . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 Appendix B. Example Configurations of Common Implementations . . 9 - B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9 + B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 - B.3. Example Configuration: Unbound . . . . . . . . . . . . . 11 - B.4. Example Configuration: Knot Resolver . . . . . . . . . . 11 - B.5. Example Configuration: Microsoft Windows Server 2012 . . 11 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 + B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11 + B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11 + B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12 + B.6. Example Configuration: Microsoft Windows Server 2012 . . 12 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction DNS recursive resolvers have to provide answers to all queries from their customers, even those for domain names that do not exist. For each queried name that has a top-level domain (TLD) that is not in the recursive resolver's cache, the resolver must send a query to a root server to get the information for that TLD, or to find out that the TLD does not exist. Research shows that the vast majority of @@ -104,21 +105,23 @@ might be able to observe that traffic on the network between the recursive resolver and root servers. The primary goals of this design are to provide more reliable answers for queries to the root zone during network attacks, and to prevent queries and responses from being visible on the network. This design will probably have little effect on getting faster responses to stub resolver for good queries on TLDs, because the TTL for most TLDs is usually long-lived (on the order of a day or two) and is thus usually already in the cache of the recursive resolver; the same is true for - the TTL for negative answers from the root servers. + the TTL for negative answers from the root servers. (Although the + primary goal of the design is for serving the root zone, the method + can be used for any zone.) This document describes a method for the operator of a recursive resolver to have a complete root zone locally, and to hide these queries from outsiders. The basic idea is to create an up-to-date root zone server on the same host as the recursive server, and use that server when the recursive resolver looks up root information. The recursive resolver validates all responses from the root server on the same host, just as it would all responses from a remote root server. @@ -162,46 +165,36 @@ instance. Removed the prohibition on distribution of recursive DNS servers including configurations for this design because some already do, and others have expressed an interest in doing so. Added the idea that a recursive resolver using this design might switch to using the normal (remote) root servers if the local root server fails. + Refreshed the list of where one can get copies of the root zone. + + Added examples of other resolvers and updated the existing examples. + [ This section will list all the changes from RFC 7706. For this draft, it is also the list of changes that we will make in future versions of the daft. ] - [ Give a clearer comparison of software that allows slaving the root - zone in the software (such as BIND or modern Unbound) versus resolver - software that requires a local slaved root zone (older Unbound). ] - - [ Add a description of Knot's cache-prefilling as way to get the data - without having a local authoritative. ] - - [ Add examples of other resolvers such as PowerDNS Recusor. ] - - [ Add discussion of BIND slaving the root zone in the same view - instead of using different views. ] - [ Make the use cases explicit. Be clearer that a real use case is folks who are worried that root server unavailabilty due to DDoS against them is a reason some people would use the mechanisms here. ] [ Describe how slaving the root zone from root zone servers does not fully remove the reliance on the root servers being available. ] - [ Refresh list of where one can get copies of the root zone. ] - [ Other new topics might go here. ] 1.2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Requirements @@ -383,40 +376,45 @@ To repeat the requirement from earlier in this document: if the contents of the zone cannot be refreshed before the expire time, the server MUST return a SERVFAIL error response for all queries until the zone can be successfully be set up again. Appendix B. Example Configurations of Common Implementations This section shows fragments of configurations for some popular recursive server software that is believed to correctly implement the - requirements given in this document. + requirements given in this document. The examples have been updated + since the publication of RFC 7706. The IPv4 and IPv6 addresses in this section were checked recently by testing for AXFR over TCP from each address for the known single- letter names in the root-servers.net zone. -B.1. Example Configuration: BIND 9.9 +B.1. Example Configuration: BIND 9.12 - BIND acts both as a recursive resolver and an authoritative server. - Because of this, there is "fate-sharing" between the two servers in - the following configuration. That is, if the root server dies, it is - likely that all of BIND is dead. + BIND 9.12 acts both as a recursive resolver and an authoritative + server. Because of this, there is "fate-sharing" between the two + servers in the following configuration. That is, if the root server + dies, it is likely that all of BIND is dead. + + Note that a future version of BIND will support a much more robust + method for creating a local mirror of the root or other zones; see + Appendix B.3. Using this configuration, queries for information in the root zone are returned with the AA bit not set. - When slaving a zone, BIND will treat zone data differently if the - zone is slaved into a separate view (or a separate instance of the - software) versus slaved into the same view or instance that is also - performing the recursion. + When slaving a zone, BIND 9.12 will treat zone data differently if + the zone is slaved into a separate view (or a separate instance of + the software) versus slaved into the same view or instance that is + also performing the recursion. Validation: When using separate views or separate instances, the DS records in the slaved zone will be validated as the zone data is accessed by the recursive server. When using the same view, this validation does not occur for the slaved zone. Caching: When using separate views or instances, the recursive server will cache all of the queries for the slaved zone, just as it would using the traditional "root hints" method. Thus, as the zone in the other view or instance is refreshed or updated, @@ -426,29 +424,29 @@ all zone data in the recursive server will be updated as soon as it receives its copy of the zone. view root { match-destinations { 127.12.12.12; }; zone "." { type slave; file "rootzone.db"; notify no; masters { - 192.228.79.201; # b.root-servers.net + 199.9.14.201; # b.root-servers.net 192.33.4.12; # c.root-servers.net 199.7.91.13; # d.root-servers.net 192.5.5.241; # f.root-servers.net 192.112.36.4; # g.root-servers.net 193.0.14.129; # k.root-servers.net 192.0.47.132; # xfr.cjr.dns.icann.org 192.0.32.132; # xfr.lax.dns.icann.org - 2001:500:84::b; # b.root-servers.net + 2001:500:200::b; # b.root-servers.net 2001:500:2::c; # c.root-servers.net 2001:500:2d::d; # d.root-servers.net 2001:500:2f::f; # f.root-servers.net 2001:500:12::d0d; # g.root-servers.net 2001:7fd::1; # k.root-servers.net 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 2620:0:2d0:202::132; # xfr.lax.dns.icann.org }; }; }; @@ -463,53 +461,85 @@ }; }; B.2. Example Configuration: Unbound 1.8 Similar to BIND, Unbound starting with version 1.8 can act both as a recursive resolver and an authoritative server. auth-zone: name: "." - master: 192.228.79.201 # b.root-servers.net + master: 199.9.14.201 # b.root-servers.net master: 192.33.4.12 # c.root-servers.net master: 199.7.91.13 # d.root-servers.net master: 192.5.5.241 # f.root-servers.net master: 192.112.36.4 # g.root-servers.net master: 193.0.14.129 # k.root-servers.net master: 192.0.47.132 # xfr.cjr.dns.icann.org master: 192.0.32.132 # xfr.lax.dns.icann.org - master: 2001:500:84::b # b.root-servers.net + master: 2001:500:200::b # b.root-servers.net master: 2001:500:2::c # c.root-servers.net master: 2001:500:2d::d # d.root-servers.net master: 2001:500:2f::f # f.root-servers.net master: 2001:500:12::d0d # g.root-servers.net master: 2001:7fd::1 # k.root-servers.net master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org fallback-enabled: yes for-downstream: no for-upstream: yes -B.3. Example Configuration: Unbound +B.3. Example Configuration: BIND 9.14 - [ Add an example of modern Unbound, or point to the Unbound - documentation where it exists ] + BIND 9.14 (which, at the time of publication of this document is a + future release) can set up a local mirror of the root zone with a + small configuration option: -B.4. Example Configuration: Knot Resolver + zone "." { + type mirror; + }; + + The simple "type mirror" configuration for the root zone works for + the root zone because a default list of primary servers for the IANA + root zone is built into BIND 9.14. In order to set up mirroring of + any other zone, an explicit list of primary servers needs to be + provided. + + See the documentation for BIND 9.14 (when it is released) for more + detail about how to use this simplified configuration + +B.4. Example Configuration: Unbound 1.9 + + Recent versions of Unbound have a "auth-zone" feature that allows + local mirroring of the root zone. Configuration looks like: + + auth-zone: + name: "." + master: "b.root-servers.net" + master: "c.root-servers.net" + master: "d.root-servers.net" + master: "f.root-servers.net" + master: "g.root-servers.net" + master: "k.root-servers.net" + fallback-enabled: yes + for-downstream: no + for-upstream: yes + zonefile: "root.zone" + +B.5. Example Configuration: Knot Resolver Knot Resolver uses its "prefill" module to load the root zone information. This is described at . -B.5. Example Configuration: Microsoft Windows Server 2012 +B.6. Example Configuration: Microsoft Windows Server 2012 Windows Server 2012 contains a DNS server in the "DNS Manager" component. When activated, that component acts as a recursive server. DNS Manager can also act as an authoritative server. Using this configuration, queries for information in the root zone are returned with the AA bit set. The steps to configure DNS Manager to implement the requirements in this document are: @@ -550,21 +580,21 @@ dissertation in 2013 [Manning2013]. Evan Hunt contributed greatly to the logic in the requirements. Other significant contributors include Wouter Wijngaards, Tony Hain, Doug Barton, Greg Lindsay, and Akira Kato. The authors also received many offline comments about making the document clear that this is just a description of a way to operate a root zone on the same host, and not a recommendation to do so. People who contributed to this update to RFC 7706 include: Florian - Obser, nusenu, [[ others go here ]]. + Obser, nusenu, Wouter Wijngaards, [[ others go here ]]. Authors' Addresses Warren Kumari Google Email: Warren@kumari.net Paul Hoffman ICANN