idnits 2.17.1 draft-sekar-dns-ul-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year == Line 123 has weird spacing: '...in name empt...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (27 July 2021) is 997 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) == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-srp-10 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track T. Lemon 5 Expires: 28 January 2022 Apple Inc 6 27 July 2021 8 An EDNS0 option to negotiate Leases on DNS Updates 9 draft-sekar-dns-ul-03 11 Abstract 13 This document proposes a new EDNS0 option that can be used by DNS 14 Update clients and DNS servers to include a lease lifetime in a DNS 15 Update or response, allowing a server to garbage collect stale 16 resource records that have been added by DNS Updates 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 28 January 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions and Terminology Used in this Document . . . . . . 3 53 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Update Message Format . . . . . . . . . . . . . . . . . . . . 3 55 5. Refresh Messages . . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. Coalescing Refresh Messages . . . . . . . . . . . . . . . 4 57 5.2. Refresh Message Format . . . . . . . . . . . . . . . . . 5 58 5.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 5 59 6. Garbage Collection . . . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 10. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Dynamic DNS Update [RFC2136] allows for a mapping from a persistent 69 hostname to a dynamic IP address. This capability is particularly 70 beneficial to mobile hosts, whose IP address may frequently change 71 with location. However, the mobile nature of such hosts often means 72 that dynamically updated resource records are not properly deleted. 73 Consider, for instance, a mobile user who publishes address records 74 via dynamic update. If this user moves their laptop out of range of 75 the Wi-Fi access point, the address record containing stale 76 information may remain on the server indefinitely. An extension to 77 Dynamic Update is thus required to tell the server to automatically 78 delete resource records if they are not refreshed after a period of 79 time. 81 Note that overloading the resource record TTL [RFC1035] is not 82 appropriate for purposes of garbage collection. Data that is 83 susceptible to frequent change or invalidation, thus requiring a 84 garbage collection mechanism, needs a relatively short resource 85 record TTL to avoid polluting intermediate DNS caches with stale 86 data. Using this TTL, short enough to minimize stale cached data, as 87 a garbage collection lease lifetime would result in an unacceptable 88 amount of network traffic due to refreshes (see Section 5 "Refresh 89 Messages"). 91 2. Conventions and Terminology Used in this Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 "Key words for use in RFCs to Indicate Requirement Levels", when, and 97 only when, they appear in all capitals, as shown here [RFC2119] 98 [RFC8174]. 100 3. Mechanisms 102 The EDNS0 Update Lease option is included in a standard Dynamic 103 Update message format [RFC2136] within an EDNS(0) OPT pseudo-RR 104 [RFC2671] with a new OPT and RDATA format proposed here. Encoding 105 the Update Lease Lifetime in an OPT RR requires minimal modification 106 to a name server's front-end, and will cause servers that do not 107 implement this extension to automatically return a descriptive error 108 (NOTIMPL). 110 4. Update Message Format 112 Dynamic DNS Update Leases Requests and Responses are formatted as 113 standard DNS Dynamic Update messages [RFC2136], with the addition of 114 a single OPT RR in the Additional section. Note that if a TSIG 115 resource record is to be added to authenticate the update [RFC2845], 116 the TSIG RR should appear *after* the OPT RR, allowing the message 117 digest in the TSIG to cover the OPT RR. 119 The OPT RR is formatted as follows: 121 Field Name Field Type Description 122 ---------------------------------------------------------------- 123 NAME domain name empty (root domain) 124 TYPE u_int16_t OPT 125 CLASS u_int16_t 0 126 TTL u_int32_t 0 127 RDLEN u_int16_t describes RDATA 128 RDATA byte stream (see below) 130 RDATA Format: 132 Field Name Field Type Description 133 ---------------------------------------------------------------- 134 OPTION-CODE u_int16_t UPDATE-LEASE (2) 135 OPTION-LENGTH u_int16_t 4 or 8 136 LEASE u_int32_t desired lease (request) or 137 granted lease (response), in seconds 138 KEY-LEASE u_int32_t optional desired (or granted) lease 139 Figure 1 141 Update Requests contain, in the LEASE field of the OPT RDATA, an 142 unsigned 32-bit integer indicating the lease lifetime, in seconds, 143 desired by the client, represented in network (big-endian) byte 144 order. In Update Responses, this field contains the actual lease 145 granted by the server. The lease granted by the server may be less 146 than, greater than, or equal to the value requested by the client. 147 To reduce network and server load, a minimum lease of 30 minutes 148 (1800 seconds) is RECOMMENDED. Leases are expected to be 149 sufficiently long as to make timer discrepancies (due to transmission 150 latency, etc.) between a client and server negligible. Clients that 151 expect the updated records to be relatively static MAY request 152 appropriately longer leases. Servers MAY grant relatively longer or 153 shorter leases to reduce network traffic due to refreshes, or reduce 154 stale data, respectively. 156 There are two variants of the EDNS(0) UPDATE-LEASE option, the basic 157 (4-byte) variant and the extended (8-byte) variant. 159 In the basic (4-byte) variant, the LEASE indicated in the OPT RR 160 applies to all resource records in the Update section. 162 In the extended (8-byte) variant, the Update Lease communicates two 163 lease lifetimes. The LEASE indicated in the OPT RR applies to all 164 resource records in the Update section *except* for KEY records. The 165 KEY-LEASE indicated in the OPT RR applies to KEY records in the 166 Update section. This variant is used specifically for supporting the 167 DNS-SD Service Registration Protocol [I-D.ietf-dnssd-srp]. 169 5. Refresh Messages 171 Resource records not to be deleted by the server MUST be refreshed by 172 the client before the lease elapses. Clients SHOULD refresh resource 173 records after 75% of the original lease has elapsed. If the client 174 uses UDP and does not receive a response from the server, the client 175 SHOULD re-try after 2 seconds. The client SHOULD continue to re-try, 176 doubling the length of time between each re-try, or re-try using TCP. 178 5.1. Coalescing Refresh Messages 180 If the client has sent multiple updates to a single server, the 181 client MAY include refreshes for all valid updates to that server in 182 a single message. This effectively places all records for a client 183 on the same expiration schedule, reducing network traffic due to 184 refreshes. In doing so, the client includes in the refresh message 185 all existing updates to the server, including those not yet close to 186 expiration, so long as at least one resource record in the message 187 has elapsed at least 75% of its original lease. If the client uses 188 UDP, the client MUST NOT coalesce refresh messages if doing so would 189 cause truncation of the message; in this case, multiple messages or 190 TCP should be used. 192 5.2. Refresh Message Format 194 Refresh messages are formatted like Dynamic Update Leases Requests 195 and Responses (see Section 4 "Update Message Format"). The resource 196 records to be refreshed are contained in the Update section. These 197 same resource records are repeated in the Prerequisite section, as an 198 "RRSet exists (value dependent)" prerequisite [RFC2136]. An OPT RR 199 is the last resource record in the Additional section (except for a 200 TSIG record, which, if required, follows the OPT RR). The OPT RR 201 contains the desired new lease on Requests, and the actual granted 202 lease on Responses. The Update Lease indicated in the OPT RR applies 203 to all resource records in the Update section. 205 5.3. Server Behavior 207 Upon receiving a valid Refresh Request, the server MUST send an 208 acknowledgment. This acknowledgment is identical to the Update 209 Response format described in Section 4 "Update Message Format", and 210 contains the new lease of the resource records being refreshed. If 211 no records in the Refresh Request have completed 50% of their leases, 212 the server SHOULD NOT refresh the records; the response should 213 contain the smallest remaining (unrefreshed) lease of all records in 214 the refresh message. The server MUST NOT increment the SOA serial 215 number of a zone as the result of a refresh. 217 6. Garbage Collection 219 If the Update Lease of a resource record elapses without being 220 refreshed, the server MUST NOT return the expired record in answers 221 to queries. The server MAY delete the record from its database. 223 7. IANA Considerations 225 The EDNS(0) OPTION CODE 2 has already been assigned for this DNS 226 extension. No additional IANA services are required by this 227 document. 229 8. Acknowledgments 231 Thanks to Marc Krochmal and Kiren Sekar to their work in 2006 on the 232 precursor to this document. Thanks also to Roger Pantos and Chris 233 Sharp for their contributions. 235 9. Normative References 237 [RFC1035] Mockapetris, P., "Domain names - implementation and 238 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 239 November 1987, . 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, 243 DOI 10.17487/RFC2119, March 1997, 244 . 246 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 247 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 248 RFC 2136, DOI 10.17487/RFC2136, April 1997, 249 . 251 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 252 RFC 2671, DOI 10.17487/RFC2671, August 1999, 253 . 255 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 256 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 257 May 2017, . 259 10. Informative References 261 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 262 Wellington, "Secret Key Transaction Authentication for DNS 263 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 264 . 266 [I-D.ietf-dnssd-srp] 267 Lemon, T. and S. Cheshire, "Service Registration Protocol 268 for DNS-Based Service Discovery", Work in Progress, 269 Internet-Draft, draft-ietf-dnssd-srp-10, 12 July 2021, 270 . 273 Authors' Addresses 275 Stuart Cheshire 276 Apple Inc. 277 One Apple Park Way 278 Cupertino, California 95014 279 United States of America 281 Phone: +1 408 974 3207 282 Email: cheshire@apple.com 283 Ted Lemon 284 Apple Inc 285 P.O. Box 958 286 Brattleboro, Vermont 05302 287 United States of America 289 Email: mellon@fugue.com