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]