idnits 2.17.00 (12 Aug 2021) /tmp/idnits19075/draft-ietf-dnsop-serve-stale-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2018) is 1330 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group D. Lawrence 3 Internet-Draft Akamai Technologies 4 Updates: 1034, 1035 (if approved) W. Kumari 5 Intended status: Standards Track P. Sood 6 Expires: April 1, 2019 Google 7 September 28, 2018 9 Serving Stale Data to Improve DNS Resiliency 10 draft-ietf-dnsop-serve-stale-01 12 Abstract 14 This draft defines a method for recursive resolvers to use stale DNS 15 data to avoid outages when authoritative nameservers cannot be 16 reached to refresh expired data. 18 Ed note 20 Text inside square brackets ([]) is additional background 21 information, answers to frequently asked questions, general musings, 22 etc. They will be removed before publication. This document is 23 being collaborated on in GitHub at . The most recent version of the document, open issues, etc 25 should all be available here. The authors gratefully accept pull 26 requests. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 1, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Standards Action . . . . . . . . . . . . . . . . . . . . . . 4 66 5. EDNS Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 68 5.2. Option Usage . . . . . . . . . . . . . . . . . . . . . . 5 69 6. Example Method . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Implementation Caveats . . . . . . . . . . . . . . . . . . . 7 71 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 74 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 14.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 14.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 Traditionally the Time To Live (TTL) of a DNS resource record has 85 been understood to represent the maximum number of seconds that a 86 record can be used before it must be discarded, based on its 87 description and usage in [RFC1035] and clarifications in [RFC2181]. 89 This document proposes that the definition of the TTL be explicitly 90 expanded to allow for expired data to be used in the exceptional 91 circumstance that a recursive resolver is unable to refresh the 92 information. It is predicated on the observation that authoritative 93 server unavailability can cause outages even when the underlying data 94 those servers would return is typically unchanged. 96 A method is described for this use of stale data, balancing the 97 competing needs of resiliency and freshness. While this intended to 98 be immediately useful to the installed base of DNS software, an 99 [RFC6891] EDNS option is also proposed for enhanced signalling around 100 the use of stale data by implementations that understand it. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 [RFC2119] when, and only when, they appear in all capitals, as shown 108 here. 110 For a comprehensive treatment of DNS terms, please see [RFC7719]. 112 3. Background 114 There are a number of reasons why an authoritative server may become 115 unreachable, including Denial of Service (DoS) attacks, network 116 issues, and so on. If the recursive server is unable to contact the 117 authoritative servers for a name but still has relevant data that has 118 aged past its TTL, that information can still be useful for 119 generating an answer under the metaphorical assumption that, "stale 120 bread is better than no bread." 122 [RFC1035] Section 3.2.1 says that the TTL "specifies the time 123 interval that the resource record may be cached before the source of 124 the information should again be consulted", and Section 4.1.3 further 125 says the TTL, "specifies the time interval (in seconds) that the 126 resource record may be cached before it should be discarded." 128 A natural English interpretation of these remarks would seem to be 129 clear enough that records past their TTL expiration must not be used, 130 However, [RFC1035] predates the more rigorous terminology of 131 [RFC2119] which softened the interpretation of "may" and "should". 133 [RFC2181] aimed to provide "the precise definition of the Time to 134 Live" but in Section 8 was mostly concerned with the numeric range of 135 values and the possibility that very large values should be capped. 136 (It also has the curious suggestion that a value in the range 137 2147483648 to 4294967295 should be treated as zero.) It closes that 138 section by noting, "The TTL specifies a maximum time to live, not a 139 mandatory time to live." This is again not [RFC2119]-normative 140 language, but does convey the natural language connotation that data 141 becomes unusable past TTL expiry. 143 Several major recursive resolver operations currently use stale data 144 for answers in some way, including Akamai, OpenDNS, Xerocole, and 145 Nominum. Their collective operational experience is that it provides 146 significant benefit with minimal downside. 148 4. Standards Action 150 The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is 151 amended to read: 153 TTL a 32 bit unsigned integer number of seconds in the range 0 - 154 2147483647 that specifies the time interval that the resource 155 record MAY be cached before the source of the information MUST 156 again be consulted. Zero values are interpreted to mean that the 157 RR can only be used for the transaction in progress, and should 158 not be cached. Values with the high order bit set SHOULD be 159 capped at no more than 2147483647. If the authority for the data 160 is unavailable when attempting to refresh the data past the given 161 interval, the record MAY be used as though it has a remaining TTL 162 of 1 second. 164 5. EDNS Option 166 While the basic behaviour of this answer-of-last-resort can be 167 achieved with changes only to resolvers, explicit signalling about 168 the use of stale data can be done with an EDNS [RFC6891] option. 170 [ This section will be fleshed out a bit more thoroughly if there is 171 interest in pursuing the option. ] 173 5.1. Option Format 175 The option is structured as follows: 177 +0 (MSB) +1 (LSB) 178 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 179 0: | OPTION-CODE | 180 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 181 2: | OPTION-LENGTH | 182 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 183 4: | STALE-RRSET-INDEX 1 | 184 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 185 6: | | 186 8: | TTL-EXPIRY 1 | 187 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 188 : ... additional STALE-RRSET-INDEX / TTL-EXPIRY pairs ... : 189 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 191 OPTION-CODE 2 octets per [RFC6891]. For Serve-Stale the code is TBD 192 by IANA. 194 OPTION-LENGTH: 2 octets per [RFC6891]. Contains the length of the 195 payload following OPTION-LENGTH, in octets. 197 STALE-RRSET-INDEX Two octets as a signed integer, indicating the 198 first RRSet in the message which is beyond its TTL, with RRSet 199 counting starting at 1 and spanning message sections. 201 TTL-EXPIRY Four octets as an unsigned integer, representing the 202 number of seconds that have passed since the TTL for the RRset 203 expired. 205 5.2. Option Usage 207 Software making a DNS request can signal that it understands Serve- 208 Stale by including the option with one STALE-RRSET-INDEX initialized 209 to any negative value and TTY-EXPIRY initialized to 0. The index is 210 set to a negative value to detect mere reflection of the option by 211 responders that don't really understand it. 213 If the request is made to a recursive resolver which used any stale 214 RRsets in its reply, it then fills in the corresponding indices and 215 staleness values. If no records are stale, STALE-RRSET-INDEX and 216 TTL-EXPIRY are set to 0. 218 If the request is made to an authoritative nameserver, it can use the 219 option in the reply to indicate how the resolver should treat the 220 records in the reply if they are unable to be refreshed later. A 221 default for all RRsets in the message is established by setting the 222 first STALE-RRSET-INDEX to 0, with optional additional STALE-RRSET- 223 INDEX values overriding the default. A TTL-EXPIRY value of 0 means 224 to never serve the RRset as stale, while non-zero values represent 225 the maximum amount of time it can be used before it MUST be evicted. 226 [ Does anyone really want to do this? It adds more state into 227 resolvers. Is the idea only for purists, or is there a practical 228 application? ] 230 No facility is made for a client of a resolver to signal that it 231 doesn't want stale answers, because if a client has knowledge of 232 Serve-Stale as an option, it also has enough knowledge to just ignore 233 any records that come back stale. [ There is admittedly the issue 234 that the client might just want to wait out the whole attempted 235 resolution, which there's currently no way to indicate. The absolute 236 value of STALE-RRSET-INDEX could be taken as a timer the requester is 237 willing to wait for an answer, but that's kind of gross overloading 238 it like that Shame to burn another field on that though, but on the 239 other hand it would be nice if a client could always signal its 240 impatience level - "I must have an answer within 900 milliseconds!" ] 242 6. Example Method 244 There is conceivably more than one way a recursive resolver could 245 responsibly implement this resiliency feature while still respecting 246 the intent of the TTL as a signal for when data is to be refreshed. 248 In this example method three notable timers drive considerations for 249 the use of stale data, as follows: 251 o A client response timer, which is the maximum amount of time a 252 recursive resolver should allow between the receipt of a 253 resolution request and sending its response. 255 o A query resolution timer, which caps the total amount of time a 256 recursive resolver spends processing the query. 258 o A maximum stale timer, which caps the amount of time that records 259 will be kept past their expiration. 261 Recursive resolvers already have the second timer; the first and 262 third timers are new concepts for this mechanism. 264 When a request is received by the recursive resolver, it SHOULD start 265 the client response timer. This timer is used to avoid client 266 timeouts. It SHOULD be configurable, with a recommended value of 1.8 267 seconds. 269 The resolver then checks its cache for an unexpired answer. If it 270 finds none and the Recursion Desired flag is not set in the request, 271 it SHOULD immediately return the response without consulting the 272 cache for expired records. 274 If iterative lookups will be done, it SHOULD start the query 275 resolution timer. This timer bounds the work done by the resolver, 276 and is commonly around 10 to 30 seconds. 278 If the answer has not been completely determined by the time the 279 client response timer has elapsed, the resolver SHOULD then check its 280 cache to see whether there is expired data that would satisfy the 281 request. If so, it adds that data to the response message and SHOULD 282 set the TTL of each expired record in the message to 1 second. The 283 response is then sent to the client while the resolver continues its 284 attempt to refresh the data. 1 second was chosen because historically 285 0 second TTLs have been problematic for some implementations. It not 286 only sidesteps those potential problems with no practical negative 287 consequence, it would also rate limit further queries from any client 288 that is honoring the TTL, such as a forwarding resolver. 290 The maximum stale timer is used for cache management and is 291 independent of the query resolution process. This timer is 292 conceptually different from the maximum cache TTL that exists in many 293 resolvers, the latter being a clamp on the value of TTLs as received 294 from authoritative servers. The maximum stale timer SHOULD be 295 configurable, and defines the length of time after a record expires 296 that it SHOULD be retained in the cache. The suggested value is 7 297 days, which gives time to notice the resolution problem and for human 298 intervention to fix it. 300 This same basic technique MAY be used to handle stale data associated 301 with delegations. If authoritative server addresses are not able to 302 be refreshed, resolution can possibly still be successful if the 303 authoritative servers themselves are still up. 305 7. Implementation Caveats 307 Answers from authoritative servers that have a DNS Response Code of 308 either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have 309 refreshed the data at the resolver. In particular, this means that 310 this method is not meant to protect against operator error at the 311 authoritative server that turns a name that is intended to be valid 312 into one that is non-existent, because there is no way for a resolver 313 to know intent. 315 Resolution is given a chance to succeed before stale data is used to 316 adhere to the original intent of the design of the DNS. This 317 mechanism is only intended to add robustness to failures, and to be 318 enabled all the time. If stale data were used immediately and then a 319 cache refresh attempted after the client response has been sent, the 320 resolver would frequently be sending data that it would have had no 321 trouble refreshing. 323 It is important to continue the resolution attempt after the stale 324 response has been sent, until the query resolution timeout, because 325 some pathological resolutions can take many seconds to succeed as 326 they cope with unavailable servers, bad networks, and other problems. 327 Stopping the resolution attempt when the response with expired data 328 has been sent would mean that answers in these pathological cases 329 would never be refreshed. 331 Canonical Name (CNAME) records mingled in the expired cache with 332 other records at the same owner name can cause surprising results. 333 This was observed with an initial implementation in BIND when a 334 hostname changed from having an IPv4 Address (A) record to a CNAME. 335 The version of BIND being used did not evict other types in the cache 336 when a CNAME was received, which in normal operations is not a 337 significant issue. However, after both records expired and the 338 authorities became unavailable, the fallback to stale answers 339 returned the older A instead of the newer CNAME. 341 [ This probably applies to other occluding types, so more thought 342 should be given to the overall issue. ] 344 Keeping records around after their normal expiration will of course 345 cause caches to grow larger than if records were removed at their 346 TTL. Specific guidance on managing cache sizes is outside the scope 347 of this document. Some areas for consideration include whether to 348 track the popularity of names in client requests versus evicting by 349 maximum age, and whether to provide a feature for manually flushing 350 only stale records. 352 8. Implementation Status 354 [RFC Editor: per RFC 6982 this section should be removed prior to 355 publication.] 357 The algorithm described in the Section 6 section was originally 358 implemented as a patch to BIND 9.7.0. It has been in production on 359 Akamai's production network since 2011, and effectively smoothed over 360 transient failures and longer outages that would have resulted in 361 major incidents. The patch was contributed to the Internet Systems 362 Consortium and is now distributed with BIND 9.12. 364 Unbound has a similar feature for serving stale answers, but it works 365 in a very different way by returning whatever cached answer it has 366 before trying to refresh expired records. This is unfortunately not 367 faithful to the ideal that data past expiry should attempt to be 368 refreshed before being served. 370 9. Security Considerations 372 The most obvious security issue is the increased likelihood of DNSSEC 373 validation failures when using stale data because signatures could be 374 returned outside their validity period. This would only be an issue 375 if the authoritative servers are unreachable, the only time the 376 techniques in this document are used, and thus does not introduce a 377 new failure in place of what would have otherwise been success. 379 Additionally, bad actors have been known to use DNS caches to keep 380 records alive even after their authorities have gone away. This 381 potentially makes that easier, although without introducing a new 382 risk. 384 10. Privacy Considerations 386 This document does not add any practical new privacy issues. 388 11. NAT Considerations 390 The method described here is not affected by the use of NAT devices. 392 12. IANA Considerations 394 This document contains no actions for IANA. This section will be 395 removed during conversion into an RFC by the RFC editor. 397 13. Acknowledgements 399 The authors wish to thank Matti Klock, Mukund Sivaraman, Jean Roy, 400 and Jason Moreau for initial review. Feedback from Robert Edmonds 401 and Davey Song has also been incorporated. 403 14. References 405 14.1. Normative References 407 [RFC1035] Mockapetris, P., "Domain names - implementation and 408 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 409 November 1987, . 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 417 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 418 . 420 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 421 for DNS (EDNS(0))", STD 75, RFC 6891, 422 DOI 10.17487/RFC6891, April 2013, 423 . 425 14.2. Informative References 427 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 428 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 429 2015, . 431 Authors' Addresses 433 David C Lawrence 434 Akamai Technologies 435 150 Broadway 436 Cambridge MA 02142-1054 437 USA 439 Email: tale@akamai.com 441 Warren Kumari 442 Google 443 1600 Amphitheatre Parkway 444 Mountain View CA 94043 445 USA 447 Email: warren@kumari.net 449 Puneet Sood 450 Google 452 Email: puneets@google.com