Internet DRAFT - draft-ihren-delegation-ttls

draft-ihren-delegation-ttls




DNS Operations Working Group                             Johan Ihren
draft-ihren-delegation-ttls-00.txt		         Autonomica
October 2003                                             Expires in six months



         Importance Of Parent-side TTLs For Referrals Several Layers Deep


Status of this Memo

   This document is an Internet-Draft and is subject to all 
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This memo documents a consequence of how the TTL re-writing
   mechanism works (or rather does not work) for the case of a
   resolver chasing a referral chain several layers deep.

   The most common example of this is the case of a recursive resolver
   trying to look up a third level domain name starting from the root.

   A result of how this works is that it seems to be a good idea to
   recommend an increase of the present standard TTL for delegations
   from the root zone from the present 48 hours to something
   significantly longer. But, more importantly, the choice of TTL for
   the referral from the parent should be a decision made by the
   child, not the parent.


1. Introduction.

   When a resolver queries an authoritative server it has to be
   prepared for several possible responses. The responses relevant
   here are primarily

   a) "The Answer", i.e. a response with the answer to the query in
      the Answer section and the enclosing NS RRset in the Authority
      section

   b) "The Referral", i.e. a response with an empty Answer section and
      the NS RRset of the child in the Authority section.

   In the case of the referral the NS RRset is cached based upon the
   TTL associated with the involved records. 

   In the probably most common case this referral will soon be
   followed by an "Answer"-response from the child and then the TTL
   for the NS RRset of the child will be re-written because the child
   is authoritative for the contents of its own NS RRset and that data
   is supplied in the Authority section of the response.

   Since the NS RRset supplied by the parent will therefore only be
   used once and then overwritten it does not matter much what TTL is
   used by the parent for the referral.

   However, in the case where the child will respond with another
   referral (i.e. referring further down the hierarchy to a grandchild
   of the parent) the response will contain an Authority section with
   the referral data for the grandchild, rather than the childs
   authoritative statement on its own NS RRset. 

   In this case the NS RRset for the child supplied by the parent will
   not be overwritten and therefore it will stay in the cache of the
   recursive resolver for as long as the parent-side TTL specifies. In
   this case the parent-side TTL will matter very much.


2. Recommendation.

   Following a referral several layers down into the DNS hiearchy is
   especially common when looking up data starting from the root.
   Therefore every TLD will be subject to this phenomena of the child
   (i.e. the TLD) not updating the TTL information for the referral
   from the parent. There are examples in other parts of the hierarchy
   too.

   Therefore it would be correct to let the child influence the choice
   of parent-side TTL for a referral. In the particular case of TLD
   referrals increasing the present 48 hour TTL significantly seems
   appropriate.

   Exactly how long a suitable TTL is will vary, but given that
   typical turn-around time for changes to the root zone is on the
   order of several weeks it does not seem excessive to use a one week
   TTL as a base recommendation.


3. Security Considerations.

   It is concievable that using a longer TTL than 48 hours in a TLD
   delegation may cause problems in the case of an emergency rollover
   from an old NS RRset to a new one. 

   On the other hand it is also concievable that a resolver may be cut
   off from root name service for for a period of time during which
   the cached referrals expire. By using a longer TTL the risk of this
   scenario is decreased. 

   Which case is considered most likely or most important will not be
   the same for all zones. It is therefore not a good idea to have the
   TTL of the referral be decided by the parent since it should be a
   decision for the child.


4. IANA Considerations.

   Presently IANA uses the same 48 hour TTL on all delegation
   information from the root, arpa and in-addr.arpa zones. Based upon
   the argument above it is recommended that this practice is replaced
   by instead honoring the wishes of the child for what TTL is
   appropriate in each particular case.


5. References

5.1. Normative.

   [RFC1034] Domain Names - Concepts and Facilities. P.V. Mockapetris,
	     November 1987.

   [RFC1035] Domain Names - Implementation and Specification.
	     P.V. Mockapetris. November 1987.

6. Authors' Address

Johan Ihren
Autonomica AB
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
johani@autonomica.se