--- 1/draft-ietf-dnsop-7706bis-01.txt 2019-01-25 15:13:23.630286063 -0800 +++ 2/draft-ietf-dnsop-7706bis-02.txt 2019-01-25 15:13:23.658286750 -0800 @@ -1,19 +1,19 @@ Network Working Group W. Kumari Internet-Draft Google Updates: 7706 (if approved) P. Hoffman Intended status: Informational ICANN -Expires: April 25, 2019 October 22, 2018 +Expires: July 29, 2019 January 25, 2019 -Decreasing Access Time to Root Servers by Running One On The Same Server - draft-ietf-dnsop-7706bis-01 + Running a Root Server Local to a Resolver + draft-ietf-dnsop-7706bis-02 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,25 +41,25 @@ 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 April 25, 2019. + This Internet-Draft will expire on July 29, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -74,88 +74,89 @@ 3. Operation of the Root Zone on the Local Server . . . . . . . 5 4. Using the Root Zone Server on the Same Host . . . . . . . . . 7 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.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 - B.3. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10 - B.4. Example Configuration: Microsoft Windows Server 2012 . . 11 + B.3. Example Configuration: Unbound . . . . . . . . . . . . . 11 + B.4. Example Configuration: Knot Resolver . . . . . . . . . . 11 + B.5. Example Configuration: Microsoft Windows Server 2012 . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + 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 queries going to the root are for names that do not exist in the root - zone, partially because the negative answers are cached for a much - shorter period of time. A slow path between the recursive resolver - and the closest root server has a negative effect on the resolver's - customers. + zone because negative answers are sometimes cached for a much shorter + period of time. Many of the queries from recursive resolvers to root servers get answers that are referrals to other servers. Malicious third parties might be able to observe that traffic on the network between the recursive resolver and root servers. - This document describes a method for the operator of a recursive - resolver to greatly speed these queries and to hide them 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. + 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 primary goals of this design are to provide faster negative - responses to stub resolver queries that contain queries that result - in NXDOMAIN responses, and to prevent queries and responses from - being visible on the network. This design will probably have little - effect on getting faster positive 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. + 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. This design explicitly only allows the new root zone server to be run on the same server as the recursive resolver, in order to prevent the server from serving authoritative answers to any other system. Specifically, the root server on the local system MUST be configured to only answer queries from the resolvers on the same host, and MUST NOT answer queries from any other resolver. - It is important to note that the design described in this document is - controversial. There is not consensus on whether this is a "best - practice". In fact, many people feel that it is an excessively risky - practice because it introduces a new operational piece to local DNS - operations where there was not one before. The advantages listed - above do not come free: if this new system does not work correctly, - users can get bad data, or the entire recursive resolution system - might fail in ways that are hard to diagnose. + At the time that RFC 7706 was published, it was considered + controversial: there was not consensus on whether this was a "best + practice". In fact, many people felt that it is an excessively risky + practice because it introduced a new operational piece to local DNS + operations where there was not one before. Since then, the DNS + operational community has largely shifted to believing that local + serving of the root zone for an individual resolver is a reasonable + practice. The advantages listed above do not come free: if this new + system does not work correctly, users can get bad data, or the entire + recursive resolution system might fail in ways that are hard to + diagnose. - This design requires the addition of authoritative name server - software running on the same machine as the recursive resolver. - Thus, recursive resolver software such as BIND or modern versions of - Unbound do not need to add new functionality, but other recursive - resolver software might need to be able to talk to an authoritative - server running on the same host. More recursive resolver software - are expected add the capabilities described in this document in th - future. + This design uses authoritative name server software running on the + same machine as the recursive resolver. Thus, recursive resolver + software such as BIND or modern versions of common open source + recursive resolver software do not need to add new functionality, but + other recursive resolver software might need to be able to talk to an + authoritative server running on the same host. - A different approach to solving the problems discussed in this - document is described in [RFC8198]. + A different approach to solving some of the problems discussed in + this document is described in [RFC8198]. 1.1. Updates from RFC 7706 RFC 7706 explicitly required that the root server instance be run on the loopback interface of the host running the validating resolver. However, RFC 7706 also had examples of how to set up common software that did not use the loopback interface. Thus, this document loosens the restriction on the interface but keeps the requirement that only systems running on that single host be able to query that root server instance. @@ -172,22 +173,21 @@ 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 Knot Resolver and PowerDNS - Recusor, and maybe Windows Server. ] + [ 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 @@ -212,22 +212,22 @@ o The system MUST have an up-to-date copy of the key used to sign the DNS root. o The system MUST be able to retrieve a copy of the entire root zone (including all DNSSEC-related records). o The system MUST be able to run an authoritative server for the root zone on the same host. The root server instance MUST only respond to queries from the same host. One way to assure not responding to queries from other hosts is to make the address of - the authoritative server one of the IPv4 loopback addresses (that - is, an address in the range 127/8 for IPv4 or ::1 in IPv6). + the authoritative server one of the loopback addresses (that is, + an address in the range 127/8 for IPv4 or ::1 in IPv6). A corollary of the above list is that authoritative data in the root zone used on the local authoritative server MUST be identical to the same data in the root zone for the DNS. It is possible to change the unsigned data (the glue records) in the copy of the root zone, but such changes could cause problems for the recursive server that accesses the local root zone, and therefore any changes to the glue records SHOULD NOT be made. 3. Operation of the Root Zone on the Local Server @@ -358,20 +358,22 @@ the root zone from ICANN by zone transfer (AXFR) over TCP from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. Currently, the root can also be retrieved by AXFR over TCP from the following root server operators: o b.root-servers.net o c.root-servers.net + o d.root-servers.net + o f.root-servers.net o g.root-servers.net o k.root-servers.net It is crucial to note that none of the above services are guaranteed to be available. It is possible that ICANN or some of the root server operators will turn off the AXFR capability on the servers listed above. Using AXFR over TCP to addresses that are likely to be @@ -387,26 +389,20 @@ 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. 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. - The examples here use a loopback address of 127.12.12.12, but typical - installations will use 127.0.0.1. The different address is used in - order to emphasize that the root server does not need to be on the - device at the name "localhost" which is often locally served as - 127.0.0.1. - B.1. Example Configuration: BIND 9.9 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. Using this configuration, queries for information in the root zone are returned with the AA bit not set. @@ -432,92 +428,88 @@ 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 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: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 }; }; }; view recursive { dnssec-validation auto; allow-recursion { any; }; recursion yes; zone "." { type static-stub; server-addresses { 127.12.12.12; }; }; }; B.2. Example Configuration: Unbound 1.8 - [ Add a description of Unbound 1.8's "auth-zone" configuration ] - -B.3. Example Configuration: Unbound 1.4 and NSD 4 + Similar to BIND, Unbound starting with version 1.8 can act both as a + recursive resolver and an authoritative server. - [ Do we still want this section? If so, maybe use Know without - cache-prefilling. ]] + auth-zone: + name: "." + master: 192.228.79.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: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 - Unbound and NSD are separate software packages. Because of this, - there is no "fate-sharing" between the two servers in the following - configurations. That is, if the root server instance (NSD) dies, the - recursive resolver instance (Unbound) will probably keep running but - will not be able to resolve any queries for the root zone. - Therefore, the administrator of this configuration might want to - carefully monitor the NSD instance and restart it immediately if it - dies. +B.3. Example Configuration: Unbound - Using this configuration, queries for information in the root zone - are returned with the AA bit not set. + [ Add an example of modern Unbound, or point to the Unbound + documentation where it exists ] - # Configuration for Unbound - server: - do-not-query-localhost: no - stub-zone: - name: "." - stub-prime: no - stub-addr: 127.12.12.12 +B.4. Example Configuration: Knot Resolver - # Configuration for NSD - server: - ip-address: 127.12.12.12 - zone: - name: "." - request-xfr: 192.228.79.201 NOKEY # b.root-servers.net - request-xfr: 192.33.4.12 NOKEY # c.root-servers.net - request-xfr: 192.5.5.241 NOKEY # f.root-servers.net - request-xfr: 192.112.36.4 NOKEY # g.root-servers.net - request-xfr: 193.0.14.129 NOKEY # k.root-servers.net - request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org - request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org - request-xfr: 2001:500:84::b NOKEY # b.root-servers.net - request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net - request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net - request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org - request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org + Knot Resolver uses its "prefill" module to load the root zone + information. This is described at . -B.4. Example Configuration: Microsoft Windows Server 2012 +B.5. 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: @@ -547,31 +539,34 @@ Right-click on the server name in the hierarchy, choosing the "Advanced" tab in the dialog box. See that "Disable recursion (also disables forwarders)" is not selected, and that "Enable DNSSEC validation for remote responses" is selected. Acknowledgements The authors fully acknowledge that running a copy of the root zone on the loopback address is not a new concept, and that we have chatted with many people about that idea over time. For example, Bill - Manning described a similar solution but to a very different problem - (intermittent connectivity, instead of constant but slow - connectivity) in his doctoral dissertation in 2013 [Manning2013]. + Manning described a similar solution to the problems in his doctoral + 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 ]]. + Authors' Addresses Warren Kumari Google Email: Warren@kumari.net + Paul Hoffman ICANN Email: paul.hoffman@icann.org