[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/