idnits 2.17.1 draft-ietf-dnsind-expires-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-25) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 323 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 55 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [7,8], [8], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 204 has weird spacing: '...rds for host ...' -- 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 (February 1996) is 10297 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) -- Looks like a reference, but probably isn't: 'TBD' on line 270 == Unused Reference: '3' is defined on line 278, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 284, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 287, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 296, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 299, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 301, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1536 (ref. '3') ** Obsolete normative reference: RFC 1348 (ref. '4') (Obsoleted by RFC 1637) ** Downref: Normative reference to an Experimental RFC: RFC 1183 (ref. '5') ** Downref: Normative reference to an Unknown state RFC: RFC 1101 (ref. '6') ** Downref: Normative reference to an Unknown state RFC: RFC 1033 (ref. '9') ** Downref: Normative reference to an Unknown state RFC: RFC 1032 (ref. '10') ** Obsolete normative reference: RFC 974 (ref. '11') (Obsoleted by RFC 2821) Summary: 18 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. A. Patton 3 Expiration Date: July 1996 BBN 4 February 1996 6 Scheduled Expiration of DNS Resource Records 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ds.internic.net (US East Coast), 24 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 25 munnari.oz.au (Pacific Rim). 27 This Internet Draft expires July 1996. 29 [[[Global issues for entire draft: 30 Draft as written expires all RRs of a type together. This 31 seems to be reasonable given some other discussions, 32 but may be controversial. Since my inclination was 33 towards treating a whole RR set the same already and I 34 couldn't figure out a good way to be more fine-grained, 35 I felt it was useful to do it this way, at least to 36 start. For all these reasons, I will leave it as is, 37 unless someone comes up with a compelling reason for 38 it, AND a good design for how to do it. 39 Do we need to expire CNAMES? Can't put an EXP there...unless 40 we make EXP an exception to that rule. I think the 41 DNSsec does this for SIGs...just extend that exemption? 42 Should the SOA serial be updated when records expire? I think 43 the same words that are in the DynDNS draft should be 44 put here... Problem is that this can happen in both 45 primary and secondary servers. 46 Interaction with Dynamic Update. Do expired RRs appear to be 47 there or not for the conditioning section of an 48 update. May want them to appear to be there for 49 several reasons 1) they need to be deleted for real 50 (maybe); 2) may be trying to replace just around time 51 of expire and not having them is a race condition; and 52 3) may have been used in conditioning because a recent 53 query showed it there. On the other hand, these may 54 want to be really gone once expired, because they're 55 no longer visible to queries and therefore updates may 56 assume they don't exist and say that in the conditional 57 part... 58 Should anything be said about expiring EXP RRs? This draft 59 lets you do it, which can result in odd behaviour. On 60 the other hand, I don't see why outlawing it is really 61 needed (maybe someone will come up with a good use for 62 this "feature"). 63 ]]] 65 Abstract 67 This document describes an additional RR type for the Domain Name 68 System[7,8] which provides for scheduled expiration of RRs in the 69 DNS. These RRs record the time at which a referenced set of RRs 70 are to be removed from the DNS. This can be used to provide the 71 information required to automatically support the reduced TTLs 72 described in RFC1034[8] when anticipating a change, and by being in 73 the zone data, will communicate that information to other servers 74 that recognize the RR, in particular, secondary servers that 75 recieve the data by Zone Transfer (AXFR or IXFR[2]). 77 Introduction 79 Several people have noted that the SIG RR from the DNS Security 80 Extensions[1] can be used to enable the TTL count down and 81 automatic deletion of RRs. This is a feature that has been 82 discussed widely at times on various DNS related mailing lists. To 83 allow this use of SIG RRs without the requirement for cryptography, 84 the NULL SIG RR was introduced. 86 In the later stages of development of the DNSsec draft, some 87 concerns were raised by the security people at having a "Security" 88 RR that, in fact, offered no security. The EXP RR described here 89 is offered as an alternative to using NULL SIG RRs for TTL count 90 down and automatic deletion of RRs. 92 This document is an attempt to focus the alternative and get some 93 experience with this approach before the DNSsec goes from Proposed 94 to Draft. At that stage, if the NULL SIG RR has achieved enough 95 deployment and no problems with its use are found, it may be 96 retained. On the other hand, if it does not get used, or has 97 problems, it can be dropped and the slack taken up by the RR 98 described here. 100 There are some proponents of this option who would like to see this 101 RR even if the NULL SIG is retained. If the DNSsec goes forward 102 with support behind the NULL SIG, but there is nonetheless support 103 (in terms of implementation and deployment experience) for the EXP 104 RR, it can go forward independantly. 106 [[[I think more should be said, but that's about all I'm good for 107 at this time. If others want to try their hand at inroductory and 108 justification text, I'd be happy to incorporate it...]]] 110 1. definition of the RR type 112 The Expires RR is defined with mnemonic "EXP" and TYPE code 113 [[[TBD]]] (decimal). The format is based slightly on the format 114 used for the SIG RR in the DNS Security Extensions[1] 116 The format of an Expires (EXP) RR is: 118 1 1 1 1 1 1 119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 120 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 121 | | 122 / / 123 / NAME / 124 | | 125 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 126 | TYPE = EXP | 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 128 | CLASS = IN | 129 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 130 | TTL | 131 | | 132 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 133 | RDLENGTH | 134 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 135 | COVERS | 136 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 137 | TIME | 138 | | 139 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 141 where: 143 * NAME: an owner name, i.e., the name of the DNS node to which this 144 resource record pertains. This is encoded as described in 145 RFC1035 sections 3.1 and 4.1.4 and may be any number of octets. 147 * TYPE: two octets containing the EXP RR TYPE code of 31 (decimal). 149 * CLASS: two octets containing the RR IN CLASS code of 1. 151 * TTL: a 32 bit signed integer that specifies the time interval in 152 seconds that the resource record may be cached before the source 153 of the information should again be consulted. 155 * RDLENGTH: 6 157 * COVERS: is the type code of the RR set that it covers or 255 to 158 indicate that it applies to all RRs of the same name and class. 159 This is a subset of the QTYPE defined in RFC1035. 161 * TIME: The date and time that the referenced RRs are due to 162 expire, represented as an unsigned number of seconds since the 163 start of 1 January 1970, GMT, ignoring leap seconds. 165 [[[It's been suggested to add an "Effective on" time or function. 166 If that's desired by anyone, my temptation is to make it separate. 167 For this to be useful, it (and EXP) would really need to apply to 168 specific RRs rather than a whole RR set. This makes it hard. For 169 all these reasons, I will leave it out, unless someone comes up 170 with a compelling reason for it, AND a good design for how to do 171 it. My inclination is that this should be done with something like 172 adding an EXP, then at the "effective time" doing a DYNDNS update 173 removing the EXP and the RRs it covers and adding the new ones. 174 This probably requires that the expired RRs appear to be there 175 whether they've expired or not for the purposes of update, but they 176 may not be visible to queries, can we make this reasonable.]]] 178 2. Master File Format 180 The format of EXP RRs follows all the rules of RFC 1035, 181 Section 5, "Master Files." 183 Example master file (based on the example in RFC1035): 185 @ IN SOA VENERA Action.domains ( 186 20 ; SERIAL 187 7200 ; REFRESH 188 600 ; RETRY 189 3600000; EXPIRE 190 60) ; MINIMUM 192 NS A.ISI.EDU. 193 NS VENERA 194 NS VAXA 195 MX 10 VENERA 196 MX 20 VAXA 198 ; address record for host A is good until 8am, 1 Jan 1996 199 A A 26.3.0.103 200 EXP A 19960101080000 202 VENERA A 10.1.0.52 203 A 128.9.0.32 204 ; all address records for host VENERA are good until midnight, 31 May 1996 205 EXP A 19960531000000 207 ; no expiration for VAXA's addresses 208 VAXA A 10.2.0.27 209 A 128.9.0.33 211 3. Handling of Expires RRs and RRS covered by them 213 When an authoritative server [[[is this limitation good? bad? 214 other?]]] returns any RR covered by an Expires RR, it must assure 215 that the TTL is small enough that copies will not be cached beyond 216 the given expiration time. 218 Although the server does not need to actually remove expired RRs 219 from its database, it must give the appearance of having done so when 220 formulating replies to query or transfer requests. A simple algorithm 221 for skipping over expired RRs or adjusting their TTL to match an 222 expiration time is shown below: 224 if expire > now { 225 if (expire - now) > TTL { 226 TTL = (expire - now) 227 } 228 include RR in reply 229 } 231 This algorithm makes the TTL just small enough to satisfy the EXP 232 requirements. Some people have suggested more elaborate techniques 233 to reduce the inherent inconsistencies introduced. Such an 234 algorithm might be to use a two day TTL when the change is more 235 than a week away, but a week ahead, start lowering the TTL such 236 that 3 days before the change only 1 day TTLs are given out, and a 237 day in advance it's down to a few hours, and a few hours in advance 238 it's down to 30 minutes. The usefulness of this more gradual 239 approach has been debated [[[do I have any references on this 240 discussion???]]], but in any case it is a local matter as long as 241 the TTL does not exceed that given by the simple algorithm above. 243 4. Additional Section Processing 245 [[[Do we need this?]]] 246 [[[Maybe suggest including them when they apply? Probably not useful.]]] 248 5. Acknowledgements 250 The original arguments for this as a separate RR were put forward 251 by Robert Elz in the DNSIND Working Group. Many others described 252 uses and requirements that were the basis of this design. Comments 253 and some explanatory text from Walt Lazear were helpful. 255 I'd also like to thank Arnt Gulbrandsen for his collected list of 256 DNS RFCs and permission to use it as the basis for the References 257 section and Bill Manning, the author of RFC1348[4], for unwittingly 258 supplying the boilerplate and diagrams I used as a basis for this 259 document. Much of the layout of the RR was based on the work of 260 Donald Eastlake and Charles Kaufman in the design of the DNS 261 Security Extensions. 263 6. Security Considerations 265 Security issues are not [[[yet]]] discussed in this memo. 266 [[[Should any be???]]] 267 [[[ EXP allows add permission to be turned into delete 268 permission]]] 269 [[[ interaction with DNSSEC, which has a different variant of 270 expiration, and with secure update[TBD]. ]]] 272 7. References 274 [1] DNSsec draft [[[fill in details]]] 276 [2] IXFR draft [[[fill in details]]] 278 [3] RFC 1536: A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller, 279 "Common DNS Implementation Errors and Suggested Fixes.", 280 10/06/1993. 282 [4] RFC 1348: B. Manning, "DNS NSAP RRs", 07/01/1992. 284 [5] RFC 1183: R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart, 285 "New DNS RR Definitions", 10/08/1990. 287 [6] RFC 1101: P. Mockapetris, "DNS encoding of network names and 288 other types", 04/01/1989. 290 [7] RFC 1035: P. Mockapetris, "Domain names - implementation and 291 specification", 11/01/1987. 293 [8] RFC 1034: P. Mockapetris, "Domain names - concepts and 294 facilities", 11/01/1987. 296 [9] RFC 1033: M. Lottor, "Domain administrators operations guide", 297 11/01/1987. 299 [10] RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987. 301 [11] RFC 974: C. Partridge, "Mail routing and the domain system", 302 01/01/1986. 304 8. Authors' Address: 306 Michael A. Patton 307 Bolt Beranek and Newman 308 10 Moulton Street 309 Cambridge, MA, 02138 311 Phone: (617) 873 2737 312 FAX: (617) 873 3457 313 Email: map@bbn.com 315 This Internet Draft expires July 1996