Network Working Group W. Kumari, Ed. Internet-Draft Google Intended status: Informational P. Hoffman, Ed. Expires: January 4, 2015 VPN Consortium July 3, 2014 Securely Distributing the DNS Root draft-wkumari-dnsop-dist-root-01 Abstract This document recommends that recursive DNS resolvers get copies of the root zone, validate it using DNSSEC, populate their caches with the information, and also give negative responses from the validated zone. [[ Note: This document is largely a discussion starting point. ]] 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 http://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 January 4, 2015. Copyright Notice Copyright (c) 2014 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 (http://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 Kumari & Hoffman Expires January 4, 2015 [Page 1] Internet-Draft Securely Distributing the DNS Root July 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Open Question: How Should the Root Zone Be Distributed? . . . 5 4. Open Question: Should Responses Have the AA Bit Set? . . . . 5 5. Pros and Cons of this Technique . . . . . . . . . . . . . . . 6 5.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction One of the main advantages of a DNSSEC-signed root zone is that it doesn't matter where you get the data from, as long as you validate the contents of the zone using DNSSEC information. From that point on, you know all of the contents of the root zone at the time that you retrieve and validated the zone. When a typical recursive resolver starts up, it has an empty cache, the addresses of the root servers. As it begins answering queries, it populates its cache by making a number of queries to the set of root servers, and caching the results. All queries for root zone names that come to the recursive resolver that are not in either its positive or negative cache are sent to one of the root servers. This process cause a large number of the queries that hit the root are so called "junk" queries, such as queries for second-level domains in non-existent TLDs. This document is describes a mechanism to populate caches in recursive resolvers with the verified contents of the full root zone so that the recursive resolvers have the all of root zone content cached. This technique can be viewed as pre-populating a resolver's cache with the root zone information by retrieving a signed copy of the root zone and verifying the contents. The two goals of this mechanism are to provide faster negative responses to stub resolver queries that contain junk queries, and to reduce the number of junk queries sent to the root servers. The Kumari & Hoffman Expires January 4, 2015 [Page 2] Internet-Draft Securely Distributing the DNS Root July 2014 mechanism has other minor advantages, but those two are the focus of this document. 1.1. 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 [RFC2119]. 2. Requirements In the discussion below, the term "legacy operation" means the way that a recursive resolver acts when it is not using the mechanism describe in this document, namely as a normal validating recursive resolver with no other special features. In order to implement the mechanism described in this document, a recursive resolver MUST support DNSSEC, and MUST have an up-to-date copy of the DNS root key. A recursive resolver using this mechanism MUST follow these steps at startup or after clearing its cache: 1. The resolver determines the list of root zone delivery servers. The delivery mechanism is not yet defined in this document, and some possible options for it are described in Section 3. 2. The resolver SHOULD randomly sort the list of zone delivery servers so that all the servers get a fairly even distribution of queries. 3. The resolver SHOULD attempt to transfer the signed root zone using the transfer protocol from each one of the servers until either success is achieved or the list has been exhausted. The resolver MAY attempt to transfer in parallel to minimize startup latency. If the root zone cannot be transferred, the resolver logs this as an error, and MUST fall back to legacy operation. 4. The resolver MUST validate the records in the zone using DNSSEC. If any of the records do not validate, the resolver MUST discard all records received, MUST log an error, and SHOULD try the next server in the list. If no transferred copy of the root zone can be validated, the resolver logs this as an error, and falls back to legacy operation. Note that the resolver MUST validate all of the zone contents, and MUST NOT start using the new contents until all have been validated; the resolver MUST NOT use "lazy validation". This means that the addition of the zone data MUST be an atomic operation. Kumari & Hoffman Expires January 4, 2015 [Page 3] Internet-Draft Securely Distributing the DNS Root July 2014 The resolver MAY store the contents of the validated root zone to disk. If the resolver has a stored copy of the root zone, and the data in the zone is not expired, and that copy was written within the refresh time listed in the zone, the resolver MAY load that zone instead of transferring. Once the resolver has transferred and validated the zone, it MUST attempt to keep its copy of the root zone up to date. This includes following the refresh, retry, expire logic, with certain modifications: o If the zone expires (for example, because it cannot retransfer because of blocked TCP connections), the resolver MUST fall back to legacy operation and MUST log an error. It MUST NOT return SERVFAIL to queries only due to its copy of the root zone being expired. o The resolver MUST validate the contents of the records in the zone using DNSSEC for every transfer. The resolver SHOULD try alternate servers if the validation fails. If the resolver is unable to transfer a copy of the zone that validates, it MUST treat this as an error, MUST discard the received records, and MUST fail back to legacy operation. Note that the resolver MUST validate all of the zone contents, and MUST NOT start using the new contents until all have been validated; the resolver MUST NOT use "lazy validation". This means that the replacement of the current zone data MUST be an atomic operation. o The resolver SHOULD attempt to restart this process at every retry interval for the root zone. o The resolver MUST set the AD bit on responses to queries for records in the root zone. This action is the same as if it had inserted the entry into its cache through a "normal" query that received a DNSSEC-validated answer. o The resolver MUST set the TTL on responses in the same fashion as it would in legacy operation. The difference here is that, when the TTL times out, instead of fetching the new answer from the root, the resolver simply starts the TTL at the maximum listed in the root zone. Compliant nameservers software MUST include an option to securely cache the root zone (an example name for this option could be "transfer-and-validate-root [yes|no]"). That is, the mechanism described in this document MUST be optional, and the cache operator MUST be able to turn it off and on. Kumari & Hoffman Expires January 4, 2015 [Page 4] Internet-Draft Securely Distributing the DNS Root July 2014 3. Open Question: How Should the Root Zone Be Distributed? The signed root zone can be distributed over almost any protocol. Because the zone is signed, the distribution protocol does not need to be authenticated. Suggestions for the distribution mechanism include: AXFR zone transfer within the DNS HTTP, most likely with appropriately-tuned caching FTP [[ Others... ]] Note that with any of these methods, the zone does not need to be transferred from the root servers themselves. Instead, a simple discovery mechanism can be built into the protocol that lets a recursive resolver discover where there are servers that will let it transfer the root zone. 4. Open Question: Should Responses Have the AA Bit Set? A recursive resolver that has a securely validated copy of the root can be thought of in at least two ways: as a smarter cache, or as a pseudo-slave server for the root. This section discusses the ramifications of those two choices. In both scenarios, the resolver will send back NXDOMAIN responses for junk queries without sending queries to the root and the resolver will set the AD bit on the responses. However, the two scenarios differ in whether or not the responses have the AA bit set. A smarter cache does not set the AA bit. The responses for any query for a name in the root or an NXDOMAIN that is being sent because the TLD is junk come back with the AD bit set but the AA bit not set, just as it would in legacy operation. A pseudo-slave to the root sets the AA bit in response to any query for a name in the root or an NXDOMAIN that is being sent because the TLD is junk. The reason that this is called a pseudo-slave instead of a slave is that there is a general expectation that a slave has a relationship with the master that would cause the slave to be notified of changes in the master with a NOTIFY announcement; that is not the case here. It acts a slave because it knows exactly how the master would reply at the time that it retrieve the signed zone, but it is a pseudo-slave because the master has no way of alerting it of changes. Kumari & Hoffman Expires January 4, 2015 [Page 5] Internet-Draft Securely Distributing the DNS Root July 2014 The advantage of a recursive resolver acting as a pseudo-slave is that other resolvers that demand authoritative answers can ask if for those. However, there are few scenarios in which those demanding resolvers exist. The disadvantage of a recursive resolver acting as a pseudo-slave is that there is no way to signal that it is a pseudo- slave and not a real slave. Thus, someone seeing the AA bit set might thing that the resolver is a real slave. This opens the can of worms about trusting the settings of the AA and AD bits in responses. 5. Pros and Cons of this Technique This is primarily a tracking / discussion section, and the text is kept even looser than in the rest of this doc. These are not ordered. 5.1. Pros o Junk queries / negative caching - Currently, a significant number of queries to the root servers are "junk" queries. Many of these queries are TLDs that do not (and may never) exist in the root Another significant source of junk is queries where the negative TLD answer did not get cached because the queries are for second- level domains (a negative cache entry for "foo.example" will not cover a subsequent query for "bar.example"). o DoS against the root service - By distributing the contents of the root to many recursive resolvers, the DoS protection for customers of the root servers is significantly increased. A DDoS may still be able to take down some recursive servers, but there is much more root service infrastructure to attack in order to be effective. Of course, there is still a zone distribution system that could be attacked (but it would need to be kept down for a much longer time to cause significant damage, and so far the root has stood up just fine to DDoS. o Small increase to privacy of requests - This also removes a place where attackers could collect information. Although query name minimization also achieves some of this, it does still leak the TLDs that people behind a resolver are querying for, which may in itself be a concern (for example someone in a homophobic country who is querying for a name in .gay). 5.2. Cons o Loss of agility in making root zone changes - Currently, if there is an error in the root zone (or someone needs to make an emergency change), a new root zone can be created, and the root server operators can be notified and start serving the new zone Kumari & Hoffman Expires January 4, 2015 [Page 6] Internet-Draft Securely Distributing the DNS Root July 2014 quickly. Of course, this does not invalidate the bad information in (long TTL) cached answers. Notifying every recursive resolver is not feasible. Currently, an "oops" in the root zone will be cached for the TTL of the record by some percentage of servers. Using the technique described above, the information may be cached (by the same percentage of servers) for the refresh time + the TTL of the record o No central monitoring point - DNS operators lose the ability to monitor the root system. While there is work underway to implement better instrumentation of the root server system, this (potentially) removes the thing to monitor. o Increased complexity in nameserver software and their operations - Any proposal for recursive servers to copy and serve the root inherently means more code to write and execute. Note that many recursive resolvers are on inexpensive home routers that are rarely (if ever) updated. o Changes the nature and distribution of traffic hitting the root servers - If all the "good" recursive resolvers deploy root copying, then root servers end up servicing only "bad" recursive resolvers and attack traffic. The roots (could) become what AS112 is for RFC1918. 6. IANA Considerations This document requires no action from the IANA. 7. Security Considerations A resolver that uses this mechanism but does not do full DNSSEC validation on the data it uses can obviously cause serious security issues because it can be fooled into giving wrong answers. [[ More? ]] 8. Acknowledgements The editors fully acknowledge that this is not a new concept, and that we have chatted with many people about this. If we have spoken to you and your name is not listed below, let us know. 9. Contributors The general concept in this document is not new; there have been discussions regarding recursive resolvers copying the root zone for Kumari & Hoffman Expires January 4, 2015 [Page 7] Internet-Draft Securely Distributing the DNS Root July 2014 many years. The fact that the root zone is now signed with DNSSEC makes implementing some of these techniques more feasible. The following is an unordered list of individuals have contributed text and / or significant discussions to this document. Steve Crocker - Shinkuro Jaap Akkerhuis - NLnet Labs David Conrad - Virtualized, LLC. Lars-Johan Liman - Netnod Suzanne Woolf - Individual Roy Arends - Nominet Olaf Kolkman - NLnet Labs Danny McPherson - Verisign Joe Abley - Dyn Jim Martin - ISC Jared Mauch - NTT America Rob Austien - Dragon Research Labs Sam Weiler - Parsons 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Warren Kumari (editor) Google 1600 Amphitheatre Parkway Mountain View, Ca 94043 US Email: Warren@kumari.net Kumari & Hoffman Expires January 4, 2015 [Page 8] Internet-Draft Securely Distributing the DNS Root July 2014 Paul Hoffman (editor) VPN Consortium Email: paul.hoffman@vpnc.org Kumari & Hoffman Expires January 4, 2015 [Page 9]