< draft-ietf-dnsop-serve-stale-00.txt   draft-ietf-dnsop-serve-stale-01.txt >
DNSOP Working Group D. Lawrence DNSOP Working Group D. Lawrence
Internet-Draft Akamai Technologies Internet-Draft Akamai Technologies
Updates: 1034, 1035 (if approved) W. Kumari Updates: 1034, 1035 (if approved) W. Kumari
Intended status: Standards Track Google Intended status: Standards Track P. Sood
Expires: May 3, 2018 October 30, 2017 Expires: April 1, 2019 Google
September 28, 2018
Serving Stale Data to Improve DNS Resiliency Serving Stale Data to Improve DNS Resiliency
draft-ietf-dnsop-serve-stale-00 draft-ietf-dnsop-serve-stale-01
Abstract Abstract
This draft defines a method for recursive resolvers to use stale DNS This draft defines a method for recursive resolvers to use stale DNS
data to avoid outages when authoritative nameservers cannot be data to avoid outages when authoritative nameservers cannot be
reached to refresh expired data. reached to refresh expired data.
Ed note Ed note
Text inside square brackets ([]) is additional background Text inside square brackets ([]) is additional background
skipping to change at page 1, line 43 skipping to change at page 1, line 44
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 May 3, 2018. This Internet-Draft will expire on April 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 27 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Standards Action . . . . . . . . . . . . . . . . . . . . . . 4 4. Standards Action . . . . . . . . . . . . . . . . . . . . . . 4
5. EDNS Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. EDNS Option . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Option Usage . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Option Usage . . . . . . . . . . . . . . . . . . . . . . 5
6. Example Method . . . . . . . . . . . . . . . . . . . . . . . 6 6. Example Method . . . . . . . . . . . . . . . . . . . . . . . 6
7. Implementation Caveats . . . . . . . . . . . . . . . . . . . 7 7. Implementation Caveats . . . . . . . . . . . . . . . . . . . 7
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . 9
14.2. Informative References . . . . . . . . . . . . . . . . . 9 14.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Traditionally the Time To Live (TTL) of a DNS resource record has Traditionally the Time To Live (TTL) of a DNS resource record has
been understood to represent the maximum number of seconds that a been understood to represent the maximum number of seconds that a
record can be used before it must be discarded, based on its record can be used before it must be discarded, based on its
description and usage in [RFC1035] and clarifications in [RFC2181]. description and usage in [RFC1035] and clarifications in [RFC2181].
This document proposes that the definition of the TTL be explicitly This document proposes that the definition of the TTL be explicitly
skipping to change at page 5, line 44 skipping to change at page 6, line 12
INDEX values overriding the default. A TTL-EXPIRY value of 0 means INDEX values overriding the default. A TTL-EXPIRY value of 0 means
to never serve the RRset as stale, while non-zero values represent to never serve the RRset as stale, while non-zero values represent
the maximum amount of time it can be used before it MUST be evicted. the maximum amount of time it can be used before it MUST be evicted.
[ Does anyone really want to do this? It adds more state into [ Does anyone really want to do this? It adds more state into
resolvers. Is the idea only for purists, or is there a practical resolvers. Is the idea only for purists, or is there a practical
application? ] application? ]
No facility is made for a client of a resolver to signal that it No facility is made for a client of a resolver to signal that it
doesn't want stale answers, because if a client has knowledge of doesn't want stale answers, because if a client has knowledge of
Serve-Stale as an option, it also has enough knowledge to just ignore Serve-Stale as an option, it also has enough knowledge to just ignore
any records that come back stale. [ There is admittedly the issue any records that come back stale. [ There is admittedly the issue
that the client might just want to wait out the whole attempted that the client might just want to wait out the whole attempted
resolution, which there's currently no way to indicate. The absolute resolution, which there's currently no way to indicate. The absolute
value of STALE-RRSET-INDEX could be taken as a timer the requester is value of STALE-RRSET-INDEX could be taken as a timer the requester is
willing to wait for an answer, but that's kind of gross overloading willing to wait for an answer, but that's kind of gross overloading
it like that Shame to burn another field on that though, but on the it like that Shame to burn another field on that though, but on the
other hand it would be nice if a client could always signal its other hand it would be nice if a client could always signal its
impatience level - "I must have an answer within 900 milliseconds!" ] impatience level - "I must have an answer within 900 milliseconds!" ]
6. Example Method 6. Example Method
skipping to change at page 6, line 47 skipping to change at page 7, line 15
If iterative lookups will be done, it SHOULD start the query If iterative lookups will be done, it SHOULD start the query
resolution timer. This timer bounds the work done by the resolver, resolution timer. This timer bounds the work done by the resolver,
and is commonly around 10 to 30 seconds. and is commonly around 10 to 30 seconds.
If the answer has not been completely determined by the time the If the answer has not been completely determined by the time the
client response timer has elapsed, the resolver SHOULD then check its client response timer has elapsed, the resolver SHOULD then check its
cache to see whether there is expired data that would satisfy the cache to see whether there is expired data that would satisfy the
request. If so, it adds that data to the response message and SHOULD request. If so, it adds that data to the response message and SHOULD
set the TTL of each expired record in the message to 1 second. The set the TTL of each expired record in the message to 1 second. The
response is then sent to the client while the resolver continues its response is then sent to the client while the resolver continues its
attempt to refresh the data. 1 second was chosen because attempt to refresh the data. 1 second was chosen because historically
historically 0 second TTLs have been problematic for some 0 second TTLs have been problematic for some implementations. It not
implementations. It not only sidesteps those potential problems with only sidesteps those potential problems with no practical negative
no practical negative consequence, it would also rate limit further consequence, it would also rate limit further queries from any client
queries from any client that is honoring the TTL, such as a that is honoring the TTL, such as a forwarding resolver.
forwarding resolver.
The maximum stale timer is used for cache management and is The maximum stale timer is used for cache management and is
independent of the query resolution process. This timer is independent of the query resolution process. This timer is
conceptually different from the maximum cache TTL that exists in many conceptually different from the maximum cache TTL that exists in many
resolvers, the latter being a clamp on the value of TTLs as received resolvers, the latter being a clamp on the value of TTLs as received
from authoritative servers. The maximum stale timer SHOULD be from authoritative servers. The maximum stale timer SHOULD be
configurable, and defines the length of time after a record expires configurable, and defines the length of time after a record expires
that it SHOULD be retained in the cache. The suggested value is 7 that it SHOULD be retained in the cache. The suggested value is 7
days, which gives time to notice the resolution problem and for human days, which gives time to notice the resolution problem and for human
intervention to fix it. intervention to fix it.
skipping to change at line 448 skipping to change at page 10, line 37
Email: tale@akamai.com Email: tale@akamai.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View CA 94043 Mountain View CA 94043
USA USA
Email: warren@kumari.net Email: warren@kumari.net
Puneet Sood
Google
Email: puneets@google.com
 End of changes. 9 change blocks. 
14 lines changed or deleted 14 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/