Internet DRAFT - draft-jabley-dnsop-flush-reqs
draft-jabley-dnsop-flush-reqs
Network Working Group J. Abley
Internet-Draft Dyn, Inc.
Intended status: Experimental W. Kumari
Expires: April 21, 2014 Google
October 18, 2013
Requirements for a Mechanism for Remote-Triggered DNS Cache Flushes
draft-jabley-dnsop-flush-reqs-00
Abstract
Operational calamaties in the DNS happen from time to time, and in
many cases problems persist due to DNS caching of bad data. Lacking
any robust mechanism to signal that bad data has been flushed, the
operators of DNS authority servers often resort to unauthenticated
requests for help being sent to mailing lists, the results of which
are frequently unsatisfying to all concerned.
This document aims to present requirements for a more robust
mechanism by which authoritative server operators can signal to
recursive server operators that bad data has been published, and that
targetted cache flushes may be beneficial.
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 April 21, 2014.
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
Abley & Kumari Expires April 21, 2014 [Page 1]
Internet-Draft DNS FLUSH Requirements October 2013
(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.
Abley & Kumari Expires April 21, 2014 [Page 2]
Internet-Draft DNS FLUSH Requirements October 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 satisfied 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].
Abley & Kumari Expires April 21, 2014 [Page 3]
Internet-Draft DNS FLUSH Requirements October 2013
2. Introduction
Operational calamaties in the DNS happen from time to time, and in
many cases problems persist due to DNS caching of bad data. Lacking
any robust mechanism to signal that bad data has been flushed, the
operators of DNS authority servers often resort to unauthenticated
requests for help being sent to mailing lists, the results of which
are frequently unsatisfying to all concerned.
This document aims to present requirements for a more robust
mechanism by which authoritative server operators can signal to
recursive server operators that bad data has been published, and that
targetted cache flushes may be beneficial.
Abley & Kumari Expires April 21, 2014 [Page 4]
Internet-Draft DNS FLUSH Requirements October 2013
3. Use Cases
The following are examples of failures that have been observed to
cause service disruption, and that a mechanism meeting the
requirements that follow might provide some relief from.
This is all woefully incomplete. Specific examples of domain names
(TLD and otherwise) have been omitted in the interests of avoiding
undue embarassment.
3.1. Registrar Compromise, Domain Hijack
Unauthorised access to a registrant's account at a registrar (or some
other registrar-level compromise) facilitates the unauthorised
redelegation of a domain to new nameservers, which serve malicious
data with long TTLs.
Remediation is achieved by restoring the correct delegation. Service
disruption continues until the malicious data has expired from
Recursive Server caches used by end-users.
3.2. Zone Signing Failure
A failure to sign a zone correctly (e.g. using the wrong keys)
results in correct zone data being published with signatures that
cannot be validated.
Remediation is achieved by fixing the signing problem (e.g. signing
with the correct keys) and publishing a new revision of the zone.
Service disruption may continue until particular elements have
expired from caches (e.g. apex DNSKEY RRSets).
3.3. Zone Integrity Failure
Publication of an incomplete (e.g. truncated) zone results in missing
data, and the absence of that data is subject to negative caching
[RFC2308].
Remediation is achieved by resolving the operational problem that led
to the incomplete zone being published, and publishing a successor
zone that is complete. Service disruption may continue until all
negatively-cached elements have expired from caches.
Abley & Kumari Expires April 21, 2014 [Page 5]
Internet-Draft DNS FLUSH Requirements October 2013
4. Requirements
[These various requirements are somewhat arbitrarily spread over the
subsections that follow. Some better organisation would make them
more readable.]
4.1. Functional Requirements
1. The mechanism MUST be effective; that is, it must be capable of
being deployed to the extent that it provides a significant
improvement in remediation of zone publication problems.
2. The mechanism MUST accommodate a maximally-constrained scope for
a flush; that is, the resulting cache flushes MUST be constrained
to specific parts of the namespace where a flush is beneficial to
resolve a problem, and MUST minimise collateral damage to other
cached data.
3. The mechanism MUST be opt-in from the perspective of a Recursive
Server operator; that is, no Recursive Server operator should be
compelled to act upon a request to flush their cache.
4. The mechanism MUST accommodate timely responses to problems.
5. The mechanism MUST support idempotency; that is, transmission of
multiple identical requests to flush MUST NOT result in more than
one flush operation in a single cache.
6. The mechanism SHOULD require minimal changes to DNS software, but
MIGHT reasonably involve changes to or deployment of surrounding
administrative scaffolding (scripts, etc).
4.2. Operational Requirements
1. It SHOULD be possible to automate the reception and processing of
a request using the mechanism on a Recursive Server.
2. The mechanism SHOULD be simple for Recursive Server operators to
implement and operate, since those operators might be the
recipient of many requests whereas the operators of Authoritative
Servers should only reasonably expect to exercise this mechanism
in the event of serious operational failures.
4.3. Manageability Requirements
1. The mechanism's effectiveness SHOULD be easily measurable;
Authoritative Server operators using the mechanism ought to be
able to gauge its effect, and Recursive Server operators ought to
Abley & Kumari Expires April 21, 2014 [Page 6]
Internet-Draft DNS FLUSH Requirements October 2013
be able to tell whether problem data was present (i.e. whether
the remedy actually corresponded to a problem).
4.4. Security Requirements
1. The mechanism MUST be authenticated, such that a Recursive Server
operator can trust that a request to flush is authentic.
2. It MUST be possible to rate-limit reception of cache flush
requests in order to avoid the mechanism being used as a denial-
of-service attack vector.
3. The mechanism MUST NOT facilitate new exploits or compromises
against Authoritative Servers or Recursive Servers.
Abley & Kumari Expires April 21, 2014 [Page 7]
Internet-Draft DNS FLUSH Requirements October 2013
5. IANA Considerations
This document makes no request of the IANA.
Abley & Kumari Expires April 21, 2014 [Page 8]
Internet-Draft DNS FLUSH Requirements October 2013
6. Security Considerations
This document presents requirements for future work, and does not
directly impact the security of the Internet.
Security requirements are described in Section 4.4.
Abley & Kumari Expires April 21, 2014 [Page 9]
Internet-Draft DNS FLUSH Requirements October 2013
7. Acknowledgements
Your name here, etc.
Abley & Kumari Expires April 21, 2014 [Page 10]
Internet-Draft DNS FLUSH Requirements October 2013
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
Abley & Kumari Expires April 21, 2014 [Page 11]
Internet-Draft DNS FLUSH Requirements October 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 April 21, 2014 [Page 12]
Internet-Draft DNS FLUSH Requirements October 2013
Authors' Addresses
Joe Abley
Dyn, Inc.
470 Moore Street
London, ON N6C 2C2
Canada
Phone: +1 519 670 9327
Email: jabley@dyn.com
Warren Kumarui
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
Email: warren@kumari.net
Abley & Kumari Expires April 21, 2014 [Page 13]
