Internet DRAFT - draft-jabley-dnsop-dns-flush

draft-jabley-dnsop-dns-flush






Network Working Group                                           J. Abley
Internet-Draft                                                     ICANN
Intended status: Experimental                                  W. Kumari
Expires: December 26, 2013                                        Google
                                                           June 24, 2013


     A Mechanism for Remote-Triggered DNS Cache Flushes (DNS FLUSH)
                    draft-jabley-dnsop-dns-flush-00

Abstract

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

   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.

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 26, 2013.

Copyright Notice

   Copyright (c) 2013 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



Abley & Kumari          Expires December 26, 2013               [Page 1]

Internet-Draft                  DNS FLUSH                      June 2013


   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.















































Abley & Kumari          Expires December 26, 2013               [Page 2]

Internet-Draft                  DNS FLUSH                      June 2013


1.  Terminology

   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.

   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.

   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.

   Slave Server:  An Authoritative Server configured to replicate zone
      data from one or more Master Servers.

   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.

   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.

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

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














Abley & Kumari          Expires December 26, 2013               [Page 3]

Internet-Draft                  DNS FLUSH                      June 2013


2.  Introduction

   The Domain Name System (DNS) is described in [RFC1034] and [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.

   An additional mechanism known as DNS NOTIFY is described in
   [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.

   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.

   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.

   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.

   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 [RFC2119], should be that
   of DNS FLUSH.




Abley & Kumari          Expires December 26, 2013               [Page 4]

Internet-Draft                  DNS FLUSH                      June 2013


3.  Use Cases

3.1.  Rapid Recovery from DNSSEC Failures

   DNS Security Extensions (DNSSEC) are described in [RFC4033],
   [RFC4034] and [RFC4035].  DNSSEC provides a means to authenticate
   responses received from the DNS using cryptographic keys and
   signatures.

   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.

   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.

3.2.  Rapid Recovery from Registry Failures

   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.

   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.

   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.








Abley & Kumari          Expires December 26, 2013               [Page 5]

Internet-Draft                  DNS FLUSH                      June 2013


4.  DNS FLUSH

4.1.  Authoritative Server Behaviour

   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 [RFC1996].

   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.

4.2.  Recursive Server Behaviour

   A Recursive Server that supports DNS FLUSH will receive and respond
   to DNS NOTIFY messages exactly as specified in [RFC1996].

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

   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.

4.3.  Authentication

   All DNS NOTIFY transactions MUST be authenticated, using TSIG
   [RFC2845] or some equivalent mechanism.  Use of TSIG implies a
   deliberate, bilateral agreement between the operators of specific
   Authoritative Servers and Recursive Servers.

   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.








Abley & Kumari          Expires December 26, 2013               [Page 6]

Internet-Draft                  DNS FLUSH                      June 2013


5.  IANA Considerations

   This document makes no request of the IANA.
















































Abley & Kumari          Expires December 26, 2013               [Page 7]

Internet-Draft                  DNS FLUSH                      June 2013


6.  Security Considerations

   DNS FLUSH uses DNS NOTIFY [RFC1996], and the security considerations
   of DNS NOTIFY hence apply equally to DNS FLUSH.

   As described in Section 4.3, DNS UPDATE messages received by
   Recursive Servers MUST be authenticated.  All non-authenticated
   messages MUST NOT result in action by the Recursive Server.











































Abley & Kumari          Expires December 26, 2013               [Page 8]

Internet-Draft                  DNS FLUSH                      June 2013


7.  Acknowledgements

   Your name here, etc.
















































Abley & Kumari          Expires December 26, 2013               [Page 9]

Internet-Draft                  DNS FLUSH                      June 2013


8.  References

8.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

8.2.  Informative References

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.


















Abley & Kumari          Expires December 26, 2013              [Page 10]

Internet-Draft                  DNS FLUSH                      June 2013


Appendix A.  Editorial Notes

   This section (and sub-sections) to be removed prior to publication.

A.1.  Change History

   00 Initial idea, circulated for the purposes of entertainment.












































Abley & Kumari          Expires December 26, 2013              [Page 11]

Internet-Draft                  DNS FLUSH                      June 2013


Authors' Addresses

   Joe Abley
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA  90094-2536
   USA

   Phone: +1 519 670 9327
   Email: joe.abley@icann.org


   Warren Kumarui
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043

   Email: warren@kumari.net

































Abley & Kumari          Expires December 26, 2013              [Page 12]