INFORMATIONAL

Errata Exist

Internet Engineering Task Force (IETF) W. Kumari Request for Comments: 7706 Google Category: Informational P. Hoffman ISSN: 2070-1721 ICANN November 2015 Decreasing Access Time to Root Servers by Running One on Loopback 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 a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7706. Kumari & Hoffman Informational [Page 1]

RFC 7706 Running Root on Loopback November 2015 1 . Introduction Kumari & Hoffman Informational [Page 3]

RFC 7706 Running Root on Loopback November 2015 AggressiveNSEC]. 1.1 . Requirements Notation RFC2119]. 2 . Requirements RFC4033]. o The system MUST have an up-to-date copy of the DNS root key. 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 on one of the IPv4 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 Kumari & Hoffman Informational [Page 4]

RFC 7706 Running Root on Loopback November 2015 3 . Operation of the Root Zone on the Loopback Address Appendix A for some current locations of sources.) 2. Start the authoritative server with the root zone on a loopback address that is not in use. For IPv4, this would typically be 127.0.0.1, but if that address is in use, any address in 127/8 is acceptable. For IPv6, this would be ::1. 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. 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. 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. One way to do this is to have a separate process that periodically checks the SOA of the root zone from the local root zone and makes sure that it is changing. At the time that this document is published, the SOA for the root zone is the digital representation of the current date with a two-digit counter appended, and the SOA is changed every day even if the contents of the root zone are unchanged. For example, the SOA of the root zone on January 2, 2015 was 2015010201. A process can use this fact to create a check for the contents of the local root zone (using a program not specified in this document). Kumari & Hoffman Informational [Page 5]

RFC 7706 Running Root on Loopback November 2015 4 . Using the Root Zone Server on the Loopback Address Section 3 simply specifies the local address as the place to look when it is looking for information from the root. All responses from the root server must be validated using DNSSEC. Note that using this configuration will cause the recursive resolver to fail if the local root zone server fails. See Appendix B for more discussion of this for specific software. To test the proper operation of the recursive resolver with the local root server, use a DNS client to send a query for the SOA of the root to the recursive server. Make sure the response that comes back has the AA bit in the message header set to 0. 5 . Security Considerations 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 a loopback address, 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. 6 . References 6.1 . Normative References RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. Kumari & Hoffman Informational [Page 6]

RFC 7706 Running Root on Loopback November 2015 B.1 . Example Configuration: BIND 9.9 Kumari & Hoffman Informational [Page 9]

RFC 7706 Running Root on Loopback November 2015 B.2 . Example Configuration: Unbound 1.4 and NSD 4 Kumari & Hoffman Informational [Page 10]

RFC 7706 Running Root on Loopback November 2015 B.3 . Example Configuration: Microsoft Windows Server 2012 Kumari & Hoffman Informational [Page 11]

RFC 7706 Running Root on Loopback November 2015 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 localhost, and not a recommendation to do so. Authors' Addresses Warren Kumari Google Email: Warren@kumari.net Paul Hoffman ICANN Email: paul.hoffman@icann.org Kumari & Hoffman Informational [Page 12]