idnits 2.17.1 draft-pusateri-dnsop-update-timeout-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 23, 2018) is 2072 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. 'SHA3' == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Pusateri 3 Internet-Draft T. Wattenberg 4 Intended status: Standards Track Unaffiliated 5 Expires: February 24, 2019 August 23, 2018 7 DNS TIMEOUT Resource Record 8 draft-pusateri-dnsop-update-timeout-00 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 with the same owner name and class. It is intended to be used to 15 transfer resource record lifetime state between a zone's primary and 16 secondary servers and to store lifetime state during server software 17 restarts. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 24, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 55 2. TIMEOUT Resource Record Properties . . . . . . . . . . . . . 3 56 3. Secondary Server Behavior . . . . . . . . . . . . . . . . . . 3 57 4. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 4 58 5. Resource Record Composition . . . . . . . . . . . . . . . . . 4 59 5.1. Hash Count . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.2. Hash Algorithm Index . . . . . . . . . . . . . . . . . . 5 61 5.3. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.4. Cryptographic Hashes . . . . . . . . . . . . . . . . . . 6 63 6. Cryptographic Hash Requirements . . . . . . . . . . . . . . . 6 64 6.1. REQUIRED Cryptographic Hash Algorithm . . . . . . . . . . 6 65 7. TIMEOUT RR RDATA Wire Format . . . . . . . . . . . . . . . . 6 66 8. TIMEOUT RR RDATA Presentation Format . . . . . . . . . . . . 8 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 12.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 DNS Update [RFC2136] provides a mechanism to dynamically add/remove 78 DNS resource records to/from a zone. When a resource record is 79 dynamically added, it remains in the zone until it is removed 80 manually or via a subsequent DNS Update. A zone administrator may 81 want to enforce a default lifetime for dynamic updates (such as the 82 DHCP lease lifetime) or the DNS Update may contain a lifetime using 83 an EDNS(0) Update Lease option [I-D.sekar-dns-ul]. This lease 84 lifetime is not communicated to secondary servers and will not endure 85 through server software restarts. This specification defines a new 86 DNS TIMEOUT resource record that associates a lifetime with one or 87 more resource records with the same owner name and class that can be 88 transferred to secondary servers through normal AXFR [RFC5936], IXFR 89 [RFC1995] transfer mechanisms. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. TIMEOUT Resource Record Properties 99 TIMEOUT resource records have different properties than normal DNS 100 resource records. 102 1. TIMEOUT resource records are only defined for CLASS IN. 104 2. TIMEOUT resource records are only for administrative use and they 105 cannot be directly queried via the normal DNS request/response 106 query mechanism. Valid requests for TIMEOUT resource record 107 types MUST return responses with an NOERROR RCODE and an ANSWER 108 COUNT of zero. 110 3. TIMEOUT resource records are not automatically sent in AXFR, IXFR 111 zone transfer requests. Both primary and secondary servers 112 should be configured on a per zone basis to transfer TIMEOUT 113 resource records to ensure they are supported. 115 4. TIMEOUT resource records are not considered for 116 DNSSEC/NSEC/NSEC3/NSEC5 record construction. 118 5. TIMEOUT resource records cannot be directly added, modified, or 119 deleted through DNS Update. 121 6. A TIMEOUT resource record MUST be removed when the last resource 122 record it covers has been removed. This may be due to the record 123 expiring (reaching the expiry time) or due to a subsequent DNS 124 Update or administrative action. 126 3. Secondary Server Behavior 128 A secondary server may or may not understand TIMEOUT resource 129 records. The primary server should not be configured to send TIMEOUT 130 resource records if the secondary server does not understand them. 131 However, if TIMEOUT resource records are mistakenly transferred to a 132 server that does not understand them, they are treated like any other 133 resource record that the server may not understand [RFC3597]. 135 A secondary server that does understand the TIMEOUT resource records 136 it receives in a transfer MUST abide by the properties of the 137 resource record type defined in Section 2. 139 A secondary server will independently expire the records in a zone it 140 maintains covered by the TIMEOUT resource record as well as expire 141 the TIMEOUT resource record itself when the last record it covers has 142 expired in the same manner that a primary server would. 144 If a TIMEOUT resource record is removed from a subsequent zone 145 transfer, the secondary server MUST also remove it from its zone 146 database regardless of the expiry time. 148 4. Sources of TIMEOUT Expiry Time 150 The expire time may come from many different sources. A few are 151 listed here however, this list is not considered complete. 153 1. Via DHCP Dynamic Lease Lifetime communicated out of band. 155 2. Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated 156 in DNS Update. 158 3. Via an administrative default server value such as one day (86400 159 seconds). 161 5. Resource Record Composition 163 The TIMEOUT resource record must provide expiry times for a mixed 164 variety of resource record types with the same owner name and class. 165 Since there could exist multiple records of the same record type with 166 the same owner name and class, the TIMEOUT resource record must be 167 able to identify each of these records individually with only 168 different RDATA. As an example, PTR records for service discovery 169 provide a level of indirection to SRV and TXT records by instance 170 name. The instance name is stored in the PTR RDATA and multiple PTR 171 records with the same owner name but only differing RDATA often 172 exist. 174 In order to distinguish each individual record with potentially 175 different expiry times, the TIMEOUT resource record is made up 176 multiple lists of hashes of the records for which they are 177 applicable. Each list has an expiry time associated with it and each 178 hash corresponds to a resource record for which that expiry time 179 applies. Each resource record represented by a hash in the list uses 180 the same expiry time associated with the list. There is also a hash 181 algorithm index associated with each list. All hashes in the list 182 MUST use the same hash algorithm. 184 Since each TIMEOUT resource record is actually a collection of state 185 from different sources over different time periods, there is a 186 potential for default algorithm changes to occur on a single server 187 or due to unavailability of an UPDATE server for a period of time to 188 merge records between failover servers with different default 189 algorithms. Therefore, the ability to have different hash algorithms 190 in the same TIMEOUT resource record is accounted for. While this 191 won't be a common scenario, it could occur during failure and restart 192 scenarios. All hashes for the same expiry time MUST use the same 193 hash algorithm. This is not likely to cause any problems with 194 merging since the same server will be using the same default hash 195 algorithm at a particular second resolution in time. 197 Within the TIMEOUT resource record there can exist an arbitrary 198 number of combinations of Hash Algorithm Index, Hash Count, Expiry 199 Time, and list of zero or more cryptographic hashes. The specific 200 fields and their values are defined as: 202 5.1. Hash Count 204 The Hash Count is a 16-bit value that specifies the number of hash 205 values for the instance. All hashes within the instance MUST use the 206 same Hash Algorithm specified by the Hash Algorithm Index. 208 A Hash Count of 0 indicates that no hashes are contained in the list. 209 This is a shortcut notation meaning all resource records with the 210 same owner name and class use the same Expiry Time. There MUST be 211 only one instance of Hash Count and Hash Algorithm Index in this 212 case. When the Hash Count is 0, the Hash Algorithm Index is set to 213 NOHASH (0) on transmission and ignored on reception. 215 5.2. Hash Algorithm Index 217 The Hash Algorithm Index is a 16-bit value that specifies an 218 identifier for the hash algorithm used. The indexes are declared in 219 a registry maintained by IANA for the purpose of listing acceptable 220 hash algorithms for this purpose. In addition to the algorithm and 221 the index, the registry will contain the output length in bits of the 222 algorithm to be used. It is conceivable, though not likely, that the 223 same algorithm could be used with different output lengths. In this 224 case, each output length would require a different index in the 225 registry. Additions to this registry will be approved with 226 additional documentation under expert review. At the time that the 227 registry is created by IANA, a group of expert reviewers will be 228 established. 230 The Hash Algorithm Index of 0 is defined as NOHASH and MUST NOT be 231 used if any hash values are present in the instance. The index value 232 of 0 is to be included in the IANA registry of Hash Algorithm Index 233 values. 235 5.3. Expiry Time 237 The expiry time is a 64-bit number expressed as the number of seconds 238 since the UNIX epoch (00:00:00 UTC on January 1, 1970). This value 239 is an absolute time at which the record will expire. Lease times 240 must be converted to an absolute expiry time when received. 242 5.4. Cryptographic Hashes 244 The hash of each resource record is calculated using the entire 245 length of the resource record as input. The output value of the hash 246 is always a fixed pre-defined length specified with the hash 247 algorithm. 249 6. Cryptographic Hash Requirements 251 The cryptographic hash algorithm used SHOULD provide the following 252 properties: 254 1. Well known algorithm with implementations easily available. 256 2. Trusted algorithm with resistance to collision attacks. 258 3. Minimize output length for efficient storage in the TIMEOUT 259 resource record. 261 While computational complexity is always a consideration when 262 selecting algorithms, the frequency of this calculation is intended 263 to be low volume and, therefore, this property is of reduced 264 importance. 266 6.1. REQUIRED Cryptographic Hash Algorithm 268 The initial algorithm selected to meet this criteria is SHAKE128. It 269 is part of the SHA-3 [SHA3] family of cryptographic hash algorithms. 270 The output length of the hash used is 128 bits or 16 bytes. SHAKE128 271 is implemented in the OpenSSL Library version 1.1.1 [OPENSSL]. In 272 order to be in compliance with this specification, the SHAKE128 273 algorithm MUST be implemented. SHAKE128 is to be assigned an 274 algorithm index of 1 in the IANA registry. 276 Additional algorithms may be defined in the future that can be used 277 in place of SHAKE128. Coordination between the primary and secondary 278 servers is required out of band to ensure both sides of a transfer 279 have implemented the particular algorithm. 281 7. TIMEOUT RR RDATA Wire Format 283 The TIMEOUT resource record follows the same pattern as other DNS 284 resource records as defined in Section 3.2.1 of [RFC1035]. 286 When transferred to a secondary server, the TTL field of the TIMEOUT 287 resource record is set to 0. The TTL has no meaning since TIMEOUT 288 RR's are never directly queried. 290 The RDATA section of the resource record is illustrated in Figure 1: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Hash Count A (n) | Hash Algorithm Index A | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Expiry Time A (64-bit) | 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 . . 301 . Hash A-1 . 302 . . 303 . . 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 . . 306 . Hash A-n . 307 . . 308 . . 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Hash Count B (m) | Hash Algorithm Index B | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Expiry Time B (64-bit) | 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 . . 316 . Hash B-1 . 317 . . 318 . . 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 . . 321 . Hash B-m . 322 . . 323 . . 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 1: RDATA Wire Format 328 Figure 1 represents an arbitrary number of combinations of Hash 329 Count, Hash Algorithm Index, Expiry Time, and list of zero or more 330 cryptographic hashes. The figure entries containing "A" in the name 331 represent one instance while the figure entries containing "B" in the 332 name represent a second instance. There can be an arbitrary number 333 of instances whose byte counts are accumulated by the RDLEN field in 334 the resource record header. 336 The letter "n" represents the Hash Count in the first instance where 337 there exists 0..n cryptographic hashes in the list. The letter "m" 338 represents the Hash Count in the second instance where there exists 339 0..m cryptographic hashes in the second list. Either "n" or "m" 340 could be zero. 342 8. TIMEOUT RR RDATA Presentation Format 344 Hash Count: unsigned decimal integer 346 Hash Algorithm index: unsigned decimal integer 348 Expiry Time: Internet Date/Time Format from [RFC3339] Section 5.6 349 profile of ISO 8601 351 Hash: Base64 encoding (whitespace allowed), Section 4 of [RFC4648] 353 9. IANA Considerations 355 This document defines a new DNS Resource Record Type named TIMEOUT to 356 be exchanged between authoritative primary and secondary DNS servers. 357 It is assigned out of the DNS Parameters Resource Record (RR) Type 358 registry. The value for the TIMEOUT resource record type is TBA. 360 This document establishes a new registry of DNS TIMEOUT Resource 361 Record Cryptographic Hash Algorithm Index values. The registry shall 362 include an index, an index name, the name of the algorithm, and the 363 length of the output function in bits. The index is to be used in 364 the RDATA section of the TIMEOUT resource record. 366 +-------+----------+-----------+---------------+-------------+ 367 | Index | Name | Algorithm | Length (bits) | Definition | 368 +-------+----------+-----------+---------------+-------------+ 369 | 0 | NOHASH | | 0 | Section 5.2 | 370 | 1 | SHAKE128 | SHAKE128 | 128 | Section 6.1 | 371 +-------+----------+-----------+---------------+-------------+ 373 Table 1: TIMEOUT RR Hash Algorithm Index values 375 10. Security Considerations 377 Secondary servers that have received TIMEOUT resource records in a 378 transfer but do not understand the record type will serve requests 379 for them like any other resource record type. This is a 380 configuration error and can reveal the time that other DNS resource 381 records will be present. 383 Vulnerabilities in cryptographic hash algorithms may become known 384 over time. This specification only defines one well respected 385 algorithm (SHAKE128) for hashing resource records to maximize 386 interoperability. The IANA registry is defined for the future when 387 vulnerabilities are found in this algorithm. Until that point, there 388 likely will not exist a need to add new hash algorithms to the 389 registry. 391 11. Acknowledgments 393 This idea was motivated through conversations with Mark Andrews. 395 12. References 397 12.1. Normative References 399 [RFC1035] Mockapetris, P., "Domain names - implementation and 400 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 401 November 1987, . 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 409 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 410 . 412 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 413 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 414 2003, . 416 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 417 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 418 . 420 [SHA3] National Institute of Standards and Technology, "SHA-3 421 Standard - Permutation-Based Hash and Extendable-Output 422 Functions FIPS PUB 202", August 2015, 423 . 426 12.2. Informative References 428 [I-D.sekar-dns-ul] 429 Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", 430 draft-sekar-dns-ul-02 (work in progress), August 2018. 432 [OPENSSL] OpenSSL Software Foundation, "OpenSSL: Cryptography and 433 SSL/TLS Toolkit", October 2017, . 435 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 436 DOI 10.17487/RFC1995, August 1996, 437 . 439 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 440 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 441 RFC 2136, DOI 10.17487/RFC2136, April 1997, 442 . 444 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 445 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 446 . 448 Authors' Addresses 450 Tom Pusateri 451 Unaffiliated 452 Raleigh, NC 453 USA 455 Email: pusateri@bangj.com 457 Tim Wattenberg 458 Unaffiliated 459 Cologne 460 Germany 462 Email: mail@timwattenberg.de