--- 1/draft-ietf-dnsop-7706bis-07.txt 2020-03-01 18:13:10.420226202 -0800 +++ 2/draft-ietf-dnsop-7706bis-08.txt 2020-03-01 18:13:10.452227001 -0800 @@ -1,54 +1,56 @@ Network Working Group W. Kumari Internet-Draft Google -Updates: 7706 (if approved) P. Hoffman +Obsoletes: 7706 (if approved) P. Hoffman Intended status: Informational ICANN -Expires: July 15, 2020 January 12, 2020 +Expires: September 2, 2020 March 1, 2020 Running a Root Server Local to a Resolver - draft-ietf-dnsop-7706bis-07 + draft-ietf-dnsop-7706bis-08 Abstract Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. + This document obsoletes RFC 7706. + [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent version of the document, open issues, and so on should all be available there. The authors gratefully accept pull requests. ] Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 15, 2020. + This Internet-Draft will expire on September 2, 2020. Copyright Notice Copyright (c) 2020 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 @@ -62,28 +64,28 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operation of the Root Zone on the Local Server . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 6.2. Informative References . . . . . . . . . . . . . . . . . 7 - Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7 - A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 8 - Appendix B. Example Configurations of Common Implementations . . 8 + 6.2. Informative References . . . . . . . . . . . . . . . . . 8 + Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 + A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9 + Appendix B. Example Configurations of Common Implementations . . 9 B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 - B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 + B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 11 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11 - B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11 + B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 12 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 is within a top-level domain (TLD) that is not @@ -108,31 +110,31 @@ 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 queries for the root zone from outsiders. The basic idea is to create an up- to-date root zone service on the same host as the recursive server, and use that service when the recursive resolver looks up root information. The recursive resolver validates all responses from the - root service on the same host, just as it would all responses from a - remote root server. + root service on the same host, just as it would all validate + responses from a remote root server. This design explicitly only allows the new root zone service 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 service on the local system MUST be configured to only answer queries from resolvers on the same host, and MUST NOT answer queries from any other resolver. - At the time that RFC 7706 was published, it was considered + At the time that RFC 7706 [RFC7706] 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. @@ -143,65 +145,67 @@ authoritative server for some zones, but other recursive resolver software might need to be able to talk to an authoritative server running on the same host. Some resolver software supports being both an authoritative server and a resolver but separated by logical "views", allowing a local root to be implemented within a single process; examples of this can be seen in Appendix B. A different approach to solving some of the problems discussed in this document is described in [RFC8198]. + Readers are expected to be familiar with [RFC8499]. + 1.1. Updates from RFC 7706 RFC 7706 explicitly required that a 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. This document loosens the restriction on using the loopback interface and in fact allows the use of a local service, not necessarily an authoritative server. However, the document keeps the requirement that only systems running - on that single host be able to query that authoritatve root server or - service. + on that single host be able to query that authoritative root server + or service. This document changes the use cases for running a local root service to be more consistent with the reasons operators said they had for using RFC 7706. 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. 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 BCP 14 [RFC2119] - [RFC8174] when, and only when, they appear in all capitals, as shown - here. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 2. Requirements In order to implement the mechanism described in this document: o The system MUST be able to validate every signed record in a zone with DNSSEC [RFC4033]. - o The system MUST have an up-to-date copy of the KSK used to sign - the DNS root. + o The system MUST have an up-to-date copy of the Key Signing Key + (KSK) [RFC4033] 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 service for the root zone on the same host. The authoritative root service MUST only respond to queries from the same host. One way to assure not responding to queries from other hosts is to run an authoritative server for the root that responds only on one of the loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 @@ -272,23 +276,23 @@ 4. Security Considerations A system that does not follow the DNSSEC-related requirements given in Section 2 can be fooled into giving bad responses in the same way as any recursive resolver that does not do DNSSEC validation on responses from a remote root server. Anyone deploying the method described in this document should be familiar with the operational benefits and costs of deploying DNSSEC [RFC4033]. - As stated in Section 1, this design explicitly only allows the local - copy of the root zone information to be available only from resolvers - on that host. This has the security property of limiting damage to + As stated in Section 1, this design explicitly allows the local copy + of the root zone information to be available only from resolvers on + that host. This has the security property of limiting damage to clients of any local resolver that might try to rely on an altered copy of the root. 5. IANA Considerations This document has no actions for IANA. 6. References 6.1. Normative References @@ -300,41 +304,54 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . + [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root + Servers by Running One on Loopback", RFC 7706, + DOI 10.17487/RFC7706, November 2015, + . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, . + 6.2. Informative References [Manning2013] Manning, W., "Client Based Naming", 2013, . + [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol + (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, + . + [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . Appendix A. Current Sources of the Root Zone The root zone can be retrieved from anywhere as long as it comes with all the DNSSEC records needed for validation. Currently, one can get - 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. One can - also get the root zone from IANA as a text file over HTTPS at + the root zone from ICANN by zone transfer (AXFR) [RFC5936] over TCP + from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. + One can also get the root zone from IANA as a text file over HTTPS at . 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 @@ -506,22 +523,21 @@ 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 . + resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html>. 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.