--- 1/draft-ietf-dnsop-7706bis-05.txt 2019-11-17 04:13:53.307803572 -0800 +++ 2/draft-ietf-dnsop-7706bis-06.txt 2019-11-17 04:13:53.343804495 -0800 @@ -1,19 +1,19 @@ Network Working Group W. Kumari Internet-Draft Google Updates: 7706 (if approved) P. Hoffman Intended status: Informational ICANN -Expires: February 27, 2020 August 26, 2019 +Expires: May 20, 2020 November 17, 2019 Running a Root Server Local to a Resolver - draft-ietf-dnsop-7706bis-05 + draft-ietf-dnsop-7706bis-06 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,21 +34,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 February 27, 2020. + This Internet-Draft will expire on May 20, 2020. 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,21 +65,21 @@ 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 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 . . . . . . . . . . . . 9 + B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 8 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 @@ -153,22 +153,22 @@ 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. This document changes the use cases for running a local root service - more consistent with the reasons operators said they had for using - RFC 7706. + 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. @@ -183,34 +183,34 @@ [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 key used to sign + o The system MUST have an up-to-date copy of the KSK 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 - in IPv6). Another method to have the resolver software also act - as an authoritative server for the root zone, but only for + in IPv6). Another method is to have the resolver software also + act as an authoritative server for the root zone, but only for answering queries from itself. 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. @@ -229,32 +229,30 @@ 2. Start the authoritative service for the root zone in a manner that prevents any system other than a recursive resolver on the same host from accessing it. The contents of the root zone MUST be refreshed using the timers from the SOA record in the root zone, as described in [RFC1035]. This inherently means that the contents of the local root zone will likely be a little behind those of the global root servers because those servers are updated when triggered by NOTIFY messages. - In a system that is using a local authoritative server for the root - zone. if the contents of the root zone cannot be refreshed before - the expire time in the SOA, the local root server MUST return a - SERVFAIL error response for all queries sent to it until the zone can - be successfully be set up again. Because this would cause the - recursive resolver to also fail, the resolver MUST immediatly switch - to using other (non-local) root servers if the resolver receives a - SERVFAIL response from a local root server. + 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 immediatly switch to using + 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 @@ -561,21 +559,22 @@ 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, Wouter Wijngaards, and Mukund Sivaraman. + Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and + Leo Vegoda. Authors' Addresses Warren Kumari Google Email: Warren@kumari.net Paul Hoffman ICANN