[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]
Versions: 00 01 02
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]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/