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]