Serving Stale Data to Improve DNS Resiliency
RFC 8767
Document | Type | RFC - Proposed Standard (March 2020; No errata) | |
---|---|---|---|
Authors | David Lawrence , Warren Kumari , Puneet Sood | ||
Last updated | 2020-03-31 | ||
Replaces | draft-tale-dnsop-serve-stale | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Suzanne Woolf | ||
Shepherd write-up | Show (last changed 2019-08-27) | ||
IESG | IESG state | RFC 8767 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Barry Leiba | ||
Send notices to | Suzanne Woolf <suzworldwide@gmail.com> | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | In Progress |
Internet Engineering Task Force (IETF) D. Lawrence Request for Comments: 8767 Oracle Updates: 1034, 1035, 2181 W. Kumari Category: Standards Track P. Sood ISSN: 2070-1721 Google March 2020 Serving Stale Data to Improve DNS Resiliency Abstract This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8767. Copyright Notice Copyright (c) 2020 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 (https://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. Table of Contents 1. Introduction 2. Terminology 3. Background 4. Standards Action 5. Example Method 6. Implementation Considerations 7. Implementation Caveats 8. Implementation Status 9. EDNS Option 10. Security Considerations 11. Privacy Considerations 12. NAT Considerations 13. IANA Considerations 14. References 14.1. Normative References 14.2. Informative References Acknowledgements Authors' Addresses 1. Introduction Traditionally, the Time To Live (TTL) of a DNS Resource Record (RR) has been understood to represent the maximum number of seconds that a record can be used before it must be discarded, based on its description and usage in [RFC1035] and clarifications in [RFC2181]. This document expands the definition of the TTL to explicitly allow for expired data to be used in the exceptional circumstance that a recursive resolver is unable to refresh the information. It is predicated on the observation that authoritative answer unavailability can cause outages even when the underlying data those servers would return is typically unchanged. We describe a method below for this use of stale data, balancing the competing needs of resiliency and freshness. This document updates the definitions of TTL from [RFC1034] and [RFC1035] so that data can be kept in the cache beyond the TTL expiry; it also updates [RFC2181] by interpreting values with the high-order bit set as being positive, rather than 0, and also suggests a cap of 7 days. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. For a glossary of DNS terms, please see [RFC8499]. 3. Background There are a number of reasons why an authoritative server may become unreachable, including Denial-of-Service (DoS) attacks, network issues, and so on. If a recursive server is unable to contact the authoritative servers for a query but still has relevant data that has aged past its TTL, that information can still be useful for generating an answer under the metaphorical assumption that "stale bread is better than no bread." [RFC1035], Section 3.2.1 says that the TTL "specifies the time interval that the resource record may be cached before the source of the information should again be consulted." [RFC1035], Section 4.1.3Show full document text