[Docs] [txt|pdf] [Tracker] [Email] [Nits]



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, <https://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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <https://www.rfc-editor.org/info/rfc2181>.

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,
              <https://www.rfc-editor.org/info/rfc4033>.

   [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,
              <https://www.rfc-editor.org/info/rfc4034>.

   [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,
              <https://www.rfc-editor.org/info/rfc4035>.

   [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,
              <https://www.rfc-editor.org/info/rfc7706>.

   [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,
              <https://www.rfc-editor.org/info/rfc8109>.

   [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
              DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
              July 2017, <https://www.rfc-editor.org/info/rfc8198>.

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/