Internet DRAFT - draft-muks-dnsop-dns-opportunistic-refresh
draft-muks-dnsop-dns-opportunistic-refresh
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, <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:
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, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<http://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
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,
<http://www.rfc-editor.org/info/rfc7871>.
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]
