idnits 2.17.1 draft-wkumari-dnsop-ttl-stretching-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2016) is 2692 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 149, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-wkumari-dnsop-hammer-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational November 14, 2016 5 Expires: May 18, 2017 7 Stretching DNS TTLs 8 draft-wkumari-dnsop-ttl-stretching-00 10 Abstract 12 The TTL of a DNS Resource Record expresses how long a record may be 13 cached before it should be discarded. This document discusses the 14 possibility of "stretching TTLS" (using them past their expiration) 15 if they cannot be refreshed. This works on the assumption that stale 16 data may be better than no data. 18 PLEASE NOTE: This document is a strawman to drive discussion. It may 19 or may not be a good idea; this document documents the idea so that 20 there is something concrete to throw tomatoes at. 22 [ Ed note: Text inside square brackets ([]) is additional background 23 information, answers to frequently asked questions, general musings, 24 etc. They will be removed before publication. This document is 25 being collaborated on in Github at: https://github.com/wkumari/draft- 26 wkumari-dnsop-ttl-stretching. The most recent version of the 27 document, open issues, etc should all be available here. The authors 28 (gratefully) accept pull requests ] 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 18, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 66 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 72 6.2. Informative References . . . . . . . . . . . . . . . . . 4 73 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 4 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1. Introduction 78 DNS Resource Records (RR) have an associated TTL. This is how long 79 the record may be cached before it should be expired and new 80 information fetched. This is based upon the assumption that the 81 authoritative servers will be reachable when they are needed, and 82 that records expire and are immediately evicted from the cache. 84 There are a number of reasons why an authoritative server may become 85 unreachable, including, unfortunately, Denial of Service (DoS) 86 attacks. Recent proposals, for example "Highly Automated Method for 87 Maintaining Expiring Records" ([I-D.wkumari-dnsop-hammer]) propose 88 refreshing records in the cache before they expire and are evicted. 89 This means that the recursive server still has information in its 90 cache when it attempts to contact the authoritative server. 92 This document suggests that, if the recursive server is unable to 93 contact the authoritative server, it simply extends the existing 94 records TTL, on the assumption that "stale bread if better than no 95 bread". 97 [Ed: This is the primary point of the document / question -- if you 98 cannot reach the authoritative nameservers (perhaps they being DoS- 99 ed, perhaps they were unplugged, you cannot really tell) it is better 100 to use the last known (and perhaps outdated) information, or is it 101 better for the domain to go dark? I think the former, but this is a 102 significant change to the meaning / semantics of TTLs). 104 1.1. Requirements notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Proposal 112 If a recursive nameserver is unable to contact any of the 113 authoritative nameservers for a zone, and it still has the resource 114 record cached, it MAY "stretch" the TTL by simply increasing it it by 115 the original TTL. It may do this N times, where N should be 116 configurable. 118 [ Ed: I was going to say "by doubling the TTL", but then if we allow 119 implementations to do this e.g 3 times, is that 4 times the original 120 TTL, or is it 2^3 the original TTL]. 122 3. IANA Considerations 124 This document contains no IANA considerations.Template: Fill this in! 126 4. Security Considerations 128 TODO: Fill this out! 130 5. Acknowledgements 132 The authors wish to thank some folk. 134 6. References 136 6.1. Normative References 138 [IANA.AS_Numbers] 139 IANA, "Autonomous System (AS) Numbers", 140 . 142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 143 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 144 RFC2119, March 1997, 145 . 147 6.2. Informative References 149 [I-D.ietf-sidr-iana-objects] 150 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 151 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 152 progress), May 2011. 154 [I-D.wkumari-dnsop-hammer] 155 Kumari, W., Arends, R., and S. Woolf, "Highly Automated 156 Method for Maintaining Expiring Records", draft-wkumari- 157 dnsop-hammer-00 (work in progress), July 2013. 159 Appendix A. Changes / Author Notes. 161 [RFC Editor: Please remove this section before publication ] 163 From -00 to -01 165 o Nothing changed in the template! 167 Author's Address 169 Warren Kumari 170 Google 171 1600 Amphitheatre Parkway 172 Mountain View, CA 94043 173 US 175 Email: warren@kumari.net