idnits 2.17.1 draft-pusateri-dnsop-update-timeout-05.txt: -(177): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(178): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(179): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(193): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(194): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(195): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(196): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(201): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(202): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(204): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 20 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 May 2020) is 1438 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T.J. Pusateri 3 Internet-Draft T. Wattenberg 4 Intended status: Standards Track Unaffiliated 5 Expires: 10 November 2020 9 May 2020 7 DNS TIMEOUT Resource Record 8 draft-pusateri-dnsop-update-timeout-05 10 Abstract 12 This specification defines a new DNS TIMEOUT resource record (RR) 13 that associates a lifetime with one or more zone resource records. 14 It is intended to be used to transfer resource record lifetime state 15 between a zone's primary and secondary servers and to store lifetime 16 state during server software restarts. 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 10 November 2020. 35 Copyright Notice 37 Copyright (c) 2020 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 3. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 3 54 4. Common Usage Patterns . . . . . . . . . . . . . . . . . . . . 4 55 4.1. TIMEOUT records vs. Update Leases . . . . . . . . . . . . 5 56 4.2. Testing for TIMEOUT . . . . . . . . . . . . . . . . . . . 6 57 5. Resource Record Composition . . . . . . . . . . . . . . . . . 6 58 5.1. Represented Record Type . . . . . . . . . . . . . . . . . 6 59 5.2. Represented Record Count . . . . . . . . . . . . . . . . 7 60 5.3. Method Identifiers . . . . . . . . . . . . . . . . . . . 7 61 5.3.1. Method Identifier 0: NO METHOD . . . . . . . . . . . 8 62 5.3.2. Method Identifier 1: MD-SHA256-128 . . . . . . . . . 8 63 5.4. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. TIMEOUT RDATA Wire Format . . . . . . . . . . . . . . . . . . 9 65 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. Primary Server Behavior . . . . . . . . . . . . . . . . . 10 67 7.2. Secondary Server Behavior . . . . . . . . . . . . . . . . 11 68 8. TIMEOUT RDATA Presentation Format . . . . . . . . . . . . . . 11 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 12.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Appendix A. Example TIMEOUT resource records . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 DNS Update [RFC2136] provides a mechanism to dynamically add/remove 81 DNS resource records to/from a zone. When a resource record is 82 dynamically added, it remains in the zone until it is removed 83 manually or via a subsequent DNS Update. The context of a dynamic 84 update may provide lifetime hints for the updated records (such as 85 the EDNS(0) Update Lease option [I-D.sekar-dns-ul]), however, this 86 lifetime is not communicated to secondary servers and will not 87 necessarily endure through server software restarts. This 88 specification defines a new DNS TIMEOUT resource record that 89 associates lifetimes with one or more resource records with the same 90 owner name, type, and class that can be transferred to secondary 91 servers through normal AXFR [RFC5936], IXFR [RFC1995] transfer 92 mechanisms. 94 An UPDATE lifetime could be stored in a proprietary database on an 95 authoritative primary server but there is an advantage to saving it 96 as a resource record: redundant master servers and secondary servers 97 capable of taking over as the primary server for a zone automatically 98 can benefit from the existing database synchronization of resource 99 records. In addition, primary and secondary servers from multiple 100 vendors can synchronize the lifetimes through the open format 101 provided by a resource record. 103 TIMEOUT records can be installed via policy by a primary server, 104 manually, or via an external UPDATE from a client. If TIMEOUT 105 records are being managed by an UPDATE client, the client should be 106 aware of server software policy with respect to TIMEOUT records to 107 prevent the TIMEOUT records from being rejected. The primary server 108 has ultimate responsibility for the records in the database and the 109 client must work within the restrictions of the policy of the primary 110 server. 112 TIMEOUT records can be thought of as a universal method for removing 113 stale dynamic DNS records. Clients such as DHCP servers who best 114 know the lease lifetimes can include individual TIMEOUT records in 115 the dynamic UPDATE messages specific for each lease lifetime. These 116 TIMEOUT records can be refreshed when the lease is refreshed and will 117 timeout the A, AAAA, and PTR records if they are not refreshed by the 118 DHCP server. Additional use cases include service discovery resource 119 records installed in unicast DNS servers via UPDATE described in 120 [RFC6763], Active Directory Controllers publishing SRV records, DNS 121 TXT resource records supporting ACME certificate management 122 challenges as described in [RFC8555], Section 8.4, and the limited 123 lifetime certificate representations produced by ACME that are stored 124 in DANE TLSA resource records [RFC6698]. 126 2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. These words may also appear in this 133 document in lower case as plain English words, absent their normative 134 meanings. 136 3. Sources of TIMEOUT Expiry Time 138 The expire time may come from many different sources. A few are 139 listed here however, this list is not considered complete. TIMEOUT 140 records may be included along side the records they represent in the 141 UPDATE message or they be synthesized by the primary server receiving 142 the UPDATE. 144 * Via DHCP Lease Lifetimes. 146 * Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated in 147 DNS Update. 149 * Via an administrative default value such as one day (86400 150 seconds). 152 4. Common Usage Patterns 154 TIMEOUT resource records are just one tool in the toolbox for 155 cleaning up stale resource records. They provide a failsafe in case 156 other mechansims meant to clean up records fail. It might be useful 157 to think of them similar to Garbage Collection (GC) or Automatic 158 Reference Counting (ARC) used by programming languages for memory 159 management. The model in which the TIMEOUT resource records are used 160 depends on the support provided for them by the primary DNS server. 162 As it cannot be presumed that all primary authoritative servers will 163 manage TIMEOUT resource records internally, an external management of 164 the TIMEOUT records and the resource records they represent might be 165 necessary. The client may perform external management of TIMEOUT 166 records it creates through an UPDATE or a third party with 167 appropriate permission may manage the records. 169 If the primary server understands TIMEOUT records and manages them 170 based on resource record updates, it will likely know when to remove 171 the resource records referenced by the TIMEOUT records. This is 172 similar to ARC. 174 ┌─────────────┐ 175 │Client UPDATE│ 176 │ with EDNS0 │───┐ 177 └─────────────┘ │ ┌───────────────┐ 178 │ │ Primary │ Zone ┌─────────┐ 179 ┌────────────────┐ ├──▶│(Authoritative)│───Transfer──▶│Secondary│ 180 │ UPDATE with │ │ └───────────────┘ └─────────┘ 181 │TIMEOUT included│───┘ 182 └────────────────┘ 184 If the primary server does not understand TIMEOUT records, then an 185 external manager (client) will need to use DNS UPDATE to manage 186 TIMEOUT records and the resource records they reference. Garbage 187 Collectors run periodically looking for memory no longer being used 188 to reclaim. In a similar way, external TIMEOUT record managers need 189 to periodically scan the TIMEOUT records and send DNS UPDATE messages 190 to add/remove records when the server doesn't manage them 191 automatically. 193 ┌────────────────┐ ┌───────────────┐ 194 │ UPDATE with │ │ Primary │ Zone ┌─────────┐ 195 │TIMEOUT included│───────▶│(Authoritative)│───Transfer──▶│Secondary│ 196 └────────────────┘ └───────────────┘ └─────────┘ 197 │ ▲ 198 Zone │ 199 Transfer UPDATE 200 │ │ 201 ┌─────────────┐ ▼ │ 202 │Client UPDATE│ ┌───────────────┐ 203 │ with EDNS0 │───────▶│ timeoutd │ 204 └─────────────┘ └───────────────┘ 206 It should be noted that similar to many instances of Garbage 207 Collection, the precision with which TIMEOUT records and the resource 208 records they reference are removed is not critical. Gross timers 209 and/or scanning mechanisms are perfectly appropriate and should not 210 consume additional resources for the purpose of being precise. As 211 described in Section 5.4 below, expiry times use one second 212 resolution. 214 4.1. TIMEOUT records vs. Update Leases 216 Each application will have to determine when it is better to use 217 TIMEOUT resource records, EDNS(0) Update Lease options, or a 218 combination of the two. In some cases, either will serve the same 219 purpose. A differentiating factor is that TIMEOUT resource records 220 use absolute time so that the records may be more easily synchronized 221 across secondary servers whereas Update Leases are specified in 222 relative time offsets. 224 If your primary DNS server supports TIMEOUT records directly, it may 225 be simpler to just provide an Update Lease lifetime in the DNS UPDATE 226 message that the server will use to create the TIMEOUT records 227 internally. If your primary DNS server does not support TIMEOUT 228 records and your application uses sources that have real-time clocks 229 that are synchronized with standard time sources, TIMEOUT records are 230 an available option to the client. However, if your clients are 231 using low-cost hardware without real-time clocks, they should send 232 Update Leases to the primary server or an intermediate proxy with a 233 synchronized real-time clock. 235 4.2. Testing for TIMEOUT 237 There is no more reliable mechanism to determine if the primary DNS 238 server supports the management of TIMEOUT records than explicitly 239 trying it. Before relying on a server to expire TIMEOUT records, the 240 application should send test records and test if they are handled as 241 expected. If the preferred mode of operation is not supported, 242 another mode can be attempted. For example, if sending a DNS UPDATE 243 with a EDNS(0) Update Lease of 1 second doesn't cause the record to 244 be expired within 6 seconds (1 + 5 fuzz), then the application can 245 try including a TIMEOUT record in the DNS UPDATE. If that doesn't 246 automatically expire, TIMEOUT records will need to be managed 247 externally. 249 5. Resource Record Composition 251 TIMEOUT resource records provide expiry times for a mixed variety of 252 resource record types with the same owner name, type, and class. 253 Since there could exist multiple records of the same record type with 254 the same owner name and class, the TIMEOUT resource record must be 255 able to identify each of these records individually with only 256 different RDATA. As an example, PTR records for service discovery 257 [RFC6763] provide a level of indirection to SRV and TXT records by 258 instance name. The instance name is stored in the PTR RDATA and 259 multiple PTR records with the same owner name and only differing 260 RDATA often exist. 262 In order to distinguish each individual record with potentially 263 different expiry times, the TIMEOUT resource record contains an 264 expiry time, the record type, a method to identify the actual records 265 for which the expiry time applies, and a count of the number of 266 records represented. Multiple TIMEOUT records with the same owner 267 name and class are created for each expiry time, record type, and 268 resource record representation. If the expiry time is the same, 269 multiple records can be combined into a single TIMEOUT record with 270 the same owner name, class, and record type but this is not required. 272 The fields and their values in a TIMEOUT record are defined as: 274 5.1. Represented Record Type 276 A 16-bit field containing the resource record type to which the 277 TIMEOUT record applies. Multiple TIMEOUT records for the same owner 278 name, class, and represented type can exist. Any resource record 279 type can be specified in the Represented Record Type including 280 another TIMEOUT record. This specification does not put any 281 restrictions on the record type but implementations in authoritative 282 servers will likely do so for policy and security reasons. 284 QTYPEs and Meta-TYPEs MUST NOT be used as the represented record 285 type. For more information, refer to [RFC6895], Section 3.1. 287 5.2. Represented Record Count 289 The Represented Record Count is a 8-bit value that specifies the 290 number of records of the specified record type with this expiry time. 292 A count of zero indicates that it is not necessary to represent any 293 records in the list. This is a shortcut notation meaning all 294 resource records with the same owner name, class, and record type use 295 the same Expiry Time. When the Represented Record Count is 0, the 296 Method Identifer is set to NO METHOD (0) on transmission and ignored 297 on reception. A primary server MUST NOT install a TIMEOUT record 298 with No Method/No Count at the same time that a TIMEOUT record exists 299 for the same owner name, class, and type with a non-zero record 300 count. Either all records MUST match the No Method/No Count 301 shorthand syntax or they MUST all be included in the list of matching 302 records. 304 In the unlikely event that the Represented Record Count exceeds 255 305 which is the largest number representable in 8 bits, multiple 306 instances of the same Expiry Time can exist. 308 5.3. Method Identifiers 310 The Method Identifier is a 8-bit value that specifies an identifier 311 for the algorithm used to distinguish between resource records. The 312 identifiers are declared in a registry maintained by IANA for the 313 purpose of listing acceptable methods for this purpose. In addition 314 to the method and the index, the registry MAY contain a fixed output 315 length in bits of the method to be used or the term "variable" to 316 denote a variable length output per record. It is conceivable, 317 though not likely, that the same method could be used with different 318 fixed output lengths. In this case, each fixed output length would 319 require a different identifier in the registry. Additions to this 320 registry will be approved with additional documentation under expert 321 review. At the time that the registry is created by IANA, a group of 322 expert reviewers will be established. 324 Additional methods of representing records may be defined in the 325 future. If such methods are defined, a primary server could create 326 TIMEOUT record using a new method that is not understood by a 327 secondary server that could take over as the primary in the event of 328 an outage or administrative change. In this case, the new primary 329 would not be able to identify the records it is supposed to TIMEOUT. 330 This is a misconfiguration and it is the responsibility of the 331 administrator to ensure that secondary servers in a position to 332 become primary understand the TIMEOUT record methods of the primary 333 server. 335 5.3.1. Method Identifier 0: NO METHOD 337 The method identifier of 0 is defined as "NO METHOD" and MUST NOT be 338 used if the represented record count is greater than 0. The value of 339 0 is to be included in the IANA registry of method identifier values. 341 5.3.2. Method Identifier 1: MD-SHA256-128 343 The method identifier of 1 is defined as "MD-SHA256-128". Following 344 the expiry time is a list of 128-bit values. Each of these values is 345 the first 128-bits of a message digest of the RDATA of a represented 346 record in canonical DNSSEC form calculated using the 256-bit SHA-256 347 hash algorithm defined in [FIPS180-4]. The canonical DNSSEC form is 348 described in [RFC4034], Section 6. The input length of RDATA for the 349 message digest is the RDLEN of the represented record. 351 5.4. Expiry Time 353 The expiry time is a 64-bit number expressed as the number of seconds 354 since the UNIX epoch (00:00:00 UTC on January 1, 1970). This value 355 is an absolute time at which the record will expire. An absolute 356 time is necessary so the TIMEOUT records do not have to change during 357 zone transfers. 359 There are circumstances when a relative expiry time would be 360 convenient due to limited resources for clock synchronization in 361 constrained devices. In this case, DNS UPDATE messages should not 362 contain precomputed TIMEOUT records but convey the relative expiry 363 time using the EDNS(0) Update Lease Option defined in 364 [I-D.sekar-dns-ul]. The relative time is then converted to an 365 absolute expiry time when received by the primary server which will 366 create the TIMEOUT resource records. 368 6. TIMEOUT RDATA Wire Format 370 The TIMEOUT resource record follows the same pattern as other DNS 371 resource records including owner name, type, class, TTL, RDATA 372 length, and RDATA as defined in [RFC1035], Section 3.2.1. 374 The RDATA section of the resource record with method identifier NO 375 METHOD (0) is illustrated in Figure 1: 377 0 1 2 3 378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Represented RR Type | Count (0) | Method (0) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Expiry Time (64-bit) | 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 1: Method (0) RDATA Wire Format 388 Figure 1 represents the TIMEOUT RDATA field of all matching records 389 of the represented type for the same owner name and class. 391 The RDATA section of the resource record with method identifier MD- 392 SHA256-128 (1) is illustrated in Figure 2: 394 0 1 2 3 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Represented RR Type | Count (n) | Method (1) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Expiry Time (64-bit) | 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 | First 128 bits of SHA256 hash | 404 | of Represented Record 1 RDATA | 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 . . 408 . . 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 411 | First 128 bits of SHA256 hash | 412 | of Represented Record n RDATA | 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 2: Method (1) MD-SHA256-128 Wire Format 418 Figure 2 represents an arbitrary number of represented records with 419 the same owner name, class, and represented type. For each expiry 420 time, a list of the first 128-bits of a SHA256 hash are appended. 422 7. Server Behavior 424 A server may or may not understand TIMEOUT resource records. If a 425 server does not understand them, they are treated like any other 426 resource record that the server may not understand. See [RFC3597] 427 for more information. 429 7.1. Primary Server Behavior 431 The primary server is the ultimate source of the database and 432 policies established by the server may overrule the actions of 433 external clients. The primary server is ultimately responsible for 434 ensuring the database is consistent but until TIMEOUT record 435 management is built-in to authoritative server software, external 436 UPDATE clients will likely manage the records. 438 Upon receiving any DNS UPDATE deleting resource records that might 439 have been covered by a TIMEOUT RR, a primary server MUST remove all 440 represented records in all of the TIMEOUT records with the same owner 441 name, class, and represented type. 443 A TIMEOUT resource record MUST be removed when the last resource 444 record it covers has been removed. This may be due to the record 445 expiring (reaching the expiry time) or due to a subsequent DNS Update 446 or administrative action. 448 The TIMEOUT record TTL should use the default TTL for the zone like 449 any other record. The TTL values of the records covered by a TIMEOUT 450 are not affected by the TIMEOUT expiry time and may be longer than 451 the expiry time. The TIMEOUT RR is mostly for the benefit of the 452 authoritative server to know when to remove the records. The fact 453 that some records might live longer in the cache of a resolver is no 454 different than other records that might get removed while still in a 455 remote resolver cache. 457 7.2. Secondary Server Behavior 459 A secondary server MUST NOT expire the records in a zone it maintains 460 covered by the TIMEOUT resource record and it MUST NOT expire the 461 TIMEOUT resource record itself when the last record it covers has 462 expired. The secondary server MUST always wait for the records to be 463 removed or updated by the primary server. 465 8. TIMEOUT RDATA Presentation Format 467 Record Type: 468 resource record type mnemonics. When the mnemonic is unknown, 469 the TYPE is represented by the word "TYPE" immediately followed 470 by the decimal RR type number, with no intervening whitespace 471 as described in [RFC3597], Section 5 473 Represented Record Count: 474 unsigned decimal integer (0-255) 476 Method Identifier: 477 unsigned decimal integer (0-255) 479 Expiry Time: 480 The Expiry Time is displayed as a compact numeric-only 481 representation of ISO 8601. All punctuation is removed. This 482 form is slightly different than the recommendation in [RFC3339] 483 but is common for DNS protocols. It is defined in [RFC4034], 484 Section 3.2 as YYYYMMDDHHmmSS in UTC. This form will always be 485 exactly 14 digits since no component is optional. 487 YYYY is the year; 489 MM is the month number (01-12); 491 DD is the day of the month (01-31); 493 HH is the hour, in 24 hour notation (00-23); 495 mm is the minute (00-59); and 497 SS is the second (00-60) where 60 is only possible as a leap 498 second. 500 List of 0 or more hashes depending on Method Identifier: 501 ( hash-1 hash2 ... ) 503 hash values shown as upper case hexadecimal string; 505 some type of white space MUST exist between hash values but 506 MUST NOT exist within hash value; 508 MUST only display parentheses for one or more hash values; 510 9. IANA Considerations 512 This document defines a new DNS Resource Record Type named TIMEOUT to 513 be exchanged between authoritative primary and secondary DNS servers. 514 It is assigned out of the DNS Parameters Resource Record (RR) Type 515 registry. The value for the TIMEOUT resource record type is TBA. 517 +---------+-------+----------------------------+------------+ 518 | Type | Value | Meaning | Definition | 519 +=========+=======+============================+============+ 520 | TIMEOUT | TBA | expire represented records | Section 5 | 521 +---------+-------+----------------------------+------------+ 523 Table 1: DNS Parameters Resource Record Registry 525 This document establishes a new registry of DNS TIMEOUT Resource 526 Record Method Identifier values. The registry shall include a 527 numeric identifier, a method name, a description of the method, and 528 the length of the output function in bits or the keyword "variable". 529 The identifier is to be used in the RDATA section of the TIMEOUT 530 resource record. 532 Initially, there are two values defined in the registry. Values from 533 240 (0xF0) through 255 (0xFF) are reserved for experimental use. 535 +---------+---------------+----------------+----------+------------+ 536 | ID | Method Name | Description | Length | Definition | 537 | | | | (bits) | | 538 +=========+===============+================+==========+============+ 539 | 0 | NO METHOD | All records | 0 | Section | 540 | | | match | | 5.3.1 | 541 +---------+---------------+----------------+----------+------------+ 542 | 1 | MD-SHA256-128 | List of | 128 bits | Section | 543 | | | 128-bit hashes | | 5.3.2 | 544 | | | of represented | | | 545 | | | records RDATA | | | 546 +---------+---------------+----------------+----------+------------+ 547 | 240-255 | EXPERIMENTAL | Reserved for | variable | Section 9 | 548 | | | Experimental | | | 549 | | | Use | | | 550 +---------+---------------+----------------+----------+------------+ 552 Table 2: TIMEOUT RR Method Identifier values 554 10. Security Considerations 556 There is no secure relationship between a TIMEOUT resource record and 557 the represented resource records it applies to. TIMEOUT records 558 should typically only apply to resource records created through the 559 UPDATE mechanism. Protection for permanent resource records in a 560 zone is advisable. 562 Authenticated UPDATE operations MUST be REQUIRED at authoritative 563 name servers supporting TIMEOUT resource records. 565 11. Acknowledgments 567 This idea was motivated through conversations with Mark Andrews. 568 Thanks to Mark as well as Paul Vixie, Joe Abley, Ted Lemon, Tony 569 Finch, Robert Story, Paul Wouters, Dick Franks, JINMEI, Tatuya, 570 Timothe Litt, and Stuart Cheshire for their suggestions, review, and 571 comments. 573 12. References 575 12.1. Normative References 577 [FIPS180-4] 578 National Institute of Standards and Technology, U.S. 579 Department of Commerce, "Secure Hash Standard (SHS) FIPS 580 180-4", August 2015, 581 . 584 [RFC1035] Mockapetris, P., "Domain names - implementation and 585 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 586 November 1987, . 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 594 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 595 . 597 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 598 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 599 2003, . 601 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 602 Rose, "Resource Records for the DNS Security Extensions", 603 RFC 4034, DOI 10.17487/RFC4034, March 2005, 604 . 606 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 607 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 608 April 2013, . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 12.2. Informative References 616 [I-D.sekar-dns-ul] 617 Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", 618 Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 619 August 2018, 620 . 622 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 623 DOI 10.17487/RFC1995, August 1996, 624 . 626 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 627 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 628 RFC 2136, DOI 10.17487/RFC2136, April 1997, 629 . 631 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 632 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 633 . 635 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 636 of Named Entities (DANE) Transport Layer Security (TLS) 637 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 638 2012, . 640 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 641 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 642 . 644 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 645 Kasten, "Automatic Certificate Management Environment 646 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 647 . 649 Appendix A. Example TIMEOUT resource records 651 The following example shows sample TIMEOUT resource records based on 652 DNS UPDATEs containing A and AAAA address records plus the 653 corresponding PTR records. 655 A host sending a name registration at time Tn for "A" and "AAAA" 656 records with lease lifetime Ln would have a series of UPDATEs (one 657 for each zone) that contain: 659 +---------------------------------------------+----+----------------+ 660 | Name | RR | Value | 661 | |Type| | 662 +=============================================+====+================+ 663 | s.example.com. | A | 192.0.2.5 | 664 +---------------------------------------------+----+----------------+ 665 | s.example.com. |AAAA| 2001:db8::5 | 666 +---------------------------------------------+----+----------------+ 667 | 5.2.0.192.in-addr.arpa. |PTR | s.example.com. | 668 +---------------------------------------------+----+----------------+ 669 | 5.0.0.0.0.0.0.0.0.0.0.0.b8.d.1.20.ip6.arpa. |PTR | s.example.com. | 670 +---------------------------------------------+----+----------------+ 672 Table 3: Example Address Records Update 674 Next, consider the TIMEOUT resource records that would be generated 675 for the records in Table 3. 677 +---------------------------------------------+----+---+---+--------+ 678 | Owner Name |Type|Cnt|Mth| Expire | 679 +=============================================+====+===+===+========+ 680 | s.example.com. | A | 0 | 0 | Tn+Ln | 681 +---------------------------------------------+----+---+---+--------+ 682 | s.example.com. |AAAA| 0 | 0 | Tn+Ln | 683 +---------------------------------------------+----+---+---+--------+ 684 | 5.2.0.192.in-addr.arpa. |PTR | 0 | 0 | Tn+Ln | 685 +---------------------------------------------+----+---+---+--------+ 686 | 5.0.0.0.0.0.0.0.0.0.0.0.b8.d.1.20.ip6.arpa. |PTR | 0 | 0 | Tn+Ln | 687 +---------------------------------------------+----+---+---+--------+ 689 Table 4: Address TIMEOUT records 691 Next, assume there are two hosts advertising the same service type 692 (different service types will have different owner names). We will 693 use _ipp._tcp.example.com as an example. 695 Host A sends an UPDATE at time Ta with lease life La for PTR, SRV, A, 696 AAAA, and TXT records. Host B sends an UPDATE at time Tb with lease 697 life Lb for PTR, SRV, A, and TXT records. 699 +---------------------------+---------+---------------------------+ 700 | Owner name | RR Type | Value | 701 +===========================+=========+===========================+ 702 | _ipp._tcp.example.com. | PTR | p1._ipp._tcp.example.com. | 703 +---------------------------+---------+---------------------------+ 704 | p1._ipp._tcp.example.com. | SRV | 0 0 631 p1.example.com. | 705 +---------------------------+---------+---------------------------+ 706 | p1._ipp._tcp.example.com. | TXT | paper=A4 | 707 +---------------------------+---------+---------------------------+ 708 | p1.example.com. | A | 192.0.2.1 | 709 +---------------------------+---------+---------------------------+ 710 | p1.example.com. | AAAA | 2001:db8::1 | 711 +---------------------------+---------+---------------------------+ 713 Table 5: DNS UPDATE from Host A 715 +---------------------------+---------+---------------------------+ 716 | Owner name | RR Type | Value | 717 +===========================+=========+===========================+ 718 | _ipp._tcp.example.com. | PTR | p2._ipp._tcp.example.com. | 719 +---------------------------+---------+---------------------------+ 720 | p2._ipp._tcp.example.com. | SRV | 0 0 631 p2.example.com. | 721 +---------------------------+---------+---------------------------+ 722 | p2._ipp._tcp.example.com. | TXT | paper=B4 | 723 +---------------------------+---------+---------------------------+ 724 | p2.example.com. | A | 192.0.2.2 | 725 +---------------------------+---------+---------------------------+ 727 Table 6: DNS UPDATE from Host B 729 For these printer registrations, the TIMEOUT records on the server 730 would look like the following: 732 +-------------------------+----+-+-+--------------------------------+ 733 | Owner Name |Type|C|M| Expire / Hash | 734 +=========================+====+=+=+================================+ 735 | _ipp.tcp.example.com. |PTR |1|1| Ta+La | 736 | | | | |69D67BCB98E8809702B9DFCA6B865558| 737 +-------------------------+----+-+-+--------------------------------+ 738 | _ipp.tcp.example.com. |PTR |1|1| Tb+Lb | 739 | | | | |7EBE34BC8B3E7306F8FCF1D6805331E1| 740 +-------------------------+----+-+-+--------------------------------+ 741 |p1._ipp._tcp.example.com.|SRV |0|0| Ta + La | 742 +-------------------------+----+-+-+--------------------------------+ 743 |p1._ipp._tcp.example.com.|TXT |0|0| Ta + La | 744 +-------------------------+----+-+-+--------------------------------+ 745 |p2._ipp._tcp.example.com.|SRV |0|0| Tb + Lb | 746 +-------------------------+----+-+-+--------------------------------+ 747 |p2._ipp._tcp.example.com.|TXT |0|0| Tb + Lb | 748 +-------------------------+----+-+-+--------------------------------+ 749 | p1.example.com. | A |0|0| Ta + La | 750 +-------------------------+----+-+-+--------------------------------+ 751 | p1.example.com. |AAAA|0|0| Ta + La | 752 +-------------------------+----+-+-+--------------------------------+ 753 | p2.example.com. | A |0|0| Tb + Lb | 754 +-------------------------+----+-+-+--------------------------------+ 756 Table 7: Service TIMEOUT records 758 Authors' Addresses 759 Tom Pusateri 760 Unaffiliated 761 Raleigh, NC 762 United States of America 764 Email: pusateri@bangj.com 766 Tim Wattenberg 767 Unaffiliated 768 Cologne 769 Germany 771 Email: mail@timwattenberg.de