template W. Kumari Internet-Draft Google Intended status: Informational R. Arends Expires: January 02, 2014 Nominet S. Woolf Internet Systems Consortium, Inc. July 01, 2013 Highly Automated Method for Maintaining Expiring Records draft-wkumari-dnsop-hammer-00 Abstract This document describes a simple DNS cache optimization which keeps the most popular records in the DNS cache. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 02, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kumari, et al. Expires January 02, 2014 [Page 1] Internet-Draft hammer July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 4 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction A recursive DNS resolver may cache a Resource Record (RR) for, at most, the Time To Live (TTL) associated with that record. While the TTL is greater than zero, the resolver may respond to queries from its cache, but once the TTL has reached zero, the resolver flushes the RR. When the resolver gets another query for that resource, it needs to initiate a new query. This is then cached and returned to the querying client. This document proposes an optimization (Highly Automated Method for Maintaining Expiring Records -- (HAMMER)) to help keep popular responses in the cache, by fetching new responses before the TTL expires. It is designed to not require much additional state. [I-D.ietf-sidr-iana-objects] and this is a reference to a draft. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Details When a recursive resolver responds to a client, it either responds from cache, or it initiates an iterative query to resolve the answer, caches the answer and then respond with that answer. Performing iterative queries to resolve the answers takes significant time, and so responding from cache is preferable. When a recursive resolver that implements HAMMER receives a query for information that it has in the cache, it responds from the cache. It also checks to see if the remaining TTL on the cached data is less Kumari, et al. Expires January 02, 2014 [Page 2] Internet-Draft hammer July 2013 than HAMMER_TIME (described below). If it is, the resolver will initiate a "cache fill" iterative query, just like it would have if the cached data had expired. During this cache fill operation the resolver continues to respond from cache (until the TTL expires). When the cache fill query completes, the new response replaces the existing cached information. This ensure that the cache has fresh data for subsequent queries. Since the cache fill query is initiated before the existing cached entry expires (and is flushed), responses will come from the cache more often. This decreases the client resolution latency and improves the user experience. As the cache fill resolution is triggered by an incoming query (and only if that query arrives shortly before the record would expire anyway), this effectively keeps the most popular data in the cache, without having to maintain counters in the cache, or proactively resolve responses that are not likely to be needed as often. This is purely an implementation optimization - resolvers always have the option to cache records for less than the TTL (for example, when running low on cache space, etc), this simply triggers a refresh of the RR before it expires. If the original TTL of the RR is less than (or close to HAMMER_TIME), the described method could cause excessive cache fill queries to occur. In order to prevent this an additional variable named STOP (described below) is introduced. If the original TTL of the RR is less than STOP * HAMMER_TIME then the cache entry should be marked with a "Can't touch this" flag, and the described method should not be used. 2.1. Variables HAMMER_TIME is the number of seconds before TTL expiration that a cache fill query should be initiated. This should be a user configurable value. A default of 2 seconds is RECOMMENDED. STOP should be a user configurable variable. A default of 3 is recommended. 3. IANA Considerations This document makes no request of the IANA. 4. Security Considerations This technique leverages existing protocols, and should not introduce any new risks, other than a slight increase in traffic. Kumari, et al. Expires January 02, 2014 [Page 3] Internet-Draft hammer July 2013 By initiating cache fill entries before the existing RR has expired this technique will slightly increase the number of queries seen by authoritative servers. This increase will be inversely proportional to the average TTL of the records that they serve. It is unlikely, but possible that this increase could cause a denial of service condition. 5. Acknowledgements The authors wish to thank Tony Finch and MC Hammer. 6. References 6.1. Normative References [IANA.AS_Numbers] IANA, "Autonomous System (AS) Numbers", , . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [I-D.ietf-sidr-iana-objects] Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects issued by IANA", draft-ietf-sidr-iana-objects-03 (work in progress), May 2011. Appendix A. Changes / Author Notes. [RFC Editor: Please remove this section before publication ] From -template to -00. o Wrote some text. o Changed the name. Authors' Addresses Kumari, et al. Expires January 02, 2014 [Page 4] Internet-Draft hammer July 2013 Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: warren@kumari.net Roy Arends Nominet Edmund Halley Road Oxford OX4 4DQ United Kingdom Email: roy@nominet.org.uk Suzanne Woolf Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US Email: woolf@isc.org Kumari, et al. Expires January 02, 2014 [Page 5]