Internet Engineering Task Force M. Sivaraman Internet-Draft Internet Systems Consortium Intended status: Experimental S. Kerr Expires: December 31, 2017 Oracle S. Morris Internet Systems Consortium June 29, 2017 DNS Opportunistic Refresh for Resolvers draft-muks-dnsop-dns-opportunistic-refresh-00 Abstract This document describes a mechanism whereby a DNS resolver can opportunistically refresh the TTLs of cached records of a zone using serial number information carried in responses from the zone's nameservers. As well as improving resolver response time by reducing the need to make upstream queries, the mechanism can also reduce the workload of authoritative servers. 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 December 31, 2017. Copyright Notice Copyright (c) 2017 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 Sivaraman, et al. Expires December 31, 2017 [Page 1] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Opportunistic DNS Refresh . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Detailed Description . . . . . . . . . . . . . . . . . . . . 4 4.1. Resolver Behavior - Querying an Authoritative Server . . 4 4.2. Authoritative Server Behavior - Processing a Query . . . 4 4.3. Resolver Behavior - Processing a Response . . . . . . . . 5 4.4. Resolver Behavior - Processing a Subsequent Query . . . . 5 4.5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative references . . . . . . . . . . . . . . . . . . 8 9.2. Informative references . . . . . . . . . . . . . . . . . 8 Appendix A. Change history (to be removed before publication) . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction DNS secondary nameservers use the value in a zone's SOA RR's SERIAL field [RFC1035] to determine freshness of the copy of a zone that they are maintaining locally and so establish whether a zone transfer to update the zone is necessary. The SOA RR is retrieved either in response to a NOTIFY message from the primary or by the passing of an interval equal to the SOA refresh timeout. A comparison of the serial numbers of the stored zone and that in the SOA record [RFC1982] establishes whether a zone transfer is necessary. By using the SOA RR's SERIAL field, nameservers avoid redundant and unnecessary zone transfers for local data that is already fresh, thereby reducing network traffic and nameserver resource usage. This memo introduces a similar - but optional - scheme, to a regular DNS query. A DNS resolver requests an authoritative server to return the SOA record along with the the results of a query. By associating these records with the serial number of zone at the time they were retrieved, a resolver can use subsequent responses from the zone to determine whether cached records have changed; if not, the cached Sivaraman, et al. Expires December 31, 2017 [Page 2] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 records can continue to be used, so eliminating the need to re-fetch the record from its zone's nameservers. 2. 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]. 3. Opportunistic DNS Refresh 3.1. Overview The idea is best illustrated with an example: 1. At time t=0, a resolver queries an authoritative server of example.com for the AAAA record of www.example.com. It includes an EDNS0 option [RFC6891] that requests that the example.com nameservers also return the SOA RR of example.com. The authoritative server returns the AAAA record for www.example.com along with the copy of the current SOA record. It also returns the ZONESERIAL EDNS0 option that guarantees to the resolver that any change in the example.com zone will be accompanied by a change in the zone's serial number. Suppose that the AAAA record is the address 2001:DB8::1 and that it has a TTL of 3600. Also suppose that the serial number of the SOA record is 42. 2. At time t=3000, the resolver queries an authoritative server of example.com for the MX record of example.com. This query also includes the EDNS0 option requesting the SOA RR. The authoritative server returns the requested data, together with the SOA RR in the Additional Section of the response as well as the ZONESERIAL EDNS0 option. Assume that the SOA record indicates that the serial number is unchanged at 42. 3. At time t=4000, the resolver receives a query for the AAAA record of www.example.com. In the normal course of events the resolver would have to re-fetch the record because the cached record has expired. However, the resolver knows that had it queried for the AAAA record of www.example.com at t=3000, it would have got the same answer as it has cached (2001:DB8::1 and an initial TTL of 3600), since the query for the MX record showed that the zone's serial number was unchanged and that the server guarantees that the serial number will change on every update to the zone. The only difference would be that instead of the record being expired, the TTL of the record would now be 2600 (the original TTL of 3600 less the 1000 seconds that have elapsed since the query for the MX record). Instead of fetching the record again, Sivaraman, et al. Expires December 31, 2017 [Page 3] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 the resolver can set the TTL to 2600, reflecting the valid state that would have occurred had the resolver queried for the record at the same time as it queried for the MX record. Use of opportunistic refresh requires that both resolvers and authoritative servers signal their support for the protocol via an EDNS0 option. This is the ZONESERIAL option and is required because: o Resolvers need to explicitly request that authoritative servers include an SOA RR in their responses, since adding an SOA record to a response when it is not needed just wastes bandwidth. o Authoritative servers need to signal that the zone's serial number changes every time the contents of the zone change, so confirming to resolvers that the serial number is an indication of the zone's freshness. This should be the normal state of affairs, but some authoritative servers generate content on the fly and may not update the SOA serial number. Although omission of the SOA RR could be used as an indication that the server does not support opportunistic refresh, this feature allows zone freshness information to be extracted from any SOA record in the answer, e.g. responses returning NXDOMAIN or explicit queries for the SOA. Under these circumstances, the ZONESERIAL option is required in the response in order to prevent misinterpretation. 4. Detailed Description 4.1. Resolver Behavior - Querying an Authoritative Server To signal support for DNS opportunistic refresh, resolvers MUST add the ZONESERIAL EDNS0 option to their queries. Bit 7 of the option's FLAGS field is the request/acknowledge flag and MUST be clear in the request to the authoritative server. 4.2. Authoritative Server Behavior - Processing a Query Upon receiving a ZONESERIAL EDNS0 option with the request/acknowledge flag clear, the action of the authoritative server depends on the response being returned: o If the answer is a negative response (e.g. NODATA or NXDOMAIN), no special action is required: the SOA of the zone that was searched for the answer will be included in the response. o If the answer is a positive response or a referral, the SOA for the zone from which the answer was obtained SHOULD be included in the additional section of the answer. Sivaraman, et al. Expires December 31, 2017 [Page 4] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 In all cases, the authoritative server MUST include the ZONESERIAL EDNS0 option in the response. The request/acknowledge bit in the FLAGS field MUST also be set in the message. 4.3. Resolver Behavior - Processing a Response Upon receiving a positive response containing an SOA RR and a valid ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's serial number with the RRs in the answer. In addition, it SHOULD note the serial number as the indication of the zone's freshness along with the time at which the serial number was valid. If a negative response is received and the message contains a valid ZONESERIAL EDNS0 option, the resolver SHOULD update its record of the zone's serial number, as well as noting the time at which this serial number was valid. 4.4. Resolver Behavior - Processing a Subsequent Query When a resolver receives a query, it will check its cache to see whether the answer is present. If it is, but the TTL has expired, an opportunistic refresh-enabled resolver SHOULD check to see if the record is associated with a zone serial number. If it is, the resolver SHOULD compare the serial number against the latest serial number it has for the zone. If the numbers are the same, the resolver SHOULD calculate a new TTL: candidate TTL = Original TTL - (current time - latest serial number retrieval time) If this value is positive and the record is not signed, the resolver MAY set the TTL of the cached record to this value and return it to the client without re-querying the authoritative server. If the value is positive and the record is signed the resolver SHOULD calculate the time to signature expiration. If this is a postive value, the resolver MAY set the TTL of the record to: New TTL = MIN(Candidate TTL, Time to Signature Expiration) In all other cases (including cases where - perhaps for policy reasons - the resolver chooses not to extend the TTL), the resolver MUST NOT reset the TTL; instead, it should fetch a new copy of the record from the appropriate nameservers. Sivaraman, et al. Expires December 31, 2017 [Page 5] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 4.5. Notes There are a number of cases that require special processing: o An authoritative server receiving a misconfigured ZONESERIAL option in a query SHOULD return a FORMERR response. o A resolver receiving a misconfigured ZONESERIAL option in a response MUST NOT interpret the serial number in any SOA RR in that response as an indication of zone freshness. It MAY however regard the RRs in the response as valid. o If, in response to a query containing the ZONESERIAL option to a zone it has previously established supports this option, a resolver receives a response containing either no ZONESERIAL option or an invalid one, the resolver should assume that the zone can no longer guarantee that the serial number will change on every zone update. It MUST clear all existing serial number information for the zone related to opportunistic DNS refresh. Subequent queries to the zone SHOULD include the ZONESERIAL option, allowing the resolver to start building up refresh information again. o In the case of NS records, although the child zone is authoritative for the NS information, a resolver must periodically query for the parent's copy of the NS records to ensure that the delegation is still valid. To avoid the extension of an NS record's TTL preventing the resolver from querying the parent, the resolver MUST NOT extend the TTL of NS records using the method described here. o To avoid any complications related to transitive use of this scheme through forwarders and other intermediate resolvers where the nameserver may return a non- authoritative answer, nameservers that are not authoritative for a zone MUST NOT include a ZONESERIAL EDNS0 option in a response to a query for a name in that zone. o If Client Subnet [RFC7871] is enabled, resource records in the cache may be associated with a subnet. In these cases, the resolver MUST ensure that the zone serial number associated with such records is obtained from an SOA record associated with the identical subnet. Sivaraman, et al. Expires December 31, 2017 [Page 6] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 5. Option Format The opportunistic DNS refresh option is encoded as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ ! OPTION-CODE ! OPTION-LENGTH ! +-------------------------------+-------------------------------+ | FLAGS | +---------------+ ZONERSERIAL EDNS0 Option where: OPTION-CODE the EDNS0 option code assigned to opportunistic DNS refresh, OPTION-LENGTH the value 1. FLAGS Flags field. Bit 7 of this field is the request/acknowledge flag. This bit MUST be clear in requests from the resolver to the authoritative server and MUST be set in responses from the authoritative server to the resolver. By flipping the bit in a response, answers from misbehaving authoritiative servers that just copy unknown EDNS0 options from query to response are not mistakenly treated as being from servers that understand opportunistic DNS refresh. Bits 0 to 6 of the FLAGS field are reserved. They MUST be set to zero by the sender, and MUST be ignored by the receiving server. 6. Security Considerations TDB 7. IANA considerations The IANA is directed to assign an EDNS0 option code for the ZONERSERIAL option from the DNS EDNS0 Option Codes (OPT) registry as follows: Sivaraman, et al. Expires December 31, 2017 [Page 7] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 +-------+------------+--------+-----------------+ | Value | Name | Status | Reference | +-------+------------+--------+-----------------+ | TBD | ZONESERIAL | TBD | [This document] | +-------+------------+--------+-----------------+ 8. Acknowledgements This document evolved from discussions with a number of people during and after IETF-94: Ray Bellis, Geoff Huston, George Michaelson, Cathy Almond, Mark Andrews, Evan Hunt, Witold Krecicki. We would also like to acknowledge Bob Harold, who suggested the underlying idea in a post to the DNSOP mailing list back in October 2015. 9. References 9.1. Normative references [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . 9.2. Informative references [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, . Appendix A. Change history (to be removed before publication) o draft-muks-dnsop-dns-opportunistic-refresh-00 Initial draft. Sivaraman, et al. Expires December 31, 2017 [Page 8] Internet-Draft DNS Opportunistic Refresh for Resolvers June 2017 Authors' Addresses Mukund Sivaraman Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 US Email: muks@isc.org URI: http://www.isc.org/ Shane Kerr Oracle Email: shane@timetravellers.org Stephen Morris Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 US Email: stephen@isc.org URI: http://www.isc.org/ Sivaraman, et al. Expires December 31, 2017 [Page 9]