DNS Opportunistic Refresh for ResolversInternet Systems Consortium950 Charter StreetRedwood City94063CAUSmuks@isc.orghttp://www.isc.org/Oracleshane@timetravellers.orgInternet Systems Consortium950 Charter StreetRedwood City94063CAUSstephen@isc.orghttp://www.isc.org/
Operations and Management Area
Internet Engineering Task ForceThis 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.DNS secondary nameservers use the value in a zone's SOA RR's SERIAL
field 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 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.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 .
The idea is best illustrated with an example: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 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.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.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: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.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.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.Upon receiving a ZONESERIAL EDNS0 option with the request/acknowledge
flag clear, the action of the authoritative server depends on the response
being returned: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.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.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.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.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.There are a number of cases that require special processing:An authoritative server receiving a misconfigured ZONESERIAL
option in a query SHOULD return a FORMERR response.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.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.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.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.If Client Subnet 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.The opportunistic DNS refresh option is encoded as follows:
+---------------+
where:the EDNS0 option code assigned to
opportunistic DNS refresh, <TBD>the value 1.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.TDBThe IANA is directed to assign an EDNS0 option code for the
ZONERSERIAL option from the DNS EDNS0 Option Codes (OPT) registry as
follows:ValueNameStatusReferenceTBDZONESERIALTBD[This document]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.
draft-muks-dnsop-dns-opportunistic-refresh-00
Initial draft.