idnits 2.17.1 draft-wessels-dns-zone-digest-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 9, 2018) is 2026 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2065 (Obsoleted by RFC 2535) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 7706 (Obsoleted by RFC 8806) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Wessels 3 Internet-Draft P. Barber 4 Intended status: Experimental M. Weinberg 5 Expires: April 12, 2019 Verisign 6 W. Kumari 7 Google 8 W. Hardaker 9 USC/ISI 10 October 9, 2018 12 Message Digest for DNS Zones 13 draft-wessels-dns-zone-digest-03 15 Abstract 17 This document describes an experimental protocol and new DNS Resource 18 Record that can be used to provide an message digest over DNS zone 19 data. The ZONEMD Resource Record conveys the message digest data in 20 the zone itself. When a zone publisher includes an ZONEMD record, 21 recipients can verify the zone contents for accuracy and 22 completeness. This provides assurance that received zone data 23 matches published data, regardless of how the zone data has been 24 transmitted and received. 26 ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC is designed 27 to protect recursive name servers and their caches, ZONEMD protects 28 applications that consume zone files, whether they be authoritative 29 name servers, recursive name servers, or uses of zone file data. 31 As specified at this time, ZONEMD is not designed for use in large, 32 dynamic zones due to the time and resources required for digest 33 calculation. The ZONEMD record described in this document includes 34 fields reserved for future work to support large, dynamic zones. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 12, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Design Overview . . . . . . . . . . . . . . . . . . . . . 5 73 1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.3.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6 75 1.3.2. Providers, Secondaries, and Anycast . . . . . . . . . 6 76 1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 6 77 1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7 78 1.3.5. General Purpose Comparison Check . . . . . . . . . . 7 79 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 80 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 81 2.1. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 7 82 2.1.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 83 2.1.2. The Digest Type Field . . . . . . . . . . . . . . . . 8 84 2.1.3. The Reserved Field . . . . . . . . . . . . . . . . . 8 85 2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 86 2.2. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 87 2.3. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 9 88 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 9 89 3.1. Canonical Format and Ordering . . . . . . . . . . . . . . 9 90 3.1.1. Order of RRsets Having the Same Owner Name . . . . . 10 91 3.1.2. Special Considerations for SOA RRs . . . . . . . . . 10 92 3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 93 3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 94 3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11 95 3.4.1. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 97 3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 11 98 4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 12 99 5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 101 6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 13 102 6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 13 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 104 7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 13 105 7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 14 106 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 107 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 108 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 109 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 14 110 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 15 111 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 114 12.2. Informative References . . . . . . . . . . . . . . . . . 18 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 117 1. Introduction 119 In the DNS, a zone is the collection of authoritative resource 120 records (RRs) sharing a common origin ([RFC7719]). Zones are often 121 stored as files on disk in the so-called master file format 122 [RFC1034]. Zones are generally distributed between name servers 123 using the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files 124 can also be distributed outside of the DNS, with such protocols as 125 FTP, HTTP, rsync, and even via email. Currently there is no standard 126 way to verify the authenticity of a stand-alone zone file. 128 This document introduces a new RR type that serves as a cryptographic 129 message digest of the data in a zone file. It allows a receiver of 130 the zone file to verify the zone file's authenticity, especially when 131 used in combination with DNSSEC. This technique makes the message 132 digest a part of the zone file itself, allowing verification the zone 133 file as a whole, no matter how it is transmitted. Furthermore, the 134 digest is based on the wire format of zone data. Thus, it 135 independent of presentation format, such as changes in whitespace, 136 capitalization, and comments. 138 DNSSEC provides three strong security guarantees relevant to this 139 protocol: 141 1. whether or not to expect DNSSEC records in the zone, 143 2. whether or not to expect a ZONEMD record in a signed zone, and 144 3. whether or not the ZONEMD record has been altered since it was 145 signed. 147 This specification is OPTIONAL to implement by both publishers and 148 consumers of zone file data. 150 1.1. Motivation 152 The motivation for this protocol enhancement is the desire for the 153 ability to verify the authenticity of a stand-alone zone file, 154 regardless of how it is transmitted. A consumer of zone file data 155 should be able to verify that the data is as-published by the zone 156 operator. 158 One approach to preventing data tampering and corruption is to secure 159 the distribution channel. The DNS has a number of features that can 160 already be used for channel security. Perhaps the most widely used 161 is DNS transaction signatures (TSIG [RFC2845]). TSIG uses shared 162 secret keys and a message digest to protect individual query and 163 response messages. It is generally used to authenticate and validate 164 UPDATE [RFC2136], AXFR [RFC5936], and IXFR [RFC1995] messages. 166 DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another 167 protocol extension designed to authenticate individual DNS 168 transactions. Whereas SIG records were originally designed to cover 169 specific RR types, SIG(0) is used to sign an entire DNS message. 170 Unlike TSIG, SIG(0) uses public key cryptography rather than shared 171 secrets. 173 The Transport Layer Security protocol suite is also designed to 174 provide channel security. It is entirely possible, for example, to 175 perform zone transfers using DNS-over-TLS ([RFC7858]). Furthermore, 176 one can easily imagine the distribution of zone files over HTTPS- 177 enabled web servers, as well as DNS-over-HTTPS [dns-over-https]. 179 Unfortunately, the protections provided by these channel security 180 techniques are ephemeral and are not retained after the data transfer 181 is complete. They can ensure that the client receives the data from 182 the expected server, and that the data sent by the server is not 183 modified during transmission. However, they do not guarantee that 184 the server transmits the data as originally published, and do not 185 provide any methods to verify data that is read after transmission is 186 complete. For example, a name server loading saved zone data upon 187 restart cannot guarantee that the on-disk data has not been modified. 188 For these reasons, it is preferable to secure the data itself. 190 Why not simply rely on DNSSEC, which provides certain data security 191 guarantees? Certainly for zones that are signed, a recipient could 192 validate all of the signed RRsets. Additionally, denial-of-existence 193 records can prove that RRsets have not been added or removed. 194 However, not all RRsets in a zone are signed. The design of DNSSEC 195 stipulates that delegations (non-apex NS records) are not signed, and 196 neither are any glue records. Thus, changes to delegation and glue 197 records cannot be detected by DNSSEC alone. Furthermore, zones that 198 employ NSEC3 with opt-out are susceptible to the removal or addition 199 of names between the signed nodes. Whereas DNSSEC is primarily 200 designed to protect consumers of DNS response messages, this protocol 201 is designed to protect consumers of zone files. 203 There are existing tools and protocols that provide data security, 204 such as OpenPGP [RFC4880] and S/MIME [RFC3851]. In fact, the 205 internic.net site publishes PGP signatures along side the root zone 206 and other files available there. However, this is a detached 207 signature with no strong association to the corresponding zone file 208 other than its timestamp. Non-detached signatures are, of course, 209 possible, but these necessarily change the format of the file being 210 distributed. That is, a zone file signed with OpenPGP or S/MIME no 211 longer looks like a zone file and could not directly be loaded into a 212 name server. Once loaded the signature data is lost, so it does not 213 survive further propagation. 215 It seems the desire for data security in DNS zones was envisioned as 216 far back as 1997. [RFC2065] is an obsoleted specification of the 217 first generation DNSSEC Security Extensions. It describes a zone 218 transfer signature, aka AXFR SIG, which is similar to the technique 219 proposed by this document. That is, it proposes ordering all 220 (signed) RRsets in a zone, hashing their contents, and then signing 221 the zone hash. The AXFR SIG is described only for use during zone 222 transfers. It did not postulate the need to validate zone data 223 distributed outside of the DNS. Furthermore, its successor, 224 [RFC2535], omits the AXFR SIG, while at the same time introducing an 225 IXFR SIG. 227 1.2. Design Overview 229 This document introduces a new Resource Record type designed to 230 convey a message digest of the content of a zone file. The digest is 231 calculated at the time of zone publication. Ideally the zone is 232 signed with DNSSEC to guarantee that any modifications of the digest 233 can be detected. The procedures for digest calculation and DNSSEC 234 signing are similar (i.e., both require the same ordering of RRs) and 235 can be done in parallel. 237 The zone digest is designed to be used on zones that are relatively 238 stable and have infrequent updates. As currently specified, the 239 digest is re-calculated over the entire zone content each time. This 240 specification does not provide an efficient mechanism for incremental 241 updates of zone data. It does, however, reserve a field in the 242 ZONEMD record for future work to support incremental zone digest 243 algorithms (e.g. using Merkle trees). 245 It is expected that verification of a zone digest would be 246 implemented in name server software. That is, a name server can 247 verify the zone data it was given and refuse to serve a zone which 248 fails verification. For signed zones, the name server needs a trust 249 anchor to perform DNSSEC validation. For signed non-root zones, the 250 name server may need to send queries to validate a chain-of-trust. 251 Digest verification could also be performed externally. 253 1.3. Use Cases 255 1.3.1. Root Zone 257 The root zone [InterNIC] is perhaps the most widely distributed DNS 258 zone on the Internet, served by 930 separate instances [RootServers] 259 at the time of this writing. Additionally, many organizations 260 configure their own name servers to serve the root zone locally. 261 Reasons for doing so include privacy and reduced access time. 262 [RFC7706] describes one, but not the only, way to do this. As the 263 root zone spreads beyond its traditional deployment boundaries, the 264 need for verification of the completeness of the zone contents 265 becomes increasingly important. 267 1.3.2. Providers, Secondaries, and Anycast 269 Since its very early days, the developers of the DNS recognized the 270 importance of secondary name servers and service diversity. However, 271 they may not have anticipated the complexity of modern DNS service 272 provisioning which can include multiple third-party providers and 273 hundreds of anycast instances. Instead of a simple primary-to- 274 secondary zone distribution system, today it is possible to have 275 multiple levels, multiple parties, and multiple protocols involved in 276 the distribution of zone data. This complexity introduces new places 277 for problems to arise. The zone digest protects the integrity of 278 data that flows through such systems. 280 1.3.3. Response Policy Zones 282 DNS Response Policy Zones is "a method of expressing DNS response 283 policy information inside specially constructed DNS zones..." [RPZ]. 284 A number of companies provide RPZ feeds, which can be consumed by 285 name server and firewall products. Since these are zone files, AXFR 286 is often, but not necessarily used for transmission. While RPZ zones 287 can certainly be signed with DNSSEC, the data is not queried 288 directly, and would not be subject to DNSSEC validation. 290 1.3.4. Centralized Zone Data Service 292 ICANN operates the Centralized Zone Data Service [CZDS], which is a 293 repository of top-level domain zone files. Users request access to 294 the system, and to individual zones, and are then able to download 295 zone data for certain uses. Adding a zone digest to these would 296 provide CZDS users with assurances that the data has not been 297 modified. Note that ZONEMD could be added to CZDS zone data 298 independently of the zone served by production name servers. 300 1.3.5. General Purpose Comparison Check 302 Since the zone digest does not depend on presentation format, it 303 could be used to compare multiple copies of a zone received from 304 different sources, or copies generated by different processes. 306 1.4. Requirements Language 308 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 309 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 310 "OPTIONAL" in this document are to be interpreted as described in BCP 311 14 [RFC2119] [RFC8174] when, and only when, they appear in all 312 capitals, as shown here. 314 2. The ZONEMD Resource Record 316 This section describes the ZONEMD Resource Record, including its 317 fields, wire format, and presentation format. The Type value for the 318 ZONEMD RR is TBD. The ZONEMD RR is class independent. The RDATA of 319 the resource record consists of three fields: Serial, Digest Type, 320 and Digest. 322 FOR DISCUSSION: This document is currently written as though a zone 323 MUST NOT contain more than one ZONEMD RR. Having exactly one ZONEMD 324 record per zone simplifies this protocol and eliminates confusion 325 around downgrade attacks, at the expense of algorithm agility. 327 2.1. ZONEMD RDATA Wire Format 329 The ZONEMD RDATA wire format is encoded as follows: 331 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Serial | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Digest Type | Reserved | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 338 | Digest | 339 / / 340 / / 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 2.1.1. The Serial Field 345 The Serial field is a 32-bit unsigned integer in network order. It 346 is equal to the serial number from the zone's SOA record ([RFC1035] 347 section 3.3.13) for which the message digest was generated. 349 2.1.2. The Digest Type Field 351 The Digest Type field is an 8-bit unsigned integer, with meaning 352 equivalent to the Digest Type of the DS resource record, as defined 353 in section 5.1.3 of [RFC4034] and values found in the IANA protocol 354 registry for DS digest types [iana-ds-digest-types]. 356 The status of ZONEMD digest types (e.g., mandatory, optional, 357 deprecated), however, are independent of those for DS digest types. 359 At the time of this writing the following digest types are defined: 361 +-------+-----------------+------------+-----------+ 362 | Value | Description | Status | Reference | 363 +-------+-----------------+------------+-----------+ 364 | 1 | SHA1 | Deprecated | [RFC3658] | 365 | 2 | SHA256 | Mandatory | [RFC4509] | 366 | 3 | GOST R 34.11-94 | Deprecated | [RFC5933] | 367 | 4 | SHA384 | Optional | [RFC6605] | 368 +-------+-----------------+------------+-----------+ 370 Table 1: ZONEMD Digest Types 372 2.1.3. The Reserved Field 374 The Reserved field is an 8-bit unsigned integer, which is always set 375 to zero. This field is reserved for future work to support efficient 376 incremental updates. 378 2.1.4. The Digest Field 380 The Digest field is a variable-length sequence of octets containing 381 the message digest. Section 3 describes how to calculate the digest 382 for a zone. Section 4 describes how to use the digest to verify the 383 contents of a zone. 385 2.2. ZONEMD Presentation Format 387 The presentation format of the RDATA portion is as follows: 389 The Serial field MUST be represented as an unsigned decimal integer. 391 The Reserved field MUST be represented as an unsigned decimal integer 392 set to zero. 394 The Digest Type field MUST be represented as an unsigned decimal 395 integer. 397 The Digest MUST be represented as a sequence of case-insensitive 398 hexadecimal digits. Whitespace is allowed within the hexadecimal 399 text. 401 2.3. ZONEMD Example 403 The following example shows a ZONEMD RR. 405 example.com. 86400 IN ZONEMD ( 2018031500 4 0 FEBE3D4CE2EC2FFA4BA9 406 9D46CD69D6D29711E552 407 17057BEE7EB1A7B641A4 408 7BA7FED2DD5B97AE499F 409 AFA4F22C6BD647DE ) 411 3. Calculating the Digest 413 3.1. Canonical Format and Ordering 415 Calculation of the zone digest REQUIRES the RRs in a zone to be 416 processed in a consistent format and ordering. Correct ordering of 417 the zone depends on (1) ordering of owner names in the zone, (2) 418 ordering of RRsets with the same owner name, and (3) ordering of RRs 419 within an RRset. 421 This specification adopts DNSSEC's canonical ordering for names 422 (Section 6.1 of [RFC4034]), and canonical ordering for RRs within an 423 RRset (Section 6.3 of [RFC4034]). It also adopts DNSSEC's canonical 424 RR form (Section 6.2 of [RFC4034]). However, since DNSSEC does not 425 define a canonical ordering for RRsets having the same owner name, 426 that ordering is defined here. 428 3.1.1. Order of RRsets Having the Same Owner Name 430 For the purposes of calculating the zone digest, RRsets having the 431 same owner name MUST be numerically ordered by their numeric RR TYPE. 433 3.1.2. Special Considerations for SOA RRs 435 When AXFR is used to transfer zone data, the first and last records 436 are always the SOA RR ([RFC5936] Section 2.2). Because of this, zone 437 files on disk often contain two SOA RRs. When calculating the zone 438 digest, the first SOA RR MUST be included and any subsequent SOA RRs 439 MUST NOT be included. 441 Additionally, per established practices, the SOA record is generally 442 the first record in a zone file. However, according to the 443 requirement to sort RRsets with the same owner name by type, the SOA 444 RR (type value 6) will not be first in the digest calculation. The 445 zone's NS RRset (type value 2) at the apex MUST be processed before 446 the SOA RR. 448 3.2. Add ZONEMD Placeholder 450 In preparation for calculating the zone digest, any existing ZONEMD 451 record MUST first be deleted from the zone. 453 Prior to calculation of the digest, and prior to signing with DNSSEC, 454 a placeholder ZONEMD record MUST be added to the zone. This serves 455 two purposes: (1) it allows the digest to cover the Serial, Reserved, 456 and Digest Type field values, and (2) ensures that appropriate 457 denial-of-existence (NSEC, NSEC3) records are created if the zone is 458 signed with DNSSEC. 460 It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of 461 the SOA. 463 In the placeholder record, the Serial field MUST be set to the 464 current SOA Serial. The Digest Type field MUST be set to the value 465 for the chosen digest algorithm. The Digest field MUST be set to all 466 zeroes and of length appropriate for the chosen digest algorithm. 468 3.3. Optionally Sign the Zone 470 Following addition of the placeholder record, the zone MAY be signed 471 with DNSSEC. Note that when the digest calculation is complete, and 472 the ZONEMD record is updated, the signature(s) for that record MUST 473 be recalculated and updated as well. Therefore, the signer is not 474 required to calculate a signature over the placeholder record at this 475 step in the process, but it is harmless to do so. 477 3.4. Calculate the Digest 479 The zone digest is calculated by concatenating the canonical on-the- 480 wire form (without name compression) of all RRs in the zone, in the 481 order described above, subject to the inclusion/exclusion rules 482 described below, and then applying the digest algorithm: 484 digest = digest_algorithm( RR(1) | RR(2) | RR(3) | ... ) 486 where "|" denotes concatenation, and 488 RR(i) = owner | type | class | TTL | RDATA length | RDATA 490 3.4.1. Inclusion/Exclusion Rules 492 When calculating the digest, the following inclusion/exclusion rules 493 apply: 495 o All records in the zone including glue records MUST be included. 497 o More than one SOA MUST NOT be included. 499 o The placeholder ZONEMD RR MUST be included. 501 o If the zone is signed, DNSSEC RRs MUST be included, except: 503 o The RRSIG covering ZONEMD MUST NOT be included. 505 FOR DISCUSSION: Ambiguities about records that are in/out of zone. 506 For example, see Jinmei message to dnsop 2018-06-01 and followups. 507 BIND will load and AXFR data "occluded" by DNAME/NS. 509 3.5. Update ZONEMD RR 511 Once the zone digest has been calculated, its value is then copied to 512 the Digest field of the ZONEMD record. 514 If the zone is signed with DNSSEC, the appropriate RRSIG records 515 covering the ZONEMD record MUST then be added or updated. Because 516 the ZONEMD placeholder was added prior to signing, the zone will 517 already have the appropriate denial-of-existence (NSEC, NSEC3) 518 records. 520 Some implementations of incremental DNSSEC signing might update the 521 zone's serial number for each resigning. However, to preserve the 522 calculated digest, generation of the ZONEMD signature at this time 523 MUST NOT also result in a change of the SOA serial number. 525 4. Verifying Zone Message Digest 527 The recipient of a zone that has a message digest record can verify 528 the zone by calculating the digest as follows: 530 1. The verifier SHOULD first determine whether or not to expect 531 DNSSEC records in the zone. This can be done by examining 532 locally configured trust anchors, or querying for (and 533 validating) DS RRs in the parent zone. For zones that are 534 provably unsigned, digest validation continues at step 4 below. 536 2. For zones that are provably signed, the existence of the ZONEMD 537 record MUST be verified. If the ZONEMD record provably does not 538 exist, digest verification cannot be done. If the ZONEMD record 539 does provably exist, but is not found in the zone, digest 540 verification MUST NOT be considered successful. 542 3. For zones that are provably signed, the SOA RR and ZONEMD RR(set) 543 MUST have valid signatures, chaining up to a trust anchor. If 544 DNSSEC validation of the SOA or ZONEMD records fails, digest 545 verification MUST NOT be considered successful. 547 4. If the zone contains more than one ZONEMD RR, digest verification 548 MUST NOT be considered successful. 550 5. The SOA Serial field MUST exactly match the ZONEMD Serial field. 551 If the fields to not match, digest verification MUST NOT be 552 considered successful. 554 6. The ZONEMD Digest Type field MUST be checked. If the verifier 555 does not support the given digest type, it SHOULD report that the 556 zone digest could not be verified due to an unsupported 557 algorithm. 559 7. The zone digest is calculated using the algorithm described in 560 Section 3.4. Note in particular that the digested ZONEMD RR MUST 561 be a placeholder and its RRSIGs MUST NOT be included in the 562 digest. 564 8. The calculated digest is compared to the received digest. If the 565 two digest values match, verification is considered successful. 566 Otherwise, verification MUST NOT be considered successful. 568 9. If the zone is to be served and transferred, the original (not 569 placeholder) ZONEMD RR MUST be sent to recipients so that 570 downstream clients can verify the zone. 572 5. Scope of Experimentation 574 This memo is published as an Experimental RFC. The purpose of the 575 experimental period is to provide the community time to analyze and 576 evaluate to the methods defined in this document, particularly with 577 regard to the wide variety of DNS zones in use on the Internet. 579 Additionally, the ZONEMD record defined in this document includes a 580 Reserved field. The authors have a particular future use in mind for 581 this field, namely to support efficient digests in large, dynamic 582 zones. We intend to conduct future experiments using Merkle trees of 583 varying depth. The choice of tree depth can be encoded in this 584 reserved field. 586 The duration of the experiment is expected to be no less than two 587 years from the publication of this document. If the experiment is 588 successful, it is expected that the findings of the experiment will 589 result in an updated document for Standards Track approval. 591 6. IANA Considerations 593 6.1. ZONEMD RRtype 595 This document uses a new DNS RR type, ZONEMD, whose value TBD has 596 been allocated by IANA from the "Resource Record (RR) TYPEs" 597 subregistry of the "Domain Name System (DNS) Parameters" registry. 599 6.2. ZONEMD Digest Type 601 The ZONEMD Digest Type field has the same values as the DS RR Digest 602 Type field, but with independent implementation status. Therefore, 603 this document expects IANA will create a new "ZONEMD Digest Types" 604 registry. 606 7. Security Considerations 608 7.1. Attacks Against the Zone Digest 610 The zone digest allows the receiver to verify that the zone contents 611 haven't been modified since the zone was generated/published. 612 Verification is strongest when the zone is also signed with DNSSEC. 613 An attacker, whose goal is to modify zone content before it is used 614 by the victim, may consider a number of different approaches. 616 The attacker might perform a downgrade attack to an unsigned zone. 617 This is why Section 4 RECOMMENDS that the verifier determine whether 618 or not to expect DNSSEC signatures for the zone in step 1. 620 The attacker might perform a downgrade attack by removing the ZONEMD 621 record. This is why Section 4 REQUIRES that the verifier checks 622 DNSSEC denial-of-existence proofs in step 2. 624 The attacker might alter the Digest Type or Digest fields of the 625 ZONEMD record. Such modifications are detectable only with DNSSEC 626 validation. 628 7.2. Attacks Utilizing the Zone Digest 630 Nothing in this specification prevents clients from making, and 631 servers from responding to, ZONEMD queries. One might consider how 632 well ZONEMD responses could be used in a distributed denial-of- 633 service amplification attack. 635 The ZONEMD RR is moderately sized, much like the DS RR. A single 636 ZONEMD RR contributes approximately 40 to 65 octets to a DNS 637 response, for currently defined digest types. Certainly other query 638 types result in larger amplification effects (i.e., DNSKEY). 640 8. Privacy Considerations 642 This specification has no impacts on user privacy. 644 9. Acknowledgments 646 The authors wish to thank David Blacka, Scott Hollenbeck, and Rick 647 Wilhelm for providing feedback on early drafts of this document. 648 Additionally, they thank Joe Abley, Mark Andrews, Olafur Gudmundsson, 649 Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Burt Kaliski, 650 Shane Kerr, Matt Larson, John Levine, Ed Lewis, Mukund Sivaraman, 651 Petr Spacek, Ondrej Sury, Florian Weimer, Tim Wicinksi, Paul Wouters, 652 and other members of the dnsop working group for their input. 654 10. Implementation Status 656 10.1. Authors' Implementation 658 The authors have an open source implementation in C, using the ldns 659 library [ldns-zone-digest]. This implementation is able to perform 660 the following functions: 662 o Read an input zone file and output a zone file with the ZONEMD 663 placeholder. 665 o Compute zone digest over signed zone file and update the ZONEMD 666 record. 668 o Re-compute DNSSEC signature over the ZONEMD record. 670 o Verify the zone digest from an input zone file. 672 This implementation does not: 674 o Perform DNSSEC validation of the ZONEMD record. 676 o Support the Gost digest algorithm. 678 o Output the ZONEMD record in its defined presentation format. 680 10.2. Shane Kerr's Implementation 682 Shane Kerr wrote an implementation of this specification during the 683 IETF 102 hackathon [ZoneDigestHackathon]. This implementation is in 684 Python and is able to perform the following functions: 686 o Read an input zone file and a output zone file with ZONEMD record. 688 o Verify the zone digest from an input zone file. 690 o Output the ZONEMD record in its defined presentation format. 692 o Generate Gost digests. 694 This implementation does not: 696 o Re-compute DNSSEC signature over the ZONEMD record. 698 o Perform DNSSEC validation of the ZONEMD record. 700 11. Change Log 702 RFC Editor: Please remove this section. 704 This section lists substantial changes to the document as it is being 705 worked on. 707 From -00 to -01: 709 o Removed requirement to sort by RR CLASS. 711 o Added Kumari and Hardaker as coauthors. 713 o Added Change Log section. 715 o Minor clarifications and grammatical edits. 717 From -01 to -02: 719 o Emphasize desire for data security over channel security. 721 o Expanded motivation into its own subsection. 723 o Removed discussion topic whether or not to include serial in 724 ZONEMD. 726 o Clarified that a zone's NS records always sort before the SOA 727 record. 729 o Clarified that all records in the zone must are digested, except 730 as specified in the exclusion rules. 732 o Added for discussion out-of-zone and occluded records. 734 o Clarified that update of ZONEMD signature must not cause a serial 735 number change. 737 o Added persons to acknowledgments. 739 From -02 to -03: 741 o Added recommendation to set ZONEMD TTL to SOA TTL. 743 o Clarified that digest input uses uncompressed names. 745 o Updated Implementations section. 747 o Changed intended status from Standards Track to Experimental and 748 added Scope of Experiment section. 750 o Updated Motivation, Introduction, and Design Overview sections in 751 response to working group discussion. 753 o Gave ZONEMD digest types their own status, separate from DS digest 754 types. Request IANA to create a registry. 756 o Added Reserved field for future work supporting dynamic updates. 758 o Be more rigorous about having just ONE ZONEMD record in the zone. 760 o Expanded use cases. 762 12. References 764 12.1. Normative References 766 [iana-ds-digest-types] 767 IANA, "Delegation Signer (DS) Resource Record (RR) Type 768 Digest Algorithms", April 2012, 769 . 772 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 773 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 774 . 776 [RFC1035] Mockapetris, P., "Domain names - implementation and 777 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 778 November 1987, . 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, 782 DOI 10.17487/RFC2119, March 1997, 783 . 785 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 786 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, 787 . 789 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 790 Rose, "Resource Records for the DNS Security Extensions", 791 RFC 4034, DOI 10.17487/RFC4034, March 2005, 792 . 794 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 795 (DS) Resource Records (RRs)", RFC 4509, 796 DOI 10.17487/RFC4509, May 2006, 797 . 799 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 800 GOST Signature Algorithms in DNSKEY and RRSIG Resource 801 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 802 2010, . 804 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 805 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 806 DOI 10.17487/RFC6605, April 2012, 807 . 809 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 810 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 811 May 2017, . 813 12.2. Informative References 815 [CZDS] Internet Corporation for Assigned Names and Numbers, 816 "Centralized Zone Data Service", October 2018, 817 . 819 [dns-over-https] 820 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 821 (DoH)", draft-ietf-doh-dns-over-https-12 (work in 822 progress), June 2018, . 825 [InterNIC] 826 ICANN, "InterNIC FTP site", May 2018, 827 . 829 [ldns-zone-digest] 830 Verisign, "Implementation of Message Digests for DNS Zones 831 using the ldns library", July 2018, 832 . 834 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 835 DOI 10.17487/RFC1995, August 1996, 836 . 838 [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System 839 Security Extensions", RFC 2065, DOI 10.17487/RFC2065, 840 January 1997, . 842 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 843 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 844 RFC 2136, DOI 10.17487/RFC2136, April 1997, 845 . 847 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 848 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, 849 . 851 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 852 Wellington, "Secret Key Transaction Authentication for DNS 853 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 854 . 856 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 857 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 858 2000, . 860 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 861 Extensions (S/MIME) Version 3.1 Message Specification", 862 RFC 3851, DOI 10.17487/RFC3851, July 2004, 863 . 865 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 866 Thayer, "OpenPGP Message Format", RFC 4880, 867 DOI 10.17487/RFC4880, November 2007, 868 . 870 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 871 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 872 . 874 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 875 Servers by Running One on Loopback", RFC 7706, 876 DOI 10.17487/RFC7706, November 2015, 877 . 879 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 880 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 881 2015, . 883 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 884 and P. Hoffman, "Specification for DNS over Transport 885 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 886 2016, . 888 [RootServers] 889 Root Server Operators, "Root Server Technical Operations", 890 July 2018, . 892 [RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones 893 (RPZ)", draft-vixie-dnsop-dns-rpz-00 (work in progress), 894 June 2018, . 897 [ZoneDigestHackathon] 898 Kerr, S., "Prototype implementation of ZONEMD for the IETF 899 102 hackathon in Python", July 2018, 900 . 902 Authors' Addresses 904 Duane Wessels 905 Verisign 906 12061 Bluemont Way 907 Reston, VA 20190 909 Phone: +1 703 948-3200 910 Email: dwessels@verisign.com 911 URI: http://verisign.com 913 Piet Barber 914 Verisign 915 12061 Bluemont Way 916 Reston, VA 20190 918 Phone: +1 703 948-3200 919 Email: pbarber@verisign.com 920 URI: http://verisign.com 922 Matt Weinberg 923 Verisign 924 12061 Bluemont Way 925 Reston, VA 20190 927 Phone: +1 703 948-3200 928 Email: mweinberg@verisign.com 929 URI: http://verisign.com 931 Warren Kumari 932 Google 933 1600 Amphitheatre Parkway 934 Mountain View, CA 94043 936 Email: warren@kumari.net 938 Wes Hardaker 939 USC/ISI 940 P.O. Box 382 941 Davis, CA 95617 943 Email: ietf@hardakers.net