| Network Working Group | J. Abley |
| Internet-Draft | ICANN |
| Intended status: Experimental | W. Kumari |
| Expires: December 26, 2013 | |
| June 24, 2013 |
A Mechanism for Remote-Triggered DNS Cache Flushes (DNS FLUSH)
draft-jabley-dnsop-dns-flush-00
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.
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 (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 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.
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.
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.
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.
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.
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.
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.
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.
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.
This document makes no request of the IANA.
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.
Your name here, etc.
| [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. |
| [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. |
This section (and sub-sections) to be removed prior to publication.