Serving Stale Data to Improve DNS Resiliency
RFC 8767

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10



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.3