idnits 2.17.1 draft-wkumari-dnsop-hammer-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 (July 01, 2013) is 3950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 template W. Kumari 3 Internet-Draft Google 4 Intended status: Informational R. Arends 5 Expires: January 02, 2014 Nominet 6 S. Woolf 7 Internet Systems Consortium, Inc. 8 July 01, 2013 10 Highly Automated Method for Maintaining Expiring Records 11 draft-wkumari-dnsop-hammer-00 13 Abstract 15 This document describes a simple DNS cache optimization which keeps 16 the most popular records in the DNS cache. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 02, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 54 2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 6.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 A recursive DNS resolver may cache a Resource Record (RR) for, at 68 most, the Time To Live (TTL) associated with that record. While the 69 TTL is greater than zero, the resolver may respond to queries from 70 its cache, but once the TTL has reached zero, the resolver flushes 71 the RR. When the resolver gets another query for that resource, it 72 needs to initiate a new query. This is then cached and returned to 73 the querying client. This document proposes an optimization (Highly 74 Automated Method for Maintaining Expiring Records -- (HAMMER)) to 75 help keep popular responses in the cache, by fetching new responses 76 before the TTL expires. It is designed to not require much 77 additional state. 79 [I-D.ietf-sidr-iana-objects] and this is a reference to a draft. 81 1.1. Requirements notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Details 89 When a recursive resolver responds to a client, it either responds 90 from cache, or it initiates an iterative query to resolve the answer, 91 caches the answer and then respond with that answer. Performing 92 iterative queries to resolve the answers takes significant time, and 93 so responding from cache is preferable. 95 When a recursive resolver that implements HAMMER receives a query for 96 information that it has in the cache, it responds from the cache. It 97 also checks to see if the remaining TTL on the cached data is less 98 than HAMMER_TIME (described below). If it is, the resolver will 99 initiate a "cache fill" iterative query, just like it would have if 100 the cached data had expired. During this cache fill operation the 101 resolver continues to respond from cache (until the TTL expires). 102 When the cache fill query completes, the new response replaces the 103 existing cached information. This ensure that the cache has fresh 104 data for subsequent queries. 106 Since the cache fill query is initiated before the existing cached 107 entry expires (and is flushed), responses will come from the cache 108 more often. This decreases the client resolution latency and 109 improves the user experience. 111 As the cache fill resolution is triggered by an incoming query (and 112 only if that query arrives shortly before the record would expire 113 anyway), this effectively keeps the most popular data in the cache, 114 without having to maintain counters in the cache, or proactively 115 resolve responses that are not likely to be needed as often. This is 116 purely an implementation optimization - resolvers always have the 117 option to cache records for less than the TTL (for example, when 118 running low on cache space, etc), this simply triggers a refresh of 119 the RR before it expires. 121 If the original TTL of the RR is less than (or close to HAMMER_TIME), 122 the described method could cause excessive cache fill queries to 123 occur. In order to prevent this an additional variable named STOP 124 (described below) is introduced. If the original TTL of the RR is 125 less than STOP * HAMMER_TIME then the cache entry should be marked 126 with a "Can't touch this" flag, and the described method should not 127 be used. 129 2.1. Variables 131 HAMMER_TIME is the number of seconds before TTL expiration that a 132 cache fill query should be initiated. This should be a user 133 configurable value. A default of 2 seconds is RECOMMENDED. 135 STOP should be a user configurable variable. A default of 3 is 136 recommended. 138 3. IANA Considerations 140 This document makes no request of the IANA. 142 4. Security Considerations 144 This technique leverages existing protocols, and should not introduce 145 any new risks, other than a slight increase in traffic. 147 By initiating cache fill entries before the existing RR has expired 148 this technique will slightly increase the number of queries seen by 149 authoritative servers. This increase will be inversely proportional 150 to the average TTL of the records that they serve. 152 It is unlikely, but possible that this increase could cause a denial 153 of service condition. 155 5. Acknowledgements 157 The authors wish to thank Tony Finch and MC Hammer. 159 6. References 161 6.1. Normative References 163 [IANA.AS_Numbers] 164 IANA, "Autonomous System (AS) Numbers", , 165 . 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 6.2. Informative References 172 [I-D.ietf-sidr-iana-objects] 173 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 174 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 175 progress), May 2011. 177 Appendix A. Changes / Author Notes. 179 [RFC Editor: Please remove this section before publication ] 181 From -template to -00. 183 o Wrote some text. 185 o Changed the name. 187 Authors' Addresses 188 Warren Kumari 189 Google 190 1600 Amphitheatre Parkway 191 Mountain View, CA 94043 192 US 194 Email: warren@kumari.net 196 Roy Arends 197 Nominet 198 Edmund Halley Road 199 Oxford OX4 4DQ 200 United Kingdom 202 Email: roy@nominet.org.uk 204 Suzanne Woolf 205 Internet Systems Consortium, Inc. 206 950 Charter Street 207 Redwood City, CA 94063 208 US 210 Email: woolf@isc.org