Network Working Group P. Hoffman Internet-Draft M. Larson Updates: 4034, 4035 (if approved) ICANN Intended status: Standards Track March 02, 2018 Expires: September 3, 2018 Additional Method for Filling DNS Caches draft-hl-dnsop-cache-filling-00 Abstract DNS recursive resolvers do not always have access to the authoritative resolvers from which they need to get information. For example, when the DNS root servers are under DDoS attack, a recursive resolver may not be able to get an answer from any of the root servers. This document describes how resolvers can populate their caches with zone information, and keep their cache populated, using out-of-band mechanisms that do not rely on the DNS protocol. The protocol is primarily designed for the root zone, but can apply to any zone that wants to participate by publishing values to be cached. 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 September 3, 2018. Copyright Notice Copyright (c) 2018 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 Hoffman & Larson Expires September 3, 2018 [Page 1] Internet-Draft cache-filling March 2018 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. 1. Introduction As decscribed in [RFC1035], recursive resolvers keep a cache of resource records that they have already seen. Entries in that cache are removed when the TTL of the records reach zero. Filling the cache for the root zone begins with priming, as decribed in [RFC8109]. Some useful DNS protocol extensions rely on entries being in a resolver's cache. In specific, "aggressive NSEC" ([RFC8198]) reduces the need for a resolver to be in contact with an authoritative server because it uses information in its cache to prevent asking about zones that do not exist. The more entries that the cache has in it, the more effective a resolver can use aggressive NSEC. This document describes a new method for resolvers to fill their caches with zone information, and keep their cache populated, using out-of-band mechanisms that do not rely on the DNS protocol. It introduces the following: o The use cases for which this protocol might be useful o A method for a resolver to get batched DNS entries that it will include in its cache o A message format for carrying those batched DNS entries that is a trivial extension to the DNS wire format from [RFC1035] o An optional method to find servers that deliver the batched entries for various zones A primary design goal for this protocol is that if the protocol fails for any reason, a resolver still accesses authoritative servers just as it does today. That is, this protocol helps fill the resolvers cache so that it avoids talking to the authoritative server over DNS, but it isn't intended to preclude the resolver from doing so. Note that this document operates differently than the method described in [RFC7706]. In that document, the resolver operator changes the source of its root information; in this document, the resolver can still get its information from the regular DNS Hoffman & Larson Expires September 3, 2018 [Page 2] Internet-Draft cache-filling March 2018 authoritative servers (such as the root servers), but can also fill its cache from sources other than the authoritative servers. This document assumes that the resolver is validating responses with DNSSEC; it does not change anything about a resolver's processing of DNSSEC data. 1.1. Use Cases The primary use case it to give resolver operators more consistent access to DNS data from authoritative servers, particularly for the root zone. The DNS root server system has experienced distributed denial of service (DDoS) attacks that have, from certain points on the network, made a majority of root servers unresponsive to some resolvers while under attack. If a resolver can extend the intervals between when it needs to reach an authoritative server, the resolver can provide more reliable access to its customers. The second use case is to speed up answers from the recursive servers to their customers by having more data in the servers' caches. This is achieved by refilling the entries in a resolver's cache before they expire. This is primarily of value to resolvers using aggressive NSEC caching [RFC8198]. Although both of these use cases focus on the root zone of the DNS, they can apply to other zones as well. For example, some TLDs allow complete access to their zone data, and they might use the publication methodology described in this document. However, the method described here might not work well for zones where some entries have TTLs that are much shorter than the 1- and 2-day TTLs in the root zone. 1.2. Terminology 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 RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant CBOR implementations. Throughout this document, the term "DNSSEC" means the protocols defined in [RFC4033], [RFC4034], [RFC4035] and all RFCs that update those three. A great deal of DNS-related terminology can be found in [I-D.ietf-dnsop-terminology-bis]. Hoffman & Larson Expires September 3, 2018 [Page 3] Internet-Draft cache-filling March 2018 2. Protocol Overview A resolver that wants to fill its cache for a zone refers to one or more URLs of the service that provides the cache-filling information. The URLs might come out of band (for example, in the resolver's configuration could specify URLs for a zone), or can be found with the new CACHE-FILL RRtype (described in Section 3). Once it has the URL, the resolver fetches a set of entries for its cache. The format described in Section 4. Basically, the format is a series of DNS queries and responses encoded in DNS wire format. The resolver processes the request-response pairs in the retrived data just as it would any request-response pairs it sees from clients (such as checking for and discarding records that should not be in the response and performing DNSSEC validation). The new data is interpreted as queries to and replies from the specified zone's authoritative name server. It then adds the responses to its cache, acting as if each response is the last response in a chain of queries to the authoritative server. 3. Discovery of Servers That Provide Cache-Filling Information A resolver contacts the server that has the cache-filling material by resolving a URL. That URL might come out of band, or might be discovered by sending a query for the zone with the CACHE-FILL RRtype. A zone might have many records in the CACHE-FILL RRset for alternate URLs. Using out-of-band URLs is acceptable if the resolver operator believes that the source would give the same answers as the authoritative server would have given. If a resolver wants to use this protocol for initial root zone priming, the URL would inherently need to be out-of-band (because the resolver doesn't yet have any ability to resolve names) and the URL MUST have an IP address as the host portion of the URL. 3.1. The CACHE-FILL RRtype The CACHE-FILL resource record is used to store a list of URLs. The Type value for the CACHE-FILL RR is TBD1. The CACHE-FILL RR is defined only for the IN class. The CACHE-FILL RR has no special Time-to-Live (TTL) requirements. The RDATA for an CACHE-FILL RR is a text string that holds a URL. The presentation format has the URL in a quoted string. Hoffman & Larson Expires September 3, 2018 [Page 4] Internet-Draft cache-filling March 2018 The CACHE-FILL RR for a zone is located at the zone apex. For example, the record below specifies a CACHE-FILL RR for the root zone because it is located at the root zone's apex (the root node of the DNS): . 86400 IN CACHE-FILL "http://cdn.example.com/root-cache-fill" See Section 7 for the registration of RRtype TBD1. 4. Message Format The format of the cache-filling data is a series of DNS request- response message pairs in wire format as defined in [RFC1035]. Each request and response message in the data MUST be formatted as a TCP DNS message with the two-octet header. HTTP servers that are providing this data SHOULD use the media type of application/TBD2. See Section 7 for the registration of this media type. 5. Filling the Cache Using the Data Received *** Warning that the origin must be specified for out-of-band URLs to know the context to interpret the data retrieved. *** Determining how often to fetch the cache file file. There are several options and more text is needed here. One option would be to fetch the file when first RRset from that zone expires, i.e., the RRset with the lowest TTL. Another option is to use the zone's SOA refresh timer to determine how often to refetch the cache fill file. 5.1. Parsing the Received Data The resolver parses the data received as follows: 1. Take the first two octets as the message length, then read that many octets of data. Verify that this is a properly-formatted DNS request. 2. Take the next two octets as the message length, then read that many octets of data. Verify that this is a properly-formatted DNS response, and that the Question section of this response matches the Question section of the immediately-preceding message. 3. Process this pair of messages; see Section 5.2. 4. Repeat if there is more octets in the data. Hoffman & Larson Expires September 3, 2018 [Page 5] Internet-Draft cache-filling March 2018 If there is an error in parsing, the resolver must stop processing and not use any data starting at the point where the error occurred. 5.2. Processing Parsed Messages After a request-response pair is parsed, the data MUST be treated as if the request had come from a client and the response had come from the authoritative server for the zone. For example, if the resolver is normally performing DNSSEC validation on responses to queries to authoritative servers, the resolver MUST validate the processed data using the same rules. The data MUST be interpreted as queries to and replies from the specified zone's authoritative name server. The resolver MUST use the normal rules (such as those from [RFC2181] for data in the Authoritative and Additional sections in responses) before putting that data into the cache. For responses from the root zone, all data is in-bailiwick, but for lower zones, the resolver MUST only fill its cache with data it would have accepted from those zones, i.e., data that is in-bailwick for that zone. The resolver SHOULD process the data immediately after it is received so that the TTLs are treated as if they had just been received from an authoritative server. The exception to this rule would be if a resolver is using a stored version of data as described in Section 5.4 5.3. Using the Cache-Filling to Initially Prime Root Server Information *** This will require that resolvers come with a second "root hints" file that has URLs, and those URLs will have to have IP addresses. The servers at those addresses need to only use TLS extensions that do not require the client to access the DNS. This is possible, but tricky. Maybe punt this to a separate draft after this one completes? 5.4. Using the Cache-Filling to Re-Prime Root Server Information A resolver following this protocol for the root zone could keep the latest copy of the root zone data it received on disk and use that data to fully prime its cache after a restart. This can be useful if the root server system is not available when the resolver starts up. Note, however, that it is possible that some of the data would be out of date and incorrect because the root zone has changed, so the resolver SHOULD immediatly pull a new version of the cache-filling data after re-priming. Hoffman & Larson Expires September 3, 2018 [Page 6] Internet-Draft cache-filling March 2018 6. Security Considerations If a malicious actor can hijack the source of the cache-filling data, they can cause that data to be used by everyone who accesses that source. This will not affect signed records for resolvers who are validating with DNSSEC, but will affect unsigned records, and all resolvers that are not validating with DNSSEC. HTTPS URLs for the cache-filling data give privacy and prevent modification of unsigned data such as glue records. Resolvers SHOULD prefer HTTPS URLs to HTTP URLs. It is possible (but unlikely) that URLs with different schemes (such as for FTP) will be used, and these URLs could have very different security properties than HTTPs URLs. *** There are certainly going to be some more. 7. IANA Considerations *** Registration for CACHE-FILL RRtype (TBD1) *** New media type for responses (TBD2) 8. References 8.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, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . 8.2. Informative References [I-D.ietf-dnsop-terminology-bis] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", draft-ietf-dnsop-terminology-bis-08 (work in progress), November 2017. Hoffman & Larson Expires September 3, 2018 [Page 7] Internet-Draft cache-filling March 2018 [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, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, 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, . [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS Resolver with Priming Queries", BCP 209, RFC 8109, DOI 10.17487/RFC8109, March 2017, . [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . Appendix A. Design Rationale A.1. Design Rationale for the Message Format The paired message format was used instead of master file format because resolvers already know how to process request-response pairs, but don't currently stuff sets of records into their cache. A.2. Design Rationale for using URLs of Data Instead of AXFR of the Zone *** CDNs have already optimized for content delivery, so building a scalable AXFR service for the root zone would not be required. *** Resolvers adding HTTPS fetching is probably less work than adding full AXFR logic. Hoffman & Larson Expires September 3, 2018 [Page 8] Internet-Draft cache-filling March 2018 Authors' Addresses Paul Hoffman ICANN Email: paul.hoffman@icann.org Matt Larson ICANN Email: matt.larson@icann.org Hoffman & Larson Expires September 3, 2018 [Page 9]