Internet Engineering Task Force M. Sivaraman
Internet-Draft Internet Systems Consortium
Intended status: Experimental S. Kerr
Expires: January 1, 2018 Oracle
S. Morris
Internet Systems Consortium
June 30, 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 January 1, 2018.

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 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

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 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, 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:

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:

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.

4.5. Notes

There are a number of cases that require special processing:

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, <TBD>
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:

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)

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/