--- 1/draft-ietf-dnsop-7706bis-06.txt 2020-01-12 17:13:14.523199132 -0800 +++ 2/draft-ietf-dnsop-7706bis-07.txt 2020-01-12 17:13:14.555199946 -0800 @@ -1,19 +1,19 @@ Network Working Group W. Kumari Internet-Draft Google Updates: 7706 (if approved) P. Hoffman Intended status: Informational ICANN -Expires: May 20, 2020 November 17, 2019 +Expires: July 15, 2020 January 12, 2020 Running a Root Server Local to a Resolver - draft-ietf-dnsop-7706bis-06 + draft-ietf-dnsop-7706bis-07 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 @@ -34,71 +34,71 @@ 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 May 20, 2020. + This Internet-Draft will expire on July 15, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + 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 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 described in the Simplified BSD License. Table of Contents 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 5.2. Informative References . . . . . . . . . . . . . . . . . 7 + 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 - B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 8 + B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 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 is within 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 because negative answers are sometimes cached for a much - shorter period of time. + root zone. 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. 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 @@ -135,21 +135,24 @@ 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 uses authoritative service running on the same machine as the recursive resolver. Common open source recursive resolver software does not need to add new functionality to act as an 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. + 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]. 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 @@ -236,24 +239,24 @@ be a little behind those of the global root servers because those servers are updated when triggered by NOTIFY messages. There is a risk that a system using a local authoritative server for the root zone cannot refresh the contents of the root zone before the expire time in the SOA. A system using a local authoritative server for the root zone MUST NOT serve stale data for the root zone. To mitigate the risk that stale data is served, the local root server MUST immediately switch to using non-local root servers. - In a resolver that is using an internal service for the root zone. - if the contents of the root zone cannot be refreshed before the - expire time in the SOA, the resolver MUST immediately switch to using - non-local root servers. + In a resolver that is using an internal service for the root zone, if + the contents of the root zone cannot be refreshed before the expire + time in the SOA, the resolver MUST immediately switch to using non- + local root servers. In the event that refreshing the contents of the root zone fails, the results can be disastrous. For example, sometimes all the NS records for a TLD are changed in a short period of time (such as 2 days); if the refreshing of the local root zone is broken during that time, the recursive resolver will have bad data for the entire TLD zone. An administrator using the procedure in this document SHOULD have an automated method to check that the contents of the local root zone are being refreshed; this might be part of the resolver software. @@ -269,50 +272,53 @@ 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 new - root zone server to be run on the same host, answering queries only - from resolvers on that host, in order to prevent the server from - serving authoritative answers to any system other than the recursive - resolver. This has the security property of limiting damage to any - other system that might try to rely on an altered copy of the root. + 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 + clients of any local resolver that might try to rely on an altered + copy of the root. -5. References +5. IANA Considerations -5.1. Normative References + This document has no actions for IANA. + +6. References + +6.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . -5.2. Informative References +6.2. Informative References [Manning2013] Manning, W., "Client Based Naming", 2013, . [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 @@ -462,36 +468,35 @@ 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: BIND 9.14 - 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: + BIND 9.14 can set up a local mirror of the root zone with a small + configuration option: 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 + See the documentation for BIND 9.14 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"