Skip to main content

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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, dnsop-chairs@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org, dnsop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf <suzworldwide@gmail.com>, barryleiba@gmail.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Serving Stale Data to Improve DNS Resiliency' to Proposed Standard (draft-ietf-dnsop-serve-stale-10.txt)

The IESG has approved the following document:
- 'Serving Stale Data to Improve DNS Resiliency'
  (draft-ietf-dnsop-serve-stale-10.txt) as Proposed Standard

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Warren Kumari, Ignas Bagdonas and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/


Ballot Text

Technical Summary

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.  It updates the definition
of TTL from RFCs 1034, 1035, and 2181 to make it clear that
data can be kept in the cache beyond the TTL expiry and used for
responses when a refreshed answer is not readily available.

Working Group Summary

This draft dates to March 2017 and was adopted by DNSOP in October 2017.
It's been extensively reviewed in the WG. The primary point of
controversy was that it discusses an optional protocol change (the choice
by a recursive resolver to re-use data beyond the authoritative server
TTL when no refresh is available) that some WG participants felt to be
unwise under some conditions. The discussion of timer values in Sec. 5,
and of implementation decisions and caveats in Sec. 6 and Sec. 7, seem to
address these concerns. Since this protocol modification is widely
implemented and deployed, having a standards track description seemed to
promote careful practice and interoperability.

Document Quality

The protocol update discussed in this draft is an attempt to document
behavior that is implemented in multiple open source DNS codebases and
deployed by a number of large operators, including DNS services and CDNs
that rely on the specified DNS behavior. Common practice regarding the
handling of TTLs by recursive resolvers has changed considerably over the
behavior originally specified, and documenting the current practice as an
update to the protocol seems likely to promote interoperability and
transparency under both normal and adverse conditions.

Personnel
Suzanne Woolf (shepherd)
Barry Leiba (AD)

RFC Editor Note