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