Document: draft-sekar-dns-ul-01.txt Stuart Cheshire Internet-Draft Marc Krochmal Category: Standards Track Apple Computer, Inc. Expires 10th February 2007 Kiren Sekar Sharpcast, Inc. 10th August 2006 Dynamic DNS Update Leases <draft-sekar-dns-ul-01.txt> Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. For the purposes of this document, the term "BCP 79" refers exclusively to RFC 3979, "Intellectual Property Rights in IETF Technology", published March 2005. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. Expires 10th February 2007 Sekar, et al. [Page 1]
Internet Draft Dynamic DNS Update Leases 10th August 2006 1. Introduction 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 6 "Refresh Messages"). 2. Conventions and Terminology Used in this Document 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]. 3. Mechanisms Dynamic DNS Update Leases 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). 4. New Assigned Numbers EDNS0 OPTION CODE: UPDATE-LEASE 2 Expires 10th February 2007 Sekar, et al. [Page 2]
Internet Draft Dynamic DNS Update Leases 10th August 2006 5. Update Message Format Dynamic DNS Update Leases Requests and Responses are formatted as per [RFC 2136], with the addition of a single OPT-RR as the last record in the Additional 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 (2) 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 (1800 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 Update section. Expires 10th February 2007 Sekar, et al. [Page 3]
Internet Draft Dynamic DNS Update Leases 10th August 2006 6. 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. 6.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. 6.2 Refresh Message Format Refresh messages are formatted like Dynamic Update Leases Requests and Responses (see Section 5 "Update Message Format"). The resource records to be refreshed are contained in the Update section. These same resource records are repeated in the Prerequisite 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 Additional 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 Update section. 6.3 Server Behavior Upon receiving a valid Refresh Request, the server MUST send an acknowledgment. This acknowledgment is identical to the Update Response format described in section 5 "Update Message Format", 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. Expires 10th February 2007 Sekar, et al. [Page 4]
Internet Draft Dynamic DNS Update Leases 10th August 2006 7. 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. 8. Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. For the purposes of this document, the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights in Contributions", published March 2005. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. IANA Considerations The EDNS0 OPTION CODE 2 has already been assigned for this DNS extension. No additional IANA services are required by this document. 10. Acknowledgments The concepts described in this document have been explored, developed and implemented with help from Roger Pantos and Chris Sharp. 11. Normative 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. Expires 10th February 2007 Sekar, et al. [Page 5]
Internet Draft Dynamic DNS Update Leases 10th August 2006 12. Informative References [RFC 2845] Vixie, P., et al., "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. 13. Authors' Addresses Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA Phone: +1 408 974 3207 EMail: rfc [at] stuartcheshire [dot] org Marc Krochmal Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA Phone: +1 408 974 4368 EMail: marc [at] apple [dot] com Kiren Sekar Sharpcast, Inc. 250 Cambridge Ave, Suite 101 Palo Alto California 94306 USA Phone: +1 650 323 1960 EMail: ksekar [at] sharpcast [dot] com Expires 10th February 2007 Sekar, et al. [Page 6]