Document: draft-dns-update-leases-00.txt                      July, 2004
Status: WORK IN PROGRESS

                          Dynamic DNS Update Leases

                      <draft-dns-update-leases-00.txt>

Abstract

   This document proposes a method of extending Dynamic DNS Update to
   contain an update lease life, allowing a server to garbage collect
   stale resource records.


Terminology

   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 "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC 2119].


1. Motivation

   Dynamic DNS Update [RFC 2136] allows for a mapping from a persistent
   hostname to a dynamic IP address.  This capability is particularly
   beneficial to mobile hosts, whose IP address may frequently change
   with location.  However, the mobile nature of such hosts often means
   that dynamically updated resource records are often not properly
   deleted.  Consider, for instance, a mobile user who publishes address
   records via dynamic update.  If this user unplugs the Ethernet cable
   from their laptop, the address record containing stale information
   will remain on the server indefinitely.  "DNS Scavenging" attempts to
   address this issue by configuring clients and servers with a preset
   refresh interval Ð however, this approach does not extend to
   zero-configuration environments in which the client and server are
   not under the same administration.  An extension to Dynamic Update is
   thus required to tell the server to automatically delete resource
   records if they are not refreshed after a period of time.

   Note that overloading the resource record TTL [RFC 1035] is not
   appropriate for purposes of garbage collection.  Data that is
   susceptible to frequent change or invalidation, thus requiring a
   garbage collection mechanism, needs a relatively short resource
   record TTL to avoid polluting intermediate DNS caches with stale
   data.  Using this TTL, short enough to minimize stale cached data, as
   a garbage collection lease life would result in an unacceptable
   amount of network traffic due to refreshes (see section 5).


2. Mechanisms

   Dynamic DNS Update Garbage Collection is implemented using the
   standard Dynamic Update message format [RFC 2136] in conjunction
   with an ENDS0 OPT pseudo-RR [RFC 2671] with a new OPT and RDATA
   format proposed here.  Encoding the Update Lease Life in an OPT RR
   requires minimal modification to a name server's front-end, and will
   cause servers that do not implement this extension to automatically
   return a descriptive error (NOTIMPL).


3. New Assigned Numbers

   EDNS0 OPTION CODE:
           UPDATE-LEASE [TBD]


4. Update Message Format

   Dynamic DNS Update with Garbage Collection Requests and Responses are
   formatted as per [RFC 2136], with the addition of a single OPT-RR as
   the last record in the Additionals section.   Note that if a TSIG
   resource record is to be added to authenticate the update [RFC 2845],
   the OPT-RR should occur BEFORE the TSIG RR, allowing the message
   digest in the TSIG to contain the OPT-RR.

   The OPT-RR is formatted as follows:

   Field Name       Field Type        Description
   ---------------------------------------------------------------------
   NAME             domain name       empty (root domain)
   TYPE             u_int16_t         OPT
   CLASS            u_int16_t         0
   TTL              u_int32_t         0
   RDLEN            u_int16_t         describes RDATA
   RDATA            octet stream      (see below)

   RDATA Format:

   Field Name        Field Type       Description
   ---------------------------------------------------------------------
   OPTION-CODE       u_int16_t        UPDATE-LEASE
   OPTION-LENGTH     u_int16_t        sizeof(int32_t)
   LEASE             int32_t          desired lease (Request) or granted
                                      lease (response), in seconds

   Update Requests contain, in the LEASE field of the OPT RDATA, a
   signed 32-bit integer indicating the lease life, in seconds, desired
   by the client.   In Update Responses, this field contains the actual
   lease granted by the server.  Note that the lease granted by the
   server may be less than, greater than, or equal to the value
   requested by the client.  To reduce network and server load, a
   minimum lease of 30 minutes (7200 seconds) is recommended.  Note that
   leases are expected to be sufficiently long as to make timer
   discrepancies  (due to transmission latency, etc.) between a client
   and server negligible.  Clients that expect the updated records to be
   relatively static MAY request appropriately longer leases. Servers
   may grant relatively longer or shorter leases to reduce network
   traffic due to refreshes, or reduce stale data, respectively.

   The Update Lease indicated in the OPT-RR applies to all resource
   records in the Updates section.


5. Refresh Messages

   Resource records not to be deleted by the server MUST be refreshed by
   the client before the lease elapses.  Clients SHOULD refresh resource
   records after 75% of the original lease has elapsed.  If the client 
   uses UDP and does not receive a response from the server, the client
   SHOULD re-try after 2 seconds.  The client SHOULD continue to re-try,
   doubling the length of time between each re-try, or re-try using TCP.


5.1 Coalescing Refresh Messages

   If the client has sent multiple updates to a single server, the
   client MAY include refreshes for all valid updates to that server in
   a single message.  This effectively places all records for a client
   on the same expiration schedule, reducing network traffic due to
   refreshes.  In doing so, the client includes in the refresh message
   all existing updates to the server, including those not yet close to
   expiration, so long as at least one resource record in the message
   has elapsed at least 75% of its original lease.  If the client uses
   UDP, the client MUST NOT coalesce refresh messages if doing so would
   cause truncation of the message Ð in this case, multiple messages or
   TCP should be used.


5.2 Refresh Message Format

   Refresh messages are formatted like Dynamic Update with Garbage
   Collection Requests and Responses (3.2).  The resource records to be
   refreshed are contained in the Update section.  These same resource
   records are repeated in the Prerequisites section, as an "RRSet
   exists (value dependent)" prerequisite as per [RFC 2136] section 2.4.
   An OPT-RR is the last resource record in the Additionals section
   (except for a TSIG record, which, if required, follows the OPT-RR).
   The OPT-RR contains the desired new lease on Requests, and the actual
   granted lease on Responses.

   The Update Lease indicated in the OPT-RR applies to all resource
   records in the Updates section.


5.3 Server Behavior

   Upon receiving a valid Refresh Request, the server MUST send an
   acknowledgement.  This acknowledgement is identical to the Update
   Response format described in section 4, and contains the new lease of
   the resource records being refreshed.  If no records in the Refresh
   Request have completed 75% of their leases, the server SHOULD NOT
   refresh the updates Ð the response should contain the smallest
   remaining (unrefreshed) lease of all records in the refresh message. 
   The server MUST NOT increment the SOA serial number of a zone as the
   result of a refresh.


6. Garbage Collection

   If the Update Lease of a resource record elapses without being
   refreshed, the server MUST NOT return the expired record in answers
   to queries.  The server MAY delete the record from its database.


7. Copyright

   Copyright (C) 2004 Apple Computer, Inc.
   All Rights Reserved.


8. References

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specifications", STD 13, RFC 1035, November 1987.

   [RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate
              Requirement Levels

   [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
              System (DNS UPDATE)", RFC 2136, April 1997.

   [RFC 2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC 2845] Vixie, P., et al., "Secret Key Transaction Authentication
              for DNS (TSIG)", RFC 2845, May 2000.