idnits 2.17.1 draft-sekar-dns-ul-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 210. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2006) is 6465 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Document: draft-sekar-dns-ul-01.txt Stuart Cheshire 2 Internet-Draft Marc Krochmal 3 Category: Standards Track Apple Computer, Inc. 4 Expires 10th February 2007 Kiren Sekar 5 Sharpcast, Inc. 6 10th August 2006 8 Dynamic DNS Update Leases 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 For the purposes of this document, the term "BCP 79" refers 19 exclusively to RFC 3979, "Intellectual Property Rights in IETF 20 Technology", published March 2005. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document proposes a method of extending Dynamic DNS Update to 41 contain an update lease life, allowing a server to garbage collect 42 stale resource records. 44 1. Introduction 46 Dynamic DNS Update [RFC 2136] allows for a mapping from a persistent 47 hostname to a dynamic IP address. This capability is particularly 48 beneficial to mobile hosts, whose IP address may frequently change 49 with location. However, the mobile nature of such hosts often means 50 that dynamically updated resource records are often not properly 51 deleted. Consider, for instance, a mobile user who publishes address 52 records via dynamic update. If this user unplugs the Ethernet cable 53 from their laptop, the address record containing stale information 54 will remain on the server indefinitely. "DNS Scavenging" attempts to 55 address this issue by configuring clients and servers with a preset 56 refresh interval, however, this approach does not extend to 57 zero-configuration environments in which the client and server are 58 not under the same administration. An extension to Dynamic Update is 59 thus required to tell the server to automatically delete resource 60 records if they are not refreshed after a period of time. 62 Note that overloading the resource record TTL [RFC 1035] is not 63 appropriate for purposes of garbage collection. Data that is 64 susceptible to frequent change or invalidation, thus requiring a 65 garbage collection mechanism, needs a relatively short resource 66 record TTL to avoid polluting intermediate DNS caches with stale 67 data. Using this TTL, short enough to minimize stale cached data, 68 as a garbage collection lease life would result in an unacceptable 69 amount of network traffic due to refreshes (see section 6 "Refresh 70 Messages"). 72 2. Conventions and Terminology Used in this Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in "Key words for use in 77 RFCs to Indicate Requirement Levels" [RFC 2119]. 79 3. Mechanisms 81 Dynamic DNS Update Leases is implemented using the standard Dynamic 82 Update message format [RFC 2136] in conjunction with an ENDS0 OPT 83 pseudo-RR [RFC 2671] with a new OPT and RDATA format proposed here. 84 Encoding the Update Lease Life in an OPT RR requires minimal 85 modification to a name server's front-end, and will cause servers 86 that do not implement this extension to automatically return a 87 descriptive error (NOTIMPL). 89 4. New Assigned Numbers 91 EDNS0 OPTION CODE: 92 UPDATE-LEASE 2 94 5. Update Message Format 96 Dynamic DNS Update Leases Requests and Responses are formatted as per 97 [RFC 2136], with the addition of a single OPT-RR as the last record 98 in the Additional section. Note that if a TSIG resource record is 99 to be added to authenticate the update [RFC 2845], the OPT-RR should 100 occur BEFORE the TSIG RR, allowing the message digest in the TSIG to 101 contain the OPT-RR. 103 The OPT-RR is formatted as follows: 105 Field Name Field Type Description 106 --------------------------------------------------------------------- 107 NAME domain name empty (root domain) 108 TYPE u_int16_t OPT 109 CLASS u_int16_t 0 110 TTL u_int32_t 0 111 RDLEN u_int16_t describes RDATA 112 RDATA octet stream (see below) 114 RDATA Format: 116 Field Name Field Type Description 117 --------------------------------------------------------------------- 118 OPTION-CODE u_int16_t UPDATE-LEASE (2) 119 OPTION-LENGTH u_int16_t sizeof(int32_t) 120 LEASE int32_t desired lease (request) or granted 121 lease (response), in seconds 123 Update Requests contain, in the LEASE field of the OPT RDATA, a 124 signed 32-bit integer indicating the lease life, in seconds, desired 125 by the client. In Update Responses, this field contains the actual 126 lease granted by the server. Note that the lease granted by the 127 server may be less than, greater than, or equal to the value 128 requested by the client. To reduce network and server load, a 129 minimum lease of 30 minutes (1800 seconds) is RECOMMENDED. Note that 130 leases are expected to be sufficiently long as to make timer 131 discrepancies (due to transmission latency, etc.) between a client 132 and server negligible. Clients that expect the updated records to be 133 relatively static MAY request appropriately longer leases. Servers 134 MAY grant relatively longer or shorter leases to reduce network 135 traffic due to refreshes, or reduce stale data, respectively. 137 The Update Lease indicated in the OPT-RR applies to all resource 138 records in the Update section. 140 6. Refresh Messages 142 Resource records not to be deleted by the server MUST be refreshed by 143 the client before the lease elapses. Clients SHOULD refresh resource 144 records after 75% of the original lease has elapsed. If the client 145 uses UDP and does not receive a response from the server, the client 146 SHOULD re-try after 2 seconds. The client SHOULD continue to re-try, 147 doubling the length of time between each re-try, or re-try using TCP. 149 6.1 Coalescing Refresh Messages 151 If the client has sent multiple updates to a single server, the 152 client MAY include refreshes for all valid updates to that server in 153 a single message. This effectively places all records for a client 154 on the same expiration schedule, reducing network traffic due to 155 refreshes. In doing so, the client includes in the refresh message 156 all existing updates to the server, including those not yet close to 157 expiration, so long as at least one resource record in the message 158 has elapsed at least 75% of its original lease. If the client uses 159 UDP, the client MUST NOT coalesce refresh messages if doing so would 160 cause truncation of the message; in this case, multiple messages or 161 TCP should be used. 163 6.2 Refresh Message Format 165 Refresh messages are formatted like Dynamic Update Leases Requests 166 and Responses (see Section 5 "Update Message Format"). The resource 167 records to be refreshed are contained in the Update section. These 168 same resource records are repeated in the Prerequisite section, as 169 an "RRSet exists (value dependent)" prerequisite as per [RFC 2136] 170 section 2.4. An OPT-RR is the last resource record in the Additional 171 section (except for a TSIG record, which, if required, follows the 172 OPT-RR). The OPT-RR contains the desired new lease on Requests, and 173 the actual granted lease on Responses. The Update Lease indicated in 174 the OPT-RR applies to all resource records in the Update section. 176 6.3 Server Behavior 178 Upon receiving a valid Refresh Request, the server MUST send an 179 acknowledgment. This acknowledgment is identical to the Update 180 Response format described in section 5 "Update Message Format", 181 and contains the new lease of the resource records being refreshed. 182 If no records in the Refresh Request have completed 75% of their 183 leases, the server SHOULD NOT refresh the updates; the response 184 should contain the smallest remaining (unrefreshed) lease of all 185 records in the refresh message. The server MUST NOT increment the 186 SOA serial number of a zone as the result of a refresh. 188 7. Garbage Collection 190 If the Update Lease of a resource record elapses without being 191 refreshed, the server MUST NOT return the expired record in answers 192 to queries. The server MAY delete the record from its database. 194 8. Copyright Notice 196 Copyright (C) The Internet Society (2006). 198 This document is subject to the rights, licenses and restrictions 199 contained in BCP 78, and except as set forth therein, the authors 200 retain all their rights. For the purposes of this document, 201 the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights 202 in Contributions", published March 2005. 204 This document and the information contained herein are provided on 205 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 206 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 207 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 208 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 209 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 212 9. IANA Considerations 214 The EDNS0 OPTION CODE 2 has already been assigned for this DNS 215 extension. No additional IANA services are required by this document. 217 10. Acknowledgments 219 The concepts described in this document have been explored, developed 220 and implemented with help from Roger Pantos and Chris Sharp. 222 11. Normative References 224 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 225 Specifications", STD 13, RFC 1035, November 1987. 227 [RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate 228 Requirement Levels 230 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 231 System (DNS UPDATE)", RFC 2136, April 1997. 233 [RFC 2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 234 RFC 2671, August 1999. 236 12. Informative References 238 [RFC 2845] Vixie, P., et al., "Secret Key Transaction Authentication 239 for DNS (TSIG)", RFC 2845, May 2000. 241 13. Authors' Addresses 243 Stuart Cheshire 244 Apple Computer, Inc. 245 1 Infinite Loop 246 Cupertino 247 California 95014 248 USA 250 Phone: +1 408 974 3207 251 EMail: rfc [at] stuartcheshire [dot] org 253 Marc Krochmal 254 Apple Computer, Inc. 255 1 Infinite Loop 256 Cupertino 257 California 95014 258 USA 260 Phone: +1 408 974 4368 261 EMail: marc [at] apple [dot] com 263 Kiren Sekar 264 Sharpcast, Inc. 265 250 Cambridge Ave, Suite 101 266 Palo Alto 267 California 94306 268 USA 270 Phone: +1 650 323 1960 271 EMail: ksekar [at] sharpcast [dot] com