Serving Stale Data to Improve DNS Resiliency
draft-ietf-dnsop-serve-stale-08

Document Type Active Internet-Draft (dnsop WG)
Last updated 2019-09-18
Replaces draft-tale-dnsop-serve-stale
Stream IETF
Intended RFC status Proposed Standard
Formats plain text pdf 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 In Last Call (ends 2019-09-25)
Consensus Boilerplate Yes
Telechat date
Responsible AD Barry Leiba
Send notices to Suzanne Woolf <suzworldwide@gmail.com>
IANA IANA review state IANA - Review Needed
DNSOP Working Group                                          D. Lawrence
Internet-Draft                                                    Oracle
Updates: 1034, 1035, 2181 (if approved)                        W. Kumari
Intended status: Standards Track                                 P. Sood
Expires: March 21, 2020                                           Google
                                                      September 18, 2019

              Serving Stale Data to Improve DNS Resiliency
                    draft-ietf-dnsop-serve-stale-08

Abstract

   This draft 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 RFC 1034 and RFC 1035 so that
   data can be kept in the cache beyond the TTL expiry, 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 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 March 21, 2020.

Copyright Notice

   Copyright (c) 2019 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

Lawrence, et al.         Expires March 21, 2020                 [Page 1]
Internet-Draft               DNS Serve Stale              September 2019

   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Standards Action  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Example Method  . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Implementation Considerations . . . . . . . . . . . . . . . .   6
   7.  Implementation Caveats  . . . . . . . . . . . . . . . . . . .   8
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
   9.  EDNS Option . . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
   12. NAT Considerations  . . . . . . . . . . . . . . . . . . . . .  11
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     15.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Traditionally the Time To Live (TTL) of a DNS resource record 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
Show full document text