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", ,
<http://www.iana.org/assignments/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]