idnits 2.17.1 draft-ietf-dnsind-defupd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 81 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([NOTIFY], [DHCP], [IXFR], [UPDATE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 1996) is 10208 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) -- Missing reference section? 'UPDATE' on line 310 looks like a reference -- Missing reference section? 'DHCP' on line 314 looks like a reference -- Missing reference section? 'NOTIFY' on line 306 looks like a reference -- Missing reference section? 'IXFR' on line 302 looks like a reference -- Missing reference section? 'UPDATE 2' on line 54 looks like a reference -- Missing reference section? 'UPDATE 4' on line 239 looks like a reference -- Missing reference section? 'RFC1035' on line 298 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie (ISC) 3 INTERNET-DRAFT May 1996 4 6 Amends: RFC 1035, [UPDATE] 8 Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 Not all applications that perform dynamic updates using the protocol 31 specified in [UPDATE] want their updates applied immediately. A case 32 in point is [DHCP], wherein the DHCP lease time should control the 33 lifetime of associated DNS data even if the DHCP client or server is 34 not available at the time the DHCP lease expires. 36 The essence of this proposal is that DNS Dynamic Updates should be 37 deferrable for some time delay period, after which they will be 38 executed normally. Furthermore, RRs added or updated by a deferred 39 update can have expiration times specified for them, as enforced by 40 the automatic Dynamic Updates. Automatic serial number changes (as 41 in [UPDATE]), dynamic zone slave notification (see [NOTIFY]) and 42 incremental zone transfer (see [IXFR]) will jointly see to it that 43 the zone changes are propagated with expedience. 45 1 - New Assigned Numbers 47 Opcode: DEFUPD (6?) 48 RRtype: TUU (34?) 49 RRtype: TUE (35?) 51 2 - Message Format 53 The format and encoding of a DEFUPD is identical to that of UPDATE as 54 defined in [UPDATE 2], except that the Opcode is DEFUPD rather than 55 UPDATE, and there are two new RR types that can be used in the 56 Additional Data section. 58 2.1 - Additional Data Section: TUU RR 60 In addition to the optional uses described in [UPDATE 2.6], a DEFUPD 61 request's Additional Data section can include a TUU (Time Until Update) 62 RR as follows: 64 Owner: same as ZNAME (see [UPDATE 2.3]) 65 Class: same as ZCLASS (see [UPDATE 2.3]) 66 Type: TUU (new RRtype for this protocol) 67 TTL: deferral time, relative, in seconds 68 RDLENGTH: 0 69 RDATA: empty 71 Of particular note is the TTL, which contains the relative time delay, 72 in seconds, starting from the time this DEFUPD is received by the 73 primary master, before operations contained in the Update Section (see 74 [UPDATE 2.5]) will actually be performed. 76 2.2 - Additional Data Section: TUE RR 78 In addition to the optional uses described in [UPDATE 2.6], a DEFUPD 79 request's Additional Data section can include a TUU (Time Until Expiry) 80 RR as follows: 82 Owner: same as ZNAME (see [UPDATE 2.3]) 83 Class: same as ZCLASS (see [UPDATE 2.3]) 84 Type: TUE (new RRtype for this protocol) 85 TTL: expiry time, relative, in seconds 86 RDLENGTH: 0 87 RDATA: empty 89 Of particular note is the TTL, which contains the expiration time delay, 90 in seconds, starting from the time this DEFUPD is received by the 91 primary master, of all RRs added or updated by operations in the Update 92 Section (see [UPDATE 2.5]). 94 3 - Server Behavior 96 A server, upon receiving a DEFUPD request, will first scan the request's 97 Additional Data section in search of TUU or TUE RRs. If no RRs of 98 either type TUU or TUE are found, then this request will be processed as 99 a normal UPDATE with no special behaviour. If any TUU or TUE RRs are 100 found, then processing continues as follows. 102 3.1 - Verify TUU RR 104 If any TUU RRs are found in the Additional Data section, this update 105 will be processed with Deferral as explained below. If more than one 106 TUU RR is found, signal FORMERR to requestor. The TUU RR's owner name 107 and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal 108 FORMERR to requestor. The TUU RR's RDLENGTH/RDATA is ignored by 109 implementations of this specification, but future specifications may 110 make use of this field. 112 3.2 - Verify TUE RR 114 If any TUE RRs are found in the Additional Data section, this update 115 will be processed with Expiry as explained below. If more than one TUE 116 RR is found, signal FORMERR to requestor. The TUE RR's owner name and 117 class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal 118 FORMERR to requestor. The TUE RR's RDLENGTH/RDATA is ignored by 119 implementations of this specification, but future specifications may 120 make use of this field. 122 3.3 - Deferral 124 If a TUU RR was specified in the Additional Data section, this update 125 will be processed with Deferral. Deferral means that the update will 126 not be applied synchronously to the requestor's transaction cycle, but 127 instead will be applied asynchronously at some potentially later time. 128 The delay period is measured in seconds and expressed in the TUU's TTL. 130 3.3.1 - Store Deferred Update 132 Subject to per-server, per-zone, and per-RRset quotas, this UPDATE 133 message is stored, persistently, on the name server. If per-RRset 134 quotas are implemented, it is recommended that a DEFUPD ``count 135 against'' all RRsets mentioned in the Update Section. If an 136 implementation defined quota is exceeded by this deferred update, or if 137 persistent storage is unavailable, signal SERVFAIL to requestor (leaving 138 the zone in its former state). Note that even a deferred update whose 139 TUU's TTL is zero (0), specifying immediate application, should be 140 subject to quotas if the name server implements quotas. 142 3.3.2 - Send Early Response 144 Signal NOERROR to requestor. 146 3.3.3 - Apply Deferred Update 148 When a period of time equal to or greater than the TUU's TTL (measured 149 in seconds) has elapsed since a DEFUPD was first received at the primary 150 master, the DEFUPD message is applied to the zone as an UPDATE would be, 151 except that no error can be signalled to the requestor. Thus, all 152 errors not found and reported at the time the DEFUPD request was 153 received are silent, affecting only the continued processing of the 154 deferred update. Note that all sections are processed, including those 155 processed before the deferred update were stored. Thus, prerequisites 156 must hold before and after the deferral period. 158 3.4 - Expiry Processing 160 When a DEFUPD is applied, either during the requestor's transaction 161 cycle or following the optional Deferral period, the inclusion of a TUE 162 RR in the Additional Data section will cause this update to be processed 163 with Expiry. 165 Expiry as expressed in the TUE's TTL is the time, in seconds, before all 166 RRs added or modified by the Update Section will be automatically 167 deleted by the primary master server. This time is relative to the time 168 the DEFUPD message is processed, which might be after the delay period 169 specified by a TUU RR. 171 3.4.1 - Initial TTL Limits 173 The TTL of all added or updated RRs in the Update Section will be 174 maximized silently to one half of the Expiry time. This will cause 175 downstream caching name servers to purge RRsets containing this RR at 176 least once before expiry. 178 3.4.2 - TTL Half Life 180 Each time an RR's expiry reaches half of its previous value, that RR's 181 TTL will be reduced to half of its previous value, until the TTL reaches 182 a value less than or equal to sixty (60), i.e., one minute of real time, 183 at which time the TTL will not be automatically reduced further by the 184 primary master. It should be noted that RRs held in a server's memory 185 need not be swept for half life processing, as long as the TTL changes 186 appear when the RR next becomes externally visible, and as long as the 187 ``zone has changed'' processing (see below) is done at the time of the 188 half life expiration. 190 Whenever the TTL is automatically reduced by this process, the zone will 191 be considered ``changed'' for the purpose of automatic SOA SERIAL 192 increment (see [UPDATE 3.6]) and real time zone slave notification (see 193 [NOTIFY]). 195 3.4.3 - Automatic Deletion 197 When the time since an RR was added or updated by a DEFUPD with Expiry 198 exceeds the TUE's TTL as specified in that update, all RRs added or 199 updated by that DEFUPD's Update Section will be automatically deleted by 200 the primary master. This deletion can be deferred until the deleted RRs 201 would next become visible, so long as the ``zone has changed'' 202 processing (see below) is done at the time of expiration (i.e., when the 203 automatic deletion is first deferred.) 205 Whenever automatic deletion occurs, the zone will be considered 206 ``changed'' for the purpose of automatic SOA SERIAL increment (see 207 [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). 209 3.5 - Requirements for Persistence 211 Stored deferred updates should persist across name server restarts. 213 3.5.1 - Restarts and Deferral 215 In the event of a name server restart, all deferred updates whose TUU 216 has expired must take effect before any network requests are processed 217 using data from the affected zone, and before any Expiry processing 218 takes place on RRs in the affected zone. 220 3.5.2 - Restarts and Expiry 222 In the event of a name server restart, all expiries must be checked as 223 of the current time before any network responses are generated using 224 data from the affected zone. 226 If an RR's expiry time has been reached while the name server was not 227 running, that RR will be deleted. Otherwise, the RR's TTL will be set 228 to one half of the time remaining before expiration, and half life 229 processing as specified in Section 3.4.2 will be restarted. 231 If any RR is deleted or if an RR's TTL is changed during startup, then 232 the zone will be considered ``changed'' for the purpose of automatic SOA 233 SERIAL increment (see [UPDATE 3.6]) and real time zone slave 234 notification (see [NOTIFY]). 236 4 - Requestor Behaviour 238 A requestor will generate and transmit a DEFUPD request as specified in 239 [UPDATE 4], except that TUU and TUE RRs can be included in the 240 Additional Data section. 242 4.1. The TUU RR, if specified, must have an owner name and class equal 243 to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to 244 the delay, measured in seconds, before this update should be processed 245 by the primary master. RDLENGTH should be set to 0, and RDATA should 246 therefore be empty. 248 4.2. The TUE RR, if specified, must have an owner name and class equal 249 to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to 250 the delay, measured in seconds, before all RRs added or changed by the 251 Update Section will be automatically deleted by the primary master. 252 This delay is measured starting from the time the update is applied, 253 which could follow a deferral delay if a TUU RR was also included in 254 this update. 256 5 - Notes on Resource Consumption 258 A TUE RR will require the primary master will initiate an automatic 259 update approximately O(log2(TTL)) times over the life of an expiring RR. 260 Even for massively sized zones, this is not considered an inappropriate 261 load on the primary master server itself. 263 The network bandwidth consumed due to the use of TUE RRs is more 264 noticeable, although for massively sized zones, the bandwidth 265 requirements should flatten somewhat as many RRs will be automatically 266 updated during any given cycle of NOTIFY and AXFR/IXFR. 268 6 - Security Considerations 270 This protocol suffers the same abject and intentional lack of security 271 as [UPDATE], from which it inherits its basic semantics. In the absence 272 of DNS Secure Updates, this protocol should not be used outside of an 273 enterprise network, and only with great care within an enterprise 274 network. 276 7 - Discussion Items for DNSIND and Namedroppers 278 Should the server's response to a DEFUPD include an opaque cookie called 279 a ``deferred update ID'' which could be used in future DEFUPD requests 280 to cancel or replace a previous deferred update? 282 Should automatic updates caused by a TUE RR be required to be batched up 283 and processed at some minimum interval? For example, if we only checked 284 for half life and expiration once per minute, this might drastically 285 reduce the number of NOTIFY/AXFR/IXFR cycles caused by any given zone. 286 We would have to recommend that all zones in a given server not be 287 synchronized to the same timer, lest a server with many zones cause all 288 of its zones to change and require NOTIFY/AXFR/IXFR in the same second. 290 Astute readers will have noticed that this proposal is a precise 291 superset of [UPDATE], and by adding the optional behaviour and 292 definitions of TUU and TUE to [UPDATE], we could do away with the 293 separate Opcode for DEFUPD. This was only possible up until the time 294 [UPDATE] went to proposed standard, but hopefully the intent was clear. 296 8 - References 298 [RFC1035] 299 P. Mockapetris, ``Domain Names - Implementation and Specification,'' 300 RFC 1035, USC/Information Sciences Institute, November 1987. 302 [IXFR] 303 M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February 304 1996, . 306 [NOTIFY] 307 P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,'' 308 Internet Draft, March 1996, . 310 [UPDATE] 311 P. Vixie (Ed), et al, ``Dynamic Updates in the Domain Name System,'' 312 Internet Draft, March 1996, . 314 [DHCP] 315 Y. Rechter, ``Interaction between DHCP and DNS,'' Internet Draft, 316 February 1996, . 318 9 - Acknowledgements 320 Yakov Rechter assisted in the design of this protocol. Robert Elz 321 assisted in the requirements definition. 323 10 - Author's Addresses 325 Paul Vixie 326 Internet Software Consortium 327 Star Route Box 159A 328 Woodside, CA 94062 329 +1 415 747 0204 330