draft-muks-dnsop-dns-opportunistic-refresh.xml

<?xml version="1.0"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<?rfc tocappendix="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc comments="no" ?>
<?rfc inline="yes" ?>
<rfc category="exp" docName="draft-muks-dnsop-dns-opportunistic-refresh-00" ipr="trust200902">

  <front>

    <title>DNS Opportunistic Refresh for Resolvers</title>

    <author fullname="Mukund Sivaraman" initials="M." surname="Sivaraman">
      <organization>Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <region>CA</region>
          <country>US</country>
        </postal>
        <email>muks@isc.org</email>
        <uri>http://www.isc.org/</uri>
      </address>
    </author>

    <author fullname="Shane Kerr" initials="S." surname="Kerr">
      <organization>Oracle</organization>
      <address>
        <email>shane@timetravellers.org</email>
      </address>
    </author>

    <author fullname="Stephen Morris" initials="S." surname="Morris">
      <organization>Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <region>CA</region>
          <country>US</country>
        </postal>
        <email>stephen@isc.org</email>
        <uri>http://www.isc.org/</uri>
      </address>
    </author>

    <date/>

    <!-- Meta-data Declarations -->

    <area>Operations and Management Area</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- <keyword>dns</keyword> -->

    <abstract>
      <t>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.</t>
    </abstract>

  </front>

  <middle>

    <section title="Introduction">
      <t>DNS secondary nameservers use the value in a zone's SOA RR's SERIAL
      field <xref target="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 <xref
      target="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.</t>

      <t>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.</t>

    </section>

    <section  title="Requirements Notation">
      <t>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 <xref target="RFC2119"/>.
      </t>
    </section>

    <section title="Opportunistic DNS Refresh">
      <section title="Overview">
        <t>The idea is best illustrated with an example:</t>

        <t><list style="numbers">

	      <t>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 <xref target="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.</t>

	      <t>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.</t>

	      <t>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.</t>

	    </list></t>

	    <t>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:</t>

        <t><list style="symbols">

	      <t>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.</t>

	      <t>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.</t>

        </list></t>

      </section>

    </section>

    <section title="Detailed Description">
      <section title="Resolver Behavior - Querying an Authoritative Server">
        <t>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.</t>
      </section>

      <section title="Authoritative Server Behavior - Processing a Query">
        <t>Upon receiving a ZONESERIAL EDNS0 option with the request/acknowledge
        flag clear, the action of the authoritative server depends on the response
        being returned:</t>
  
        <t><list style="symbols">
  
          <t>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.</t>
  
          <t>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.</t>
 
        </list></t>

        <t>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.</t>
      </section>

      <section title="Resolver Behavior - Processing a Response">
    	<t>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.</t>

        <t>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.</t>
      </section>

      <section title="Resolver Behavior - Processing a Subsequent Query">
    	<t>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: </t>
    
    	<t>candidate TTL = Original TTL - (current time - latest serial number retrieval
    	time)</t>
    
    	<t>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.</t>

	    <t>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:</t>

        <t>New TTL = MIN(Candidate TTL, Time to Signature Expiration)</t>

    	<t>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.</t>
      </section>

      <section title="Notes">

        <t>There are a number of cases that require special processing:</t>

        <t><list style="symbols">

	      <t>An authoritative server receiving a misconfigured ZONESERIAL
	      option in a query SHOULD return a FORMERR response.</t>

	      <t>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.</t>

	      <t>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.</t>

	      <t>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.</t>

	      <t>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.</t>

	      <t>If Client Subnet <xref target="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.</t>

	    </list></t>

      </section>

    </section>

    <section title="Option Format">
      <t>The opportunistic DNS refresh option is encoded as follows:</t>

      <figure align="center" title="ZONERSERIAL EDNS0 Option">
        <artwork align="center">
          <![CDATA[
                     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     |]]>
+---------------+
        </artwork>
      </figure>

      <t>where:</t>

      <t><list style="hanging">

        <t hangText="OPTION-CODE">the EDNS0 option code assigned to
        opportunistic DNS refresh, &lt;TBD&gt;</t>

        <t hangText="OPTION-LENGTH">the value 1.</t>

	    <t hangText="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.</t>

	    <t>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.</t>

      </list></t>
    </section>

    <section title="Security Considerations" anchor="sec-security">
      <t>TDB</t>
    </section>

    <section title="IANA considerations">
      <t>The IANA is directed to assign an EDNS0 option code for the
      ZONERSERIAL option from the DNS EDNS0 Option Codes (OPT) registry as
      follows:</t>

      <texttable>

        <ttcol>Value</ttcol>
        <ttcol>Name</ttcol>
        <ttcol>Status</ttcol>
        <ttcol>Reference</ttcol>

        <c>TBD</c>
        <c>ZONESERIAL</c>
        <c>TBD</c>
        <c>[This document]</c>

      </texttable>
    </section>

    <section title="Acknowledgements">
      <t>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.</t>

<!--The idea was first discussed by Shane and Mukund during IETF-94
      where various advantages of using such a scheme were
      discovered. During the same IETF meeting, the scheme was verbally
      described to and discussed with Ray Bellis, Geoff Huston and
      George Michaelson from which the scheme was refined. After the
      IETF meeting, initial drafts of the idea were reviewed by Cathy
      Almond, Mark Andrews, Ray Bellis, Evan Hunt and Witold
      Krecicki. Stephen joined as an author after suggesting changes to
      improve presentation of the ideas and alternate schemes.</t>

      <t>Ray Bellis pointed to a dnsop mailing list thread where a
      similar idea was considered by Bob Harold in reply to discussion
      about <xref target="I-D.yao-dnsop-root-cache" /> on 28 October
      2015.</t>
-->
    </section>

  </middle>

  <back>

    <references title="Normative references">
      <?rfc include="reference.RFC.1035.xml"?>
      <?rfc include="reference.RFC.1982.xml"?>
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.6891.xml"?>
    </references>

    <references title="Informative references">
      <?rfc include="reference.RFC.7871.xml"?>
    </references>

    <section title="Change history (to be removed before publication)">
      <t>
        <list style="symbols">

          <t>
          draft-muks-dnsop-dns-opportunistic-refresh-00
          <vspace/>
          Initial draft.
          </t>

        </list>
      </t>
    </section>

  </back>
</rfc>