One document matched: draft-jabley-dnsop-dns-flush-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc1034 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
  <!ENTITY rfc1035 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
  <!ENTITY rfc1996 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1996.xml'>
  <!ENTITY rfc2119 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc2845 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2845.xml'>
  <!ENTITY rfc4033 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
  <!ENTITY rfc4034 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml'>
  <!ENTITY rfc4035 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml'>
]>

<rfc category="exp" ipr="trust200902"
  docName="draft-jabley-dnsop-dns-flush-00">

  <?rfc toc="no" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>

  <front>
    <title abbrev="DNS FLUSH">A Mechanism for Remote-Triggered DNS
      Cache Flushes (DNS FLUSH)</title>

    <author initials='J.' surname="Abley" fullname='Joe Abley'>
      <organization>ICANN</organization>
      <address>
        <postal>
          <street>12025 Waterfront Drive, Suite 300</street>
          <city>Los Angeles</city>
          <region>CA</region>
          <code>90094-2536</code>
          <country>USA</country>
        </postal>
        <phone>+1 519 670 9327</phone>
        <email>joe.abley@icann.org</email>
      </address>
    </author>

    <author initials="W." surname="Kumari" fullname="Warren Kumarui">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
        </postal>
        <email>warren@kumari.net</email>
      </address>
    </author>

    <date month="June" year="2013"/>

    <abstract>
      <t>DNS NOTIFY is a mechanism for prompt notification of zone
        changes between DNS authority servers that is usually
	employed to trigger immediate zone transfers.</t>

      <t>This document specifies an additional use of DNS NOTIFY
	to allow DNS authority servers to trigger cache flushes on
	recursive DNS servers. Such signalling is authenticated and
	is intended for use between cooperating DNS server
	operators.</t>
    </abstract>
  </front>

  <middle>
    <section title="Terminology">
      <t>This document makes use of the following taxonomy. Note
	that although it is thought that these terms (and the
	meanings presented here) are in common use, overloading and
	ambiguity abounds in practice and hence the definitions
	presented here should not be considered universally-applicable.</t>

      <t>
        <list style="hanging">
	  <t hangText="Authoritative Server:">A DNS server that
	    serves one or more DNS zones authoritatively, and which
	    does not process recursive queries. An Authoritative
	    Server may function as a Master Server, or a Slave
	    Server, or both.</t>

	  <t hangText="Master Server:">An Authoritative Server with
	    the ability to respond to zone transfer requests from
	    one or more Slave Servers and hence replicate zone data
	    from master to slave.</t>

	  <t hangText="Slave Server:">An Authoritative Server
	    configured to replicate zone data from one or more
	    Master Servers.</t>

	  <t hangText="Recursive Server:">A DNS server that processes
	    Recursive Queries on behalf of Stub Resolvers. Recursive
	    Servers ultimately obtain responses from Authoritative
	    Servers, although particular queries from Stub Resolvers
	    may be satisified using data stored in a local cache
	    or obtained from one or more other Recursive Servers.</t>

	  <t hangText="Stub Resolver:">A DNS client that communicates
	    with one or more configured Recursive Servers in order
	    to obtain responses to queries on behalf of an
	    application.</t>
	</list>
      </t>

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

      <t>Notwithstanding the use of this normative language, this
	document describes an experimental mechanism and does not
	seek to define a standard of any kind.</t>
    </section>

    <section title="Introduction">
	<t>The Domain Name System (DNS) is described in <xref
	target="RFC1034"/> and <xref target="RFC1035"/>. Those
	documents describe a means of publishing zone data on
	multiple Authoritative Servers, with the zone data itself
	being replicated from Master Servers to Slave Servers using
	zone transfer. The frequency at which a Slave Server will
	attempt to replicate zone data from a Master Server is
	determined by timers present in the RDATA of each zone's
	SOA record.</t>

      <t>An additional mechanism known as DNS NOTIFY is described
	in <xref target="RFC1996"/>. Authoritative servers that
	support DNS NOTIFY are capable of preemptive zone transfers
	(transfers that are attempted before the SOA timers would
	normally indicate that they are needed); a Master Server
	with a new revision of a zone signals the availability of
	new data by sending a DNS NOTIFY message to a Slave Server,
	providing the opportunity for the Slave Server to initiate
	a zone transfer request from the Master Server and hence
	facilitate rapid propagation of changes to zones.</t>

      <t>DNS Resolvers provide a caching layer between stub resolvers
	and Authoritative Servers. Answers to queries that have
	been previously obtained from Authority Servers will persist
	in a local cache for a time specified by the TTL field
	encoded within individual resource records.</t>

      <t>Although DNS NOTIFY allows rapid propagation of changes
	within zones to the Authority Servers which serve those
	zones, those changes may not be immediately apparent to
	Stub Resolvers; answers cached by Recursive Resolvers will
	continue to be returned to Stub Resolvers until they expire.
	Many implementations of Recursive Servers are capable of
	removing entries from the local cache earlier than they
	would normally expire, but this is generally a manual
	operation used as part of end-user troubleshooting, and
	there is no defined mechanism to allow an Authoritative
	Server to signal to nominated Recursive Servers that
	particular data is stale, and should be flushed early.</t>

      <t>This document defines such a mechanism, using the
        existing DNS NOTIFY facility to allow an Authoritative
        Server to signal a Recursive Server to flush particular
        data from its local cache.</t>

      <t>This document defines no new protocol elements and makes
	no changes to the existing specification for DNS UPDATE.
	Rather, this document specifies that the interpretation of
	a DNS UPDATE received by a Recursive Server, a case not
	considered in <xref target="RFC2119"/>, should be that of
	DNS FLUSH.</t>
    </section>

    <section title="Use Cases">
      <section title="Rapid Recovery from DNSSEC Failures">
        <t>DNS Security Extensions (DNSSEC) are described in
          <xref target="RFC4033"/>, <xref target="RFC4034"/> and
          <xref target="RFC4035"/>. DNSSEC provides a means to
          authenticate responses received from the DNS using
          cryptographic keys and signatures.</t>

	<t>Signatures and keys in DNSSEC are published in-band using
	  resource records, and hence are subject to caching. Zone
	  signing errors such as the publication of signatures from
	  a non-published key have been observed to cause validation
	  failures for end users that persist long after errors
	  have been corrected on the relevant Authoritative
	  Servers.</t>

	<t>The mechanism described in this document could provide
	  a means to avoid those persistent failures for specific
	  relying parties; for example, an ISP could trigger automatic
	  cache flushes for its own signed zones to the Recursive
	  Servers provided for use by its customers, or a TLD
	  operator could do similarly to particularly significant
	  Recursive Servers within particularly prominent communities
	  of users.</t>
      </section>

      <section title="Rapid Recovery from Registry Failures">
        <t>Domain Name Registries maintain information used to
          publish zones that mainly support referrals for children.
          Examples of such zones are ORG, COM, NET, CO.UK and CA.
          In many cases interaction with Registries is mediated
          by Registrars who provide an interface for end-users
          (Registrants) to effect changes.</t>

        <t>A failure in the Registry/Registrar system which resulted
          in incorrect information being published in the parent
          zone has the potential to impact operations of many child
          zones. Such failures might be caused by a zone publication
          error (e.g. zone truncation due to a systems error) or
          a database failure at a Registrar or in the Registry.</t>

        <t>Recovery from such failures is automatic given sufficient
          time. However, the mechanism described in this document
          facilitates a more rapid recovery, without having to wait
          for undesirable negative or positive answers in Recursive
          Servers to expire from their caches.</t>
      </section>
    </section>

    <section title="DNS FLUSH">
      <section title="Authoritative Server Behaviour">
	<t>An Authoritative Server that supports DNS NOTIFY will
	  normally send DNS NOTIFY messages to a set of Authoritative
	  Servers each time the contents of a zone changes, as
	  indicated by an increased SOA serial, as specified in
	  <xref target="RFC1996"/>.</t>

	<t>An Authoritative Server that supports DNS FLUSH MAY send
	  DNS NOTIFY messages to a set of Recursive Servers each
	  time the contents of a zone change. The use of DNS NOTIFY
	  for DNS FLUSH is specified to be exactly the same as if
	  the DNS NOTIFY message was being sent to an Authoritative
	  Server; the only difference is the intent of the
	  communication, to trigger a remote cache flush rather
	  than a zone transfer.</t>
      </section>

      <section title="Recursive Server Behaviour">
	<t>A Recursive Server that supports DNS FLUSH will receive
	  and respond to DNS NOTIFY messages exactly as specified
	  in <xref target="RFC1996"/>.</t>

	<t>Following reception of a DNS NOTIFY message from an
	  Authoritative Server, a Recursive Server SHOULD take
	  appropriate action according to local policy.</t>

	<t>For example, a Recursive Server MAY flush data from its
	  local cache that is known to originate in the zone indicated
	  by the QNAME in the received DNS NOTIFY. A Recursive
	  Server under high load might instead do nothing, however,
	  due to a local policy decision.</t>
      </section>

      <section title="Authentication" anchor="authentication">
	<t>All DNS NOTIFY transactions MUST be authenticated, using
	  <xref target="RFC2845">TSIG</xref> or some equivalent
	  mechanism.  Use of TSIG implies a deliberate, bilateral
	  agreement between the operators of specific Authoritative
	  Servers and Recursive Servers.</t>

	<t>Recursive Servers that receive non-authenticated DNS NOTIFY
          messages (or messages whose authenticity cannot be conrirmed)
          MUST NOT take any action to avoid the threat of malicious
          third parties triggering cache flushes, which might elevate
          network resource consumption on the Recursive Server and
          decrease performance for Stub Resolvers.</t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>This document makes no request of the IANA.</t>
    </section>

    <section title="Security Considerations">
      <t>DNS FLUSH uses <xref target="RFC1996">DNS NOTIFY</xref>,
	and the security considerations of DNS NOTIFY hence apply
	equally to DNS FLUSH.</t>

      <t>As described in <xref target="authentication"/>, DNS UPDATE
        messages received by Recursive Servers MUST be authenticated.
        All non-authenticated messages MUST NOT result in action by
        the Recursive Server.</t>
    </section>

    <section title="Acknowledgements">
      <t>Your name here, etc.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc1034;
      &rfc1035;
      &rfc1996;
      &rfc2119;
      &rfc2845;
    </references>

    <references title="Informative References">
      &rfc4033;
      &rfc4034;
      &rfc4035;
    </references>

    <section title="Editorial Notes">
      <t>This section (and sub-sections) to be removed prior to
        publication.</t>

      <section title="Change History">
        <t>
          <list style="hanging">
            <t hangText="00">Initial idea, circulated for the purposes of
              entertainment.</t>
          </list>
        </t>
      </section>
    </section>
  </back>
</rfc>