< draft-ietf-dnsop-serve-stale-06.txt   draft-ietf-dnsop-serve-stale-07.txt >
DNSOP Working Group D. Lawrence DNSOP Working Group D. Lawrence
Internet-Draft Oracle Internet-Draft Oracle
Updates: 1034, 1035 (if approved) W. Kumari Updates: 1034, 1035, 2181 (if approved) W. Kumari
Intended status: Standards Track P. Sood Intended status: Standards Track P. Sood
Expires: February 9, 2020 Google Expires: March 2, 2020 Google
August 08, 2019 August 30, 2019
Serving Stale Data to Improve DNS Resiliency Serving Stale Data to Improve DNS Resiliency
draft-ietf-dnsop-serve-stale-06 draft-ietf-dnsop-serve-stale-07
Abstract Abstract
This draft defines a method (serve-stale) for recursive resolvers to This draft defines a method (serve-stale) for recursive resolvers to
use stale DNS data to avoid outages when authoritative nameservers use stale DNS data to avoid outages when authoritative nameservers
cannot be reached to refresh expired data. It updates the definition cannot be reached to refresh expired data. One of the motivations
of TTL from [RFC1034], [RFC1035], and [RFC2181] to make it clear that for serve-stale is to make the DNS more resilient to DoS attacks, and
data can be kept in the cache beyond the TTL expiry and used for thereby make them less attractive as an attack vector. This document
responses when a refreshed answer is not readily available. One of updates the definitions of TTL from RFC 1034 and RFC 1035 so that
the motivations for serve-stale is to make the DNS more resilient to data can be kept in the cache beyond the TTL expiry, and also updates
DoS attacks, and thereby make them less attractive as an attack RFC 2181 by interpreting values with the high order bit set as being
vector. positive, rather than 0, and also suggests a cap of 7 days.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 9, 2020. This Internet-Draft will expire on March 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 2, line 49
This document proposes that the definition of the TTL be explicitly This document proposes that the definition of the TTL be explicitly
expanded to allow for expired data to be used in the exceptional expanded to allow for expired data to be used in the exceptional
circumstance that a recursive resolver is unable to refresh the circumstance that a recursive resolver is unable to refresh the
information. It is predicated on the observation that authoritative information. It is predicated on the observation that authoritative
answer unavailability can cause outages even when the underlying data answer unavailability can cause outages even when the underlying data
those servers would return is typically unchanged. those servers would return is typically unchanged.
We describe a method below for this use of stale data, balancing the We describe a method below for this use of stale data, balancing the
competing needs of resiliency and freshness. 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, and 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 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
For a comprehensive treatment of DNS terms, please see [RFC7719]. For a comprehensive treatment of DNS terms, please see [RFC8499].
3. Background 3. Background
There are a number of reasons why an authoritative server may become There are a number of reasons why an authoritative server may become
unreachable, including Denial of Service (DoS) attacks, network unreachable, including Denial of Service (DoS) attacks, network
issues, and so on. If a recursive server is unable to contact the issues, and so on. If a recursive server is unable to contact the
authoritative servers for a query but still has relevant data that authoritative servers for a query but still has relevant data that
has aged past its TTL, that information can still be useful for has aged past its TTL, that information can still be useful for
generating an answer under the metaphorical assumption that "stale generating an answer under the metaphorical assumption that "stale
bread is better than no bread." bread is better than no bread."
skipping to change at page 12, line 9 skipping to change at page 12, line 16
Moura, G., Heidemann, J., Mueller, M., Schmidt, R., and M. Moura, G., Heidemann, J., Mueller, M., Schmidt, R., and M.
Davids, "When the Dike Breaks: Dissecting DNS Defenses Davids, "When the Dike Breaks: Dissecting DNS Defenses
During DDos", ACM 2018 Internet Measurement Conference, During DDos", ACM 2018 Internet Measurement Conference,
DOI 10.1145/3278532.3278534, October 2018, DOI 10.1145/3278532.3278534, October 2018,
<https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf>. <https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>. <https://www.rfc-editor.org/info/rfc6672>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
2015, <https://www.rfc-editor.org/info/rfc7719>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Authors' Addresses Authors' Addresses
David C Lawrence David C Lawrence
Oracle Oracle
Email: tale@dd.org Email: tale@dd.org
Warren "Ace" Kumari Warren "Ace" Kumari
Google Google
 End of changes. 8 change blocks. 
16 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/