1 Internet Engineering Task Force (IETF) D. Wessels
2 Request for Comments: 8976 P. Barber
3 Category: Standards Track Verisign
4 ISSN: 2070-1721 M. Weinberg
5 Amazon
6 W. Kumari
7 Google
8 W. Hardaker
9 USC/ISI
10 February 2021
11
12
13 Message Digest for DNS Zones
14
15 Abstract
16
17 This document describes a protocol and new DNS Resource Record that
18 provides a cryptographic message digest over DNS zone data at rest.
19 The ZONEMD Resource Record conveys the digest data in the zone
20 itself. When used in combination with DNSSEC, ZONEMD allows
21 recipients to verify the zone contents for data integrity and origin
22 authenticity. This provides assurance that received zone data
23 matches published data, regardless of how the zone data has been
24 transmitted and received. When used without DNSSEC, ZONEMD functions
25 as a checksum, guarding only against unintentional changes.
26
27 ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets
28 (DNS data with fine granularity), whereas ZONEMD protects a zone's
29 data as a whole, whether consumed by authoritative name servers,
30 recursive name servers, or any other applications.
31
32 As specified herein, ZONEMD is impractical for large, dynamic zones
33 due to the time and resources required for digest calculation.
34 However, the ZONEMD record is extensible so that new digest schemes
35 may be added in the future to support large, dynamic zones.
36
37 Status of This Memo
38
39 This is an Internet Standards Track document.
40
41 This document is a product of the Internet Engineering Task Force
42 (IETF). It represents the consensus of the IETF community. It has
43 received public review and has been approved for publication by the
44 Internet Engineering Steering Group (IESG). Further information on
45 Internet Standards is available in Section 2 of RFC 7841.
46
47 Information about the current status of this document, any errata,
48 and how to provide feedback on it may be obtained at
49 https://www.rfc-editor.org/info/rfc8976.
50
51 Copyright Notice
52
53 Copyright (c) 2021 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
55
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (https://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
65
66 Table of Contents
67
68 1. Introduction
69 1.1. Motivation
70 1.2. Alternative Approaches
71 1.3. Design Overview
72 1.4. Use Cases
73 1.4.1. Root Zone
74 1.4.2. Providers, Secondaries, and Anycast
75 1.4.3. Response Policy Zones
76 1.4.4. Centralized Zone Data Service
77 1.4.5. General Purpose Comparison Check
78 1.5. Terminology
79 2. The ZONEMD Resource Record
80 2.1. Non-apex ZONEMD Records
81 2.2. ZONEMD RDATA Wire Format
82 2.2.1. The Serial Field
83 2.2.2. The Scheme Field
84 2.2.3. The Hash Algorithm Field
85 2.2.4. The Digest Field
86 2.3. ZONEMD Presentation Format
87 2.4. ZONEMD Example
88 2.5. Including ZONEMD RRs in a Zone
89 3. Calculating the Digest
90 3.1. Add ZONEMD Placeholder
91 3.2. Optionally, Sign the Zone
92 3.3. Scheme-Specific Processing
93 3.3.1. The SIMPLE Scheme
94 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules
95 3.3.1.2. SIMPLE Scheme Digest Calculation
96 3.4. Update ZONEMD RR
97 4. Verifying Zone Digest
98 5. IANA Considerations
99 5.1. ZONEMD RRtype
100 5.2. ZONEMD Scheme
101 5.3. ZONEMD Hash Algorithms
102 6. Security Considerations
103 6.1. Using Zone Digest without DNSSEC
104 6.2. Attacks against the Zone Digest
105 6.3. Use of Multiple ZONEMD Hash Algorithms
106 6.4. DNSSEC Timing Considerations
107 6.5. Attacks Utilizing ZONEMD Queries
108 6.6. Resilience and Fragility
109 7. Performance Considerations
110 7.1. SIMPLE SHA384
111 8. Privacy Considerations
112 9. References
113 9.1. Normative References
114 9.2. Informative References
115 Appendix A. Example Zones with Digests
116 A.1. Simple EXAMPLE Zone
117 A.2. Complex EXAMPLE Zone
118 A.3. EXAMPLE Zone with Multiple Digests
119 A.4. The URI.ARPA Zone
120 A.5. The ROOT-SERVERS.NET Zone
121 Appendix B. Implementation Status
122 B.1. Authors' Implementation
123 B.2. Shane Kerr's Implementation
124 B.3. NIC Chile Lab's Implementation
125 Acknowledgments
126 Authors' Addresses
127
128 1. Introduction
129
130 In the DNS, a zone is the collection of authoritative resource
131 records (RRs) sharing a common origin ([RFC8499]). Zones are often
132 stored as files in the so-called "master file format" ([RFC1034]).
133 Zones are generally distributed among name servers using the zone
134 transfer (AXFR) ([RFC5936]) and incremental zone transfer (IXFR)
135 ([RFC1995]) protocols. They can also be distributed outside of the
136 DNS with any file transfer protocol such as FTP, HTTP, and rsync, or
137 even as email attachments. Currently, there is no standard way to
138 compute a hash or message digest for a stand-alone zone.
139
140 This document specifies an RR type that provides a cryptographic
141 message digest of the data in a zone. It allows a receiver of the
142 zone to verify the zone's integrity and authenticity when used in
143 combination with DNSSEC. The digest RR is a part of the zone itself,
144 allowing verification of the zone, no matter how it is transmitted.
145 The digest uses the wire format of zone data in a canonical ordering.
146 Thus, it is independent of presentation format such as whitespace,
147 capitalization, and comments.
148
149 This specification is OPTIONAL to implement by both publishers and
150 consumers of zone data.
151
152 1.1. Motivation
153
154 The primary motivation for this protocol enhancement is the desire to
155 verify the data integrity and origin authenticity of a stand-alone
156 zone, regardless of how it is transmitted. A consumer of zone data
157 should be able to verify that it is as published by the zone
158 operator.
159
160 Note, however, that integrity and authenticity can only be assured
161 when the zone is signed. DNSSEC provides three strong security
162 guarantees relevant to this protocol:
163
164 1. whether or not to expect DNSSEC records in the zone,
165
166 2. whether or not to expect a ZONEMD record in a signed zone, and
167
168 3. whether or not the ZONEMD record has been altered since it was
169 signed.
170
171 A secondary motivation is to provide the equivalent of a checksum,
172 allowing a zone recipient to check for unintended changes and
173 operational errors such as accidental truncation.
174
175 1.2. Alternative Approaches
176
177 One approach to preventing data tampering and corruption is to secure
178 the distribution channel. The DNS has a number of features that are
179 already used for channel security. Perhaps the most widely used is
180 DNS transaction signatures (TSIGs) ([RFC8945]). A TSIG uses shared
181 secret keys and a message digest to protect individual query and
182 response messages. It is generally used to authenticate and validate
183 UPDATE ([RFC2136]), AXFR ([RFC5936]), and IXFR ([RFC1995]) messages.
184
185 DNS Request and Transaction Signatures (SIG(0)) ([RFC2931]) is
186 another protocol extension that authenticates individual DNS
187 transactions. Whereas SIG records normally cover specific RR types,
188 SIG(0) is used to sign an entire DNS message. Unlike TSIG, SIG(0)
189 uses public key cryptography rather than shared secrets.
190
191 The Transport Layer Security protocol suite also provides channel
192 security. The DPRIVE Working Group is in the process of specifying
193 DNS Zone Transfer-over-TLS ([DPRIVE-XFR-OVER-TLS]). One can also
194 easily imagine the distribution of zones over HTTPS-enabled web
195 servers as well as DNS-over-HTTPS ([RFC8484]).
196
197 Unfortunately, the protections provided by these channel security
198 techniques are (in practice) ephemeral and are not retained after the
199 data transfer is complete. They ensure that the client receives the
200 data from the expected server and that the data sent by the server is
201 not modified during transmission. However, they do not guarantee
202 that the server transmits the data as originally published and do not
203 provide any methods to verify data that is read after transmission is
204 complete. For example, a name server loading saved zone data upon
205 restart cannot guarantee that the on-disk data has not been modified.
206 Such modification could be the result of an accidental corruption of
207 the file or perhaps an incomplete saving of the file
208 ([DISK-FULL-FAILURE]). For these reasons, it is preferable to
209 protect the integrity of the data itself.
210
211 Why not simply rely on DNSSEC, which provides certain data security
212 guarantees? For zones that are signed, a recipient could validate
213 all of the signed RRsets. Additionally, denial-of-existence records
214 prove that RRsets have not been added or removed. However,
215 delegations (non-apex NS records) are not signed by DNSSEC and
216 neither are any glue records. ZONEMD protects the integrity of
217 delegation, glue, and other records that are not otherwise covered by
218 DNSSEC. Furthermore, zones that employ NSEC3 with Opt-Out
219 ([RFC5155]) are susceptible to the removal or addition of names
220 between the signed nodes. Whereas DNSSEC primarily protects
221 consumers of DNS response messages, this protocol protects consumers
222 of zones.
223
224 There are existing tools and protocols that provide data security,
225 such as OpenPGP ([RFC4880]) and S/MIME ([RFC8551]). In fact, the
226 internic.net site publishes Pretty Good Privacy (PGP) signatures
227 alongside the root zone and other files available there. However,
228 this is a detached signature with no strong association to the
229 corresponding zone file other than its timestamp. Attached
230 signatures are of course possible, but these necessarily change the
231 format of the file being distributed; a zone signed with OpenPGP or
232 S/MIME no longer looks like a DNS zone and could not directly be
233 loaded into a name server. Once loaded, the signature data is lost,
234 so it cannot be further propagated.
235
236 It seems the desire for data security in DNS zones was envisioned as
237 far back as 1997. [RFC2065] is an obsoleted specification of the
238 first generation DNSSEC Security Extensions. It describes a zone
239 transfer signature, identified as the AXFR SIG, which is similar to
240 the technique proposed by this document. That is, it proposes
241 ordering all (signed) RRsets in a zone, hashing their contents, and
242 then signing the zone hash. The AXFR SIG is described only for use
243 during zone transfers. It did not postulate the need to validate
244 zone data distributed outside of the DNS. Furthermore, its
245 successor, [RFC2535], omits the AXFR SIG while at the same time
246 introducing an IXFR SIG. (Note: RFC 2535 was obsoleted by [RFC4033],
247 [RFC4034], and [RFC4035].)
248
249 1.3. Design Overview
250
251 This document specifies a new Resource Record type to convey a
252 message digest of the content of a zone. The digest is calculated at
253 the time of zone publication. If the zone is signed with DNSSEC, any
254 modifications of the digest can be detected. The procedures for
255 digest calculation and DNSSEC signing are similar. Both require data
256 to be processed in a well-defined order and format. It may be
257 possible to perform DNSSEC signing and digest calculation in
258 parallel.
259
260 The zone digest is designed to be used on zones that have infrequent
261 updates. As specified herein, the digest is recalculated over the
262 entire zone content each time the zone is updated. This
263 specification does not provide an efficient mechanism for updating
264 the digest on incremental updates of zone data. It is, however,
265 extensible so that future schemes may be defined to support efficient
266 incremental digest updates.
267
268 It is expected that verification of a zone digest will be implemented
269 in name server software. That is, a name server can verify the zone
270 data it was given and refuse to serve a zone that fails verification.
271 For signed zones, the name server needs a trust anchor to perform
272 DNSSEC validation. For signed non-root zones, the name server may
273 need to send queries to validate a chain of trust. Digest
274 verification could also be performed externally.
275
276 1.4. Use Cases
277
278 1.4.1. Root Zone
279
280 The root zone ([InterNIC]) is one of the most widely distributed DNS
281 zones on the Internet, served by more than 1000 separate instances
282 ([ROOT-SERVERS]) at the time of this writing. Additionally, many
283 organizations configure their own name servers to serve the root zone
284 locally. Reasons for doing so include privacy and reduced access
285 time. [RFC8806] describes one way to do this. As the root zone
286 spreads beyond its traditional deployment boundaries, the
287 verification of the completeness of the zone contents becomes more
288 important.
289
290 1.4.2. Providers, Secondaries, and Anycast
291
292 Since its very early days, the developers of the DNS recognized the
293 importance of secondary name servers and service diversity. However,
294 modern DNS service has complex provisioning that includes multiple
295 third-party providers ([RFC8901]) and hundreds of anycast instances
296 ([RFC3258]). Instead of a simple primary-to-secondary zone
297 distribution system, today it is possible to have multiple levels,
298 multiple parties, and multiple protocols involved in the distribution
299 of zone data. This complexity introduces new places for problems to
300 arise. The zone digest protects the integrity of data that flows
301 through such systems.
302
303 1.4.3. Response Policy Zones
304
305 A Response Policy Zone (RPZ) is "a mechanism to introduce a
306 customized policy in Domain Name System servers, so that recursive
307 resolvers return possibly modified results" ([RPZ]). The policy
308 information is carried inside specially constructed DNS zones. A
309 number of companies provide RPZ feeds, which are consumed by name
310 server and firewall products. While RPZs can be signed with DNSSEC,
311 the data is not queried directly and would not be subject to DNSSEC
312 validation.
313
314 1.4.4. Centralized Zone Data Service
315
316 ICANN operates the Centralized Zone Data Service ([CZDS]), which is a
317 repository of top-level domain zone files. Users that have been
318 granted access are then able to download zone data. Adding a zone
319 digest to these would provide CZDS users with assurances that the
320 data has not been modified between origination and retrieval. Note
321 that ZONEMD could be added to zone data supplied to CZDS without
322 requiring it to be present in the zone data served by production name
323 servers, since the digest is inherently attached to the specific copy
324 of the zone.
325
326 1.4.5. General Purpose Comparison Check
327
328 Since the zone digest calculation does not depend on presentation
329 format, it could be used to compare multiple copies of a zone
330 received from different sources, or copies generated by different
331 processes. In this case, it serves as a checksum and can be useful
332 even for unsigned zones.
333
334 1.5. Terminology
335
336 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
337 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
338 "OPTIONAL" in this document are to be interpreted as described in
339 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
340 capitals, as shown here.
341
342 The terms Private Use, Reserved, Unassigned, and Specification
343 Required are to be interpreted as defined in [RFC8126].
344
345 2. The ZONEMD Resource Record
346
347 This section describes the ZONEMD Resource Record, including its
348 fields, wire format, and presentation format. The Type value for the
349 ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
350 the resource record consists of four fields: Serial, Scheme, Hash
351 Algorithm, and Digest.
352
353 2.1. Non-apex ZONEMD Records
354
355 This document specifies ZONEMD RRs located at the zone apex. Non-
356 apex ZONEMD RRs are not forbidden, but have no meaning in this
357 specification. Non-apex ZONEMD RRs MUST NOT be used for
358 verification.
359
360 During digest calculation, non-apex ZONEMD RRs are treated as
361 ordinary RRs. They are digested as is, and the RR is not replaced by
362 a placeholder RR.
363
364 Unless explicitly stated otherwise, "ZONEMD" always refers to apex
365 records throughout this document.
366
367 2.2. ZONEMD RDATA Wire Format
368
369 The ZONEMD RDATA wire format is encoded as follows:
370
371 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
372 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
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374 | Serial |
375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376 | Scheme |Hash Algorithm | |
377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
378 | Digest |
379 / /
380 / /
381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
382
383 2.2.1. The Serial Field
384
385 The Serial field is a 32-bit unsigned integer in network byte order.
386 It is the serial number from the zone's SOA record ([RFC1035],
387 Section 3.3.13) for which the zone digest was generated.
388
389 It is included here to clearly bind the ZONEMD RR to a particular
390 version of the zone's content. Without the serial number, a stand-
391 alone ZONEMD digest has no obvious association to any particular
392 instance of a zone.
393
394 2.2.2. The Scheme Field
395
396 The Scheme field is an 8-bit unsigned integer that identifies the
397 methods by which data is collated and presented as input to the
398 hashing function.
399
400 Herein, SIMPLE, with Scheme value 1, is the only standardized Scheme
401 defined for ZONEMD records and it MUST be supported by
402 implementations. The "ZONEMD Schemes" registry is further described
403 in Section 5.
404
405 Scheme values 240-254 are allocated for Private Use.
406
407 2.2.3. The Hash Algorithm Field
408
409 The Hash Algorithm field is an 8-bit unsigned integer that identifies
410 the cryptographic hash algorithm used to construct the digest.
411
412 Herein, SHA384 ([RFC6234]), with Hash Algorithm value 1, is the only
413 standardized Hash Algorithm defined for ZONEMD records that MUST be
414 supported by implementations. When SHA384 is used, the size of the
415 Digest field is 48 octets. The result of the SHA384 digest algorithm
416 MUST NOT be truncated, and the entire 48-octet digest is published in
417 the ZONEMD record.
418
419 SHA512 ([RFC6234]), with Hash Algorithm value 2, is also defined for
420 ZONEMD records and SHOULD be supported by implementations. When
421 SHA512 is used, the size of the Digest field is 64 octets. The
422 result of the SHA512 digest algorithm MUST NOT be truncated, and the
423 entire 64-octet digest is published in the ZONEMD record.
424
425 Hash Algorithm values 240-254 are allocated for Private Use.
426
427 The "ZONEMD Hash Algorithms" registry is further described in
428 Section 5.
429
430 2.2.4. The Digest Field
431
432 The Digest field is a variable-length sequence of octets containing
433 the output of the hash algorithm. The length of the Digest field is
434 determined by deducting the fixed size of the Serial, Scheme, and
435 Hash Algorithm fields from the RDATA size in the ZONEMD RR header.
436
437 The Digest field MUST NOT be shorter than 12 octets. Digests for the
438 SHA384 and SHA512 hash algorithms specified herein are never
439 truncated. Digests for future hash algorithms MAY be truncated but
440 MUST NOT be truncated to a length that results in less than 96 bits
441 (12 octets) of equivalent strength.
442
443 Section 3 describes how to calculate the digest for a zone.
444 Section 4 describes how to use the digest to verify the contents of a
445 zone.
446
447 2.3. ZONEMD Presentation Format
448
449 The presentation format of the RDATA portion is as follows:
450
451 * The Serial field is represented as an unsigned decimal integer.
452
453 * The Scheme field is represented as an unsigned decimal integer.
454
455 * The Hash Algorithm field is represented as an unsigned decimal
456 integer.
457
458 * The Digest is represented as a sequence of case-insensitive
459 hexadecimal digits. Whitespace is allowed within the hexadecimal
460 text.
461
462 2.4. ZONEMD Example
463
464 The following example shows a ZONEMD RR in presentation format:
465
466 example.com. 86400 IN ZONEMD 2018031500 1 1 (
467 FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
468 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
469
470 2.5. Including ZONEMD RRs in a Zone
471
472 The zone operator chooses an appropriate hash algorithm and scheme
473 and includes the calculated zone digest in the apex ZONEMD RRset.
474 The zone operator MAY choose any of the defined hash algorithms and
475 schemes, including the Private Use code points.
476
477 The ZONEMD RRset MAY contain multiple records to support algorithm
478 agility ([BCP201]). When multiple ZONEMD RRs are present, each MUST
479 specify a unique Scheme and Hash Algorithm tuple. It is RECOMMENDED
480 that a zone include only one ZONEMD RR, unless the zone operator is
481 in the process of transitioning to a new scheme or hash algorithm.
482
483 3. Calculating the Digest
484
485 The algorithm described in this section is designed for the common
486 case of offline DNSSEC signing. Slight deviations may be permitted
487 or necessary in other situations, such as with unsigned zones or
488 online DNSSEC signing. Implementations that deviate from the
489 described algorithm are advised to ensure that it produces ZONEMD
490 RRs, signatures, and denial-of-existence records that are identical
491 to the ones generated by this procedure.
492
493 3.1. Add ZONEMD Placeholder
494
495 In preparation for calculating the zone digest(s), any existing
496 ZONEMD records (and covering RRSIGs) at the zone apex are first
497 deleted.
498
499 Prior to calculation of the digest, and prior to signing with DNSSEC,
500 one or more placeholder ZONEMD records are added to the zone apex.
501 This ensures that denial-of-existence (NSEC, NSEC3) records are
502 created correctly if the zone is signed with DNSSEC. If placeholders
503 were not added prior to signing, the later addition of ZONEMD records
504 would also require updating the Type Bit Maps field of any apex NSEC/
505 NSEC3 RRs, which then invalidates the calculated digest value.
506
507 When multiple ZONEMD RRs are published in the zone, e.g., during an
508 algorithm rollover, each MUST specify a unique Scheme and Hash
509 Algorithm tuple.
510
511 It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of
512 the Start of Authority (SOA). However, the TTL of the ZONEMD record
513 may be safely ignored during verification in all cases.
514
515 In the placeholder record, the Serial field is set to the current SOA
516 Serial. The Scheme field is set to the value for the chosen
517 collation scheme. The Hash Algorithm field is set to the value for
518 the chosen hash algorithm. Since apex ZONEMD records are excluded
519 from digest calculation, the value of the Digest field does not
520 matter at this point in the process.
521
522 3.2. Optionally, Sign the Zone
523
524 Following the addition of placeholder records, the zone may be signed
525 with DNSSEC. When the digest calculation is complete, and the ZONEMD
526 record is updated, the signature(s) for the ZONEMD RRset MUST be
527 recalculated and updated as well. Therefore, the signer is not
528 required to calculate a signature over the placeholder record at this
529 step in the process, but it is harmless to do so.
530
531 3.3. Scheme-Specific Processing
532
533 Herein, only the SIMPLE collation scheme is defined. Additional
534 schemes may be defined in future updates to this document.
535
536 3.3.1. The SIMPLE Scheme
537
538 For the SIMPLE scheme, the digest is calculated over the zone as a
539 whole. This means that a change to a single RR in the zone requires
540 iterating over all RRs in the zone to recalculate the digest. SIMPLE
541 is a good choice for zones that are small and/or stable, but it is
542 probably not good for zones that are large and/or dynamic.
543
544 Calculation of a zone digest requires RRs to be processed in a
545 consistent format and ordering. This specification uses DNSSEC's
546 canonical on-the-wire RR format (without name compression) and
547 ordering as specified in Sections 6.1, 6.2, and 6.3 of [RFC4034] with
548 the additional provision that RRsets having the same owner name MUST
549 be numerically ordered, in ascending order, by their numeric RR TYPE.
550
551 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules
552
553 When iterating over records in the zone, the following inclusion/
554 exclusion rules apply:
555
556 * All records in the zone, including glue records, MUST be included
557 unless excluded by a subsequent rule.
558
559 * Occluded data ([RFC5936], Section 3.5) MUST be included.
560
561 * If there are duplicate RRs with equal owner, class, type, and
562 RDATA, only one instance is included ([RFC4034], Section 6.3) and
563 the duplicates MUST be omitted.
564
565 * The placeholder apex ZONEMD RR(s) MUST NOT be included.
566
567 * If the zone is signed, DNSSEC RRs MUST be included, except:
568
569 * The RRSIG covering the apex ZONEMD RRset MUST NOT be included
570 because the RRSIG will be updated after all digests have been
571 calculated.
572
573 3.3.1.2. SIMPLE Scheme Digest Calculation
574
575 A zone digest using the SIMPLE scheme is calculated by concatenating
576 all RRs in the zone, in the format and order described in
577 Section 3.3.1 subject to the inclusion/exclusion rules described in
578 Section 3.3.1.1, and then applying the chosen hash algorithm:
579
580 digest = hash( RR(1) | RR(2) | RR(3) | ... )
581
582 where "|" denotes concatenation.
583
584 3.4. Update ZONEMD RR
585
586 The calculated zone digest is inserted into the placeholder ZONEMD
587 RR. Repeat for each digest if multiple digests are to be published.
588
589 If the zone is signed with DNSSEC, the RRSIG record(s) covering the
590 ZONEMD RRset MUST then be added or updated. Because the ZONEMD
591 placeholder was added prior to signing, the zone will already have
592 the appropriate denial-of-existence (NSEC, NSEC3) records.
593
594 Some DNSSEC implementations (especially "online signing") might
595 update the SOA serial number whenever a new signature is made. To
596 preserve the calculated digest, generation of a ZONEMD signature MUST
597 NOT also result in a change to the SOA serial number. The ZONEMD RR
598 and the matching SOA MUST be published at the same time.
599
600 4. Verifying Zone Digest
601
602 The recipient of a zone that has a ZONEMD RR verifies the zone by
603 calculating the digest as follows:
604
605 | Note: If multiple ZONEMD RRs are present in the zone, e.g.,
606 | during an algorithm rollover, a match using any one of the
607 | recipient's supported Schemes and Hash Algorithms is sufficient
608 | to verify the zone. The verifier MAY ignore a ZONEMD RR if its
609 | Scheme and Hash Algorithm violates local policy.
610
611 1. The verifier MUST first determine whether or not to expect DNSSEC
612 records in the zone. By examining locally configured trust
613 anchors and, if necessary, querying for and validating Delegation
614 Signer (DS) RRs in the parent zone, the verifier knows whether or
615 not the zone to be verified should include DNSSEC keys and
616 signatures. For zones where signatures are not expected, or if
617 DNSSEC validation is not performed, digest verification continues
618 at step 4 below.
619
620 2. For zones where signatures are expected, the existence of the
621 apex ZONEMD record MUST be validated. If the DNSSEC data proves
622 the ZONEMD RRset does not exist, digest verification cannot
623 occur. If the DNSSEC data proves the ZONEMD does exist, but is
624 not found in the zone, digest verification MUST NOT be considered
625 successful.
626
627 3. For zones where signatures are expected, the SOA and ZONEMD
628 RRsets MUST have valid signatures, chaining up to a trust anchor.
629 If DNSSEC validation of the SOA or ZONEMD RRsets fails, digest
630 verification MUST NOT be considered successful.
631
632 4. When multiple ZONEMD RRs are present, each MUST specify a unique
633 Scheme and Hash Algorithm tuple. If the ZONEMD RRset contains
634 more than one RR with the same Scheme and Hash Algorithm, digest
635 verification for those ZONEMD RRs MUST NOT be considered
636 successful.
637
638 5. Loop over all apex ZONEMD RRs and perform the following steps:
639
640 a. The SOA Serial field MUST exactly match the ZONEMD Serial
641 field. If the fields do not match, digest verification MUST
642 NOT be considered successful with this ZONEMD RR.
643
644 b. The Scheme field MUST be checked. If the verifier does not
645 support the given scheme, verification MUST NOT be considered
646 successful with this ZONEMD RR.
647
648 c. The Hash Algorithm field MUST be checked. If the verifier
649 does not support the given hash algorithm, verification MUST
650 NOT be considered successful with this ZONEMD RR.
651
652 d. The Digest field size MUST be checked. If the size of the
653 given Digest field is smaller than 12 octets, or if the size
654 is not equal to the size expected for the corresponding Hash
655 Algorithm, verification MUST NOT be considered successful
656 with this ZONEMD RR.
657
658 e. The zone digest is computed over the zone data as described
659 in Section 3.3 using the Scheme and Hash Algorithm for the
660 current ZONEMD RR.
661
662 f. The computed digest is compared to the received digest. If
663 the two digest values match, verification is considered
664 successful. Otherwise, verification MUST NOT be considered
665 successful for this ZONEMD RR.
666
667 Each time zone verification is performed, the verifier SHOULD report
668 the status as either successful or unsuccessful. When unsuccessful,
669 the verifier SHOULD report the reason(s) that verification did not
670 succeed.
671
672 5. IANA Considerations
673
674 5.1. ZONEMD RRtype
675
676 This document defines a new DNS RR type, ZONEMD, whose value 63 has
677 been allocated by IANA from the "Resource Record (RR) TYPEs"
678 subregistry of the "Domain Name System (DNS) Parameters" registry:
679
680 Type: ZONEMD
681 Value: 63
682 Meaning: Message Digest Over Zone Data
683 Reference: [RFC8976]
684
685 5.2. ZONEMD Scheme
686
687 IANA has created a new subregistry in the "Domain Name System (DNS)
688 Parameters" registry as follows:
689
690 Registry Name: ZONEMD Schemes
691 Registration Procedure: Specification Required
692 Reference: [RFC8976]
693
694 +=========+=========================+==========+===========+
695 | Value | Description | Mnemonic | Reference |
696 +=========+=========================+==========+===========+
697 | 0 | Reserved | | [RFC8976] |
698 +---------+-------------------------+----------+-----------+
699 | 1 | Simple ZONEMD collation | SIMPLE | [RFC8976] |
700 +---------+-------------------------+----------+-----------+
701 | 2-239 | Unassigned | | |
702 +---------+-------------------------+----------+-----------+
703 | 240-254 | Private Use | N/A | [RFC8976] |
704 +---------+-------------------------+----------+-----------+
705 | 255 | Reserved | | [RFC8976] |
706 +---------+-------------------------+----------+-----------+
707
708 Table 1: ZONEMD Scheme Registry
709
710 5.3. ZONEMD Hash Algorithms
711
712 IANA has created a new subregistry in the "Domain Name System (DNS)
713 Parameters" registry as follows:
714
715 Registry Name: ZONEMD Hash Algorithms
716 Registration Procedure: Specification Required
717 Reference: [RFC8976]
718
719 +=========+=============+==========+===========+
720 | Value | Description | Mnemonic | Reference |
721 +=========+=============+==========+===========+
722 | 0 | Reserved | | [RFC8976] |
723 +---------+-------------+----------+-----------+
724 | 1 | SHA-384 | SHA384 | [RFC8976] |
725 +---------+-------------+----------+-----------+
726 | 2 | SHA-512 | SHA512 | [RFC8976] |
727 +---------+-------------+----------+-----------+
728 | 3-239 | Unassigned | | |
729 +---------+-------------+----------+-----------+
730 | 240-254 | Private Use | N/A | [RFC8976] |
731 +---------+-------------+----------+-----------+
732 | 255 | Reserved | | [RFC8976] |
733 +---------+-------------+----------+-----------+
734
735 Table 2: ZONEMD Hash Algorithms Registry
736
737 6. Security Considerations
738
739 6.1. Using Zone Digest without DNSSEC
740
741 Users of ZONEMD with unsigned zones are advised that it provides no
742 real protection against attacks. While zone digests can be used in
743 the absence of DNSSEC, this only provides protection against
744 accidental zone corruption such as transmission errors and
745 truncation. When used in this manner, it effectively serves only as
746 a checksum. For zones not signed with DNSSEC, an attacker can make
747 any zone modifications appear to be valid by recomputing the Digest
748 field of a ZONEMD RR.
749
750 6.2. Attacks against the Zone Digest
751
752 An attacker, whose goal is to modify zone content before it is used
753 by the victim, may consider a number of different approaches.
754
755 The attacker might perform a downgrade attack to an unsigned zone.
756 This is why Section 4 talks about determining whether or not to
757 expect DNSSEC signatures for the zone in step 1.
758
759 The attacker might perform a downgrade attack by removing one or more
760 ZONEMD records. Such a removal is detectable only with DNSSEC
761 validation and is why Section 4 talks about checking denial-of-
762 existence proofs in step 2 and signature validation in step 3.
763
764 The attacker might alter the Scheme, Hash Algorithm, or Digest fields
765 of the ZONEMD record. Such modifications are detectable only with
766 DNSSEC validation.
767
768 As stated in [BCP201], cryptographic algorithms age and become weaker
769 as cryptanalysis techniques and computing resources improve with
770 time. Implementors and publishers of zone digests should anticipate
771 the need for algorithm agility on long timescales.
772
773 6.3. Use of Multiple ZONEMD Hash Algorithms
774
775 When a zone publishes multiple ZONEMD RRs, the overall security is
776 only as good as the weakest hash algorithm in use. For this reason,
777 Section 2 recommends only publishing multiple ZONEMD RRs when
778 transitioning to a new scheme or hash algorithm. Once the transition
779 is complete, the old scheme or hash algorithm should be removed from
780 the ZONEMD RRset.
781
782 6.4. DNSSEC Timing Considerations
783
784 As with all DNSSEC signatures, the ability to perform signature
785 validation of a ZONEMD record is limited in time. If the DS
786 record(s) or trust anchors for the zone to be verified are no longer
787 available, the recipient cannot validate the ZONEMD RRset. This
788 could happen even if the ZONEMD signature is still current (not
789 expired), since the zone's DS record(s) may have been withdrawn
790 following a Key Signing Key (KSK) rollover.
791
792 For zones where it may be important to validate a ZONEMD RRset
793 through its entire signature validity period, the zone operator
794 should ensure that KSK rollover timing takes this into consideration.
795
796 6.5. Attacks Utilizing ZONEMD Queries
797
798 Nothing in this specification prevents clients from making, and
799 servers from responding to, ZONEMD queries. Servers SHOULD NOT
800 calculate zone digests dynamically (for each query) as this can be
801 used as a CPU resource exhaustion attack.
802
803 ZONEMD responses could be used in a distributed denial-of-service
804 amplification attack. The ZONEMD RR is moderately sized, much like
805 the DS RR. A single ZONEMD RR contributes approximately 65 to 95
806 octets to a DNS response for digest types defined herein. Other RR
807 types, such as DNS Public Key (DNSKEY), can result in larger
808 amplification effects.
809
810 6.6. Resilience and Fragility
811
812 ZONEMD is used to detect incomplete or corrupted zone data prior to
813 its use, thereby increasing resilience by not using corrupt data, but
814 also introduces some denial-of-service fragility by making good data
815 in a zone unavailable if some other data is missing or corrupt.
816 Publishers and consumers of zones containing ZONEMD records should be
817 aware of these trade-offs. While the intention is to secure the zone
818 data, misconfigurations or implementation bugs are generally
819 indistinguishable from intentional tampering and could lead to
820 service failures when verification is performed automatically.
821
822 Zone publishers may want to deploy ZONEMD gradually perhaps by
823 utilizing one of the Private Use hash algorithm code points listed in
824 Section 5.3. Similarly, recipients may want to initially configure
825 verification failures only as a warning, and later as an error after
826 gaining experience and confidence with the feature.
827
828 7. Performance Considerations
829
830 This section is provided to make zone publishers aware of the
831 performance requirements and implications of including ZONEMD RRs in
832 a zone.
833
834 7.1. SIMPLE SHA384
835
836 As mentioned previously, the SIMPLE scheme may be impractical for use
837 in zones that are either large or highly dynamic. Zone publishers
838 should carefully consider the use of ZONEMD in such zones since it
839 might cause consumers of zone data (e.g., secondary name servers) to
840 expend resources on digest calculation. For such use cases, it is
841 recommended that ZONEMD only be used when digest calculation time is
842 significantly less than propagation times and update intervals.
843
844 The authors' implementation (Appendix B.1) includes an option to
845 record and report CPU usage of its operation. The software was used
846 to generate digests for more than 800 Top-Level Domain (TLD) zones
847 available from [CZDS]. The table below summarizes the results for
848 the SIMPLE scheme and SHA384 hash algorithm grouped by zone size.
849 The Rate column is the mean amount of time per RR to calculate the
850 digest, running on commodity hardware in early 2020.
851
852 +=====================+================+
853 | Zone Size (RRs) | Rate (msec/RR) |
854 +=====================+================+
855 | 10 - 99 | 0.00683 |
856 +---------------------+----------------+
857 | 100 - 999 | 0.00551 |
858 +---------------------+----------------+
859 | 1000 - 9999 | 0.00505 |
860 +---------------------+----------------+
861 | 10000 - 99999 | 0.00602 |
862 +---------------------+----------------+
863 | 100000 - 999999 | 0.00845 |
864 +---------------------+----------------+
865 | 1000000 - 9999999 | 0.0108 |
866 +---------------------+----------------+
867 | 10000000 - 99999999 | 0.0148 |
868 +---------------------+----------------+
869
870 Table 3
871
872 For example, based on the above table, it takes approximately 0.13
873 seconds to calculate a SIMPLE SHA384 digest for a zone with 22,000
874 RRs, and about 2.5 seconds for a zone with 300,000 RRs.
875
876 These benchmarks attempt to emulate a worst-case scenario and take
877 into account the time required to canonicalize the zone for
878 processing. Each of the 800+ zones were measured three times and
879 then averaged, with a different random sorting of the input data
880 prior to each measurement.
881
882 8. Privacy Considerations
883
884 This specification has no impact on user privacy.
885
886 9. References
887
888 9.1. Normative References
889
890 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
891 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
892 <https://www.rfc-editor.org/info/rfc1034>.
893
894 [RFC1035] Mockapetris, P., "Domain names - implementation and
895 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
896 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
897
898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
899 Requirement Levels", BCP 14, RFC 2119,
900 DOI 10.17487/RFC2119, March 1997,
901 <https://www.rfc-editor.org/info/rfc2119>.
902
903 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
904 Rose, "Resource Records for the DNS Security Extensions",
905 RFC 4034, DOI 10.17487/RFC4034, March 2005,
906 <https://www.rfc-editor.org/info/rfc4034>.
907
908 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
909 (SHA and SHA-based HMAC and HKDF)", RFC 6234,
910 DOI 10.17487/RFC6234, May 2011,
911 <https://www.rfc-editor.org/info/rfc6234>.
912
913 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
914 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
915 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
916
917 9.2. Informative References
918
919 [BCP201] Housley, R., "Guidelines for Cryptographic Algorithm
920 Agility and Selecting Mandatory-to-Implement Algorithms",
921 BCP 201, RFC 7696, November 2015.
922
923 <https://www.rfc-editor.org/info/bcp201>
924
925 [CZDS] Internet Corporation for Assigned Names and Numbers
926 (ICANN), "Centralized Zone Data Service", October 2018,
927 <https://czds.icann.org/>.
928
929 [DISK-FULL-FAILURE]
930 DENIC, "Background of the Partial Failure of the Name
931 Service for .de Domains", May 2010,
932 <https://web.archive.org/web/20100618032705/
933 https://www.denic.de/en/denic-in-dialogue/news/2733.html>.
934
935 [DNS-TOOLS]
936 "DNS tools for zone signature (file, pkcs11-hsm) and
937 validation, and zone digest (ZONEMD)", commit 489de21,
938 December 2020, <https://github.com/niclabs/dns-tools>.
939
940 [DPRIVE-XFR-OVER-TLS]
941 Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
942 Mankin, "DNS Zone Transfer-over-TLS", Work in Progress,
943 Internet-Draft, draft-ietf-dprive-xfr-over-tls-05, 20
944 January 2021, <https://tools.ietf.org/html/draft-ietf-
945 dprive-xfr-over-tls-05>.
946
947 [InterNIC] InterNIC, "Index of ftp://rs.internic.net/", May 2018,
948 <ftp://ftp.internic.net/domain/>.
949
950 [LDNS-ZONE-DIGEST]
951 "Implementation of Message Digests for DNS Zones using the
952 ldns library", commit 71c0cd1, January 2021,
953 <https://github.com/verisign/ldns-zone-digest>.
954
955 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
956 DOI 10.17487/RFC1995, August 1996,
957 <https://www.rfc-editor.org/info/rfc1995>.
958
959 [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System
960 Security Extensions", RFC 2065, DOI 10.17487/RFC2065,
961 January 1997, <https://www.rfc-editor.org/info/rfc2065>.
962
963 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
964 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
965 RFC 2136, DOI 10.17487/RFC2136, April 1997,
966 <https://www.rfc-editor.org/info/rfc2136>.
967
968 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
969 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
970 <https://www.rfc-editor.org/info/rfc2535>.
971
972 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
973 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
974 2000, <https://www.rfc-editor.org/info/rfc2931>.
975
976 [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
977 Shared Unicast Addresses", RFC 3258, DOI 10.17487/RFC3258,
978 April 2002, <https://www.rfc-editor.org/info/rfc3258>.
979
980 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
981 Rose, "DNS Security Introduction and Requirements",
982 RFC 4033, DOI 10.17487/RFC4033, March 2005,
983 <https://www.rfc-editor.org/info/rfc4033>.
984
985 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
986 Rose, "Protocol Modifications for the DNS Security
987 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
988 <https://www.rfc-editor.org/info/rfc4035>.
989
990 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
991 Thayer, "OpenPGP Message Format", RFC 4880,
992 DOI 10.17487/RFC4880, November 2007,
993 <https://www.rfc-editor.org/info/rfc4880>.
994
995 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
996 Security (DNSSEC) Hashed Authenticated Denial of
997 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
998 <https://www.rfc-editor.org/info/rfc5155>.
999
1000 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
1001 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
1002 <https://www.rfc-editor.org/info/rfc5936>.
1003
1004 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1005 Writing an IANA Considerations Section in RFCs", BCP 26,
1006 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1007 <https://www.rfc-editor.org/info/rfc8126>.
1008
1009 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
1010 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
1011 <https://www.rfc-editor.org/info/rfc8484>.
1012
1013 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1014 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
1015 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
1016
1017 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
1018 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
1019 Message Specification", RFC 8551, DOI 10.17487/RFC8551,
1020 April 2019, <https://www.rfc-editor.org/info/rfc8551>.
1021
1022 [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
1023 a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
1024 <https://www.rfc-editor.org/info/rfc8806>.
1025
1026 [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
1027 Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
1028 DOI 10.17487/RFC8901, September 2020,
1029 <https://www.rfc-editor.org/info/rfc8901>.
1030
1031 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
1032 Gudmundsson, O., and B. Wellington, "Secret Key
1033 Transaction Authentication for DNS (TSIG)", STD 93,
1034 RFC 8945, DOI 10.17487/RFC8945, November 2020,
1035 <https://www.rfc-editor.org/info/rfc8945>.
1036
1037 [ROOT-SERVERS]
1038 Root Server Operators, "root-servers.org", July 2018,
1039 <https://www.root-servers.org/>.
1040
1041 [RPZ] Wikipedia, "Response policy zone", May 2020,
1042 <https://en.wikipedia.org/w/
1043 index.php?title=Response_policy_zone&oldid=960043728>.
1044
1045 [ZONE-DIGEST-HACKATHON]
1046 "Prototype implementation of ZONEMD for the IETF 102
1047 hackathon", commit 76ad7a7, August 2019,
1048 <https://github.com/shane-kerr/ZoneDigestHackathon>.
1049
1050 [ZONE-DIGEST-TESTS]
1051 IETF, "RFC 8976 ZONEMD Test Cases", January 2021,
1052 <https://trac.ietf.org/trac/dnsop/wiki/
1053 RFC8976ZONEMDTestCases>.
1054
1055 Appendix A. Example Zones with Digests
1056
1057 This appendix contains example zones with accurate ZONEMD records.
1058 These can be used to verify an implementation of the zone digest
1059 protocol. Additional and more extensive test cases can be found via
1060 the ZONEMD Tests Wiki ([ZONE-DIGEST-TESTS]) maintained by the IETF
1061 DNSOP Working Group.
1062
1063 A.1. Simple EXAMPLE Zone
1064
1065 Here, the EXAMPLE zone contains an SOA record, NS and glue records,
1066 and a ZONEMD record.
1067
1068 example. 86400 IN SOA ns1 admin 2018031900 (
1069 1800 900 604800 86400 )
1070 86400 IN NS ns1
1071 86400 IN NS ns2
1072 86400 IN ZONEMD 2018031900 1 1 (
1073 c68090d90a7aed71
1074 6bc459f9340e3d7c
1075 1370d4d24b7e2fc3
1076 a1ddc0b9a87153b9
1077 a9713b3c9ae5cc27
1078 777f98b8e730044c )
1079 ns1 3600 IN A 203.0.113.63
1080 ns2 3600 IN AAAA 2001:db8::63
1081
1082 A.2. Complex EXAMPLE Zone
1083
1084 Here, the EXAMPLE zone contains duplicate RRs, an occluded RR,
1085 uppercase names, a wildcard, a multi-record RRset, a non-apex ZONEMD
1086 RR, and one out-of-zone RR.
1087
1088 example. 86400 IN SOA ns1 admin 2018031900 (
1089 1800 900 604800 86400 )
1090 86400 IN NS ns1
1091 86400 IN NS ns2
1092 86400 IN ZONEMD 2018031900 1 1 (
1093 a3b69bad980a3504
1094 e1cffcb0fd6397f9
1095 3848071c93151f55
1096 2ae2f6b1711d4bd2
1097 d8b39808226d7b9d
1098 b71e34b72077f8fe )
1099 ns1 3600 IN A 203.0.113.63
1100 NS2 3600 IN AAAA 2001:db8::63
1101 occluded.sub 7200 IN TXT "I'm occluded but must be digested"
1102 sub 7200 IN NS ns1
1103 duplicate 300 IN TXT "I must be digested just once"
1104 duplicate 300 IN TXT "I must be digested just once"
1105 foo.test. 555 IN TXT "out-of-zone data must be excluded"
1106 UPPERCASE 3600 IN TXT "canonicalize uppercase owner names"
1107 * 777 IN PTR dont-forget-about-wildcards
1108 mail 3600 IN MX 20 MAIL1
1109 mail 3600 IN MX 10 Mail2.Example.
1110 sortme 3600 IN AAAA 2001:db8::5:61
1111 sortme 3600 IN AAAA 2001:db8::3:62
1112 sortme 3600 IN AAAA 2001:db8::4:63
1113 sortme 3600 IN AAAA 2001:db8::1:65
1114 sortme 3600 IN AAAA 2001:db8::2:64
1115 non-apex 900 IN ZONEMD 2018031900 1 1 (
1116 616c6c6f77656420
1117 6275742069676e6f
1118 7265642e20616c6c
1119 6f77656420627574
1120 2069676e6f726564
1121 2e20616c6c6f7765 )
1122
1123 A.3. EXAMPLE Zone with Multiple Digests
1124
1125 Here, the EXAMPLE zone contains multiple ZONEMD records. It has both
1126 SHA384 and SHA512 digests using the SIMPLE scheme. It also includes
1127 ZONEMD records with Scheme and Hash Algorithm values in the private
1128 range (240-254). These additional private-range digests are not
1129 verifiable.
1130
1131 example. 86400 IN SOA ns1 admin 2018031900 (
1132 1800 900 604800 86400 )
1133 example. 86400 IN NS ns1.example.
1134 example. 86400 IN NS ns2.example.
1135 example. 86400 IN ZONEMD 2018031900 1 1 (
1136 62e6cf51b02e54b9
1137 b5f967d547ce4313
1138 6792901f9f88e637
1139 493daaf401c92c27
1140 9dd10f0edb1c56f8
1141 080211f8480ee306 )
1142 example. 86400 IN ZONEMD 2018031900 1 2 (
1143 08cfa1115c7b948c
1144 4163a901270395ea
1145 226a930cd2cbcf2f
1146 a9a5e6eb85f37c8a
1147 4e114d884e66f176
1148 eab121cb02db7d65
1149 2e0cc4827e7a3204
1150 f166b47e5613fd27 )
1151 example. 86400 IN ZONEMD 2018031900 1 240 (
1152 e2d523f654b9422a
1153 96c5a8f44607bbee )
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
1154 example. 86400 IN ZONEMD 2018031900 241 1 (
1155 e1846540e33a9e41
1156 89792d18d5d131f6
1157 05fc283e )
1158 ns1.example. 3600 IN A 203.0.113.63
1159 ns2.example. 86400 IN TXT "This example has multiple digests"
1160 NS2.EXAMPLE. 3600 IN AAAA 2001:db8::63
1161
1162 A.4. The URI.ARPA Zone
1163
1164 The following sample zone is the URI.ARPA zone retrieved 2021-01-21.
1165 Note this sample zone has been re-signed with unpublished keys, so
1166 that the added ZONEMD RR also has a signature.
1167
1168 uri.arpa. 3600 IN SOA sns.dns.icann.org. (
1169 noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
1170 uri.arpa. 3600 IN RRSIG SOA 8 2 3600 (
1171 20210217232440 20210120232440 37444 uri.arpa.
1172 GzQw+QzwLDJr13REPGVmpEChjD1D2XlX0ie1DnWHpgaEw1E/dhs3lCN3+B
1173 mHd4Kx3tffTRgiyq65HxR6feQ5v7VmAifjyXUYB1DZur1eP5q0Ms2ygCB3
1174 byoeMgCNsFS1oKZ2LdzNBRpy3oace8xQn1SpmHGfyrsgg+WbHKCT1dY= )
1175 uri.arpa. 86400 IN NS a.iana-servers.net.
1176 uri.arpa. 86400 IN NS b.iana-servers.net.
1177 uri.arpa. 86400 IN NS c.iana-servers.net.
1178 uri.arpa. 86400 IN NS ns2.lacnic.net.
1179 uri.arpa. 86400 IN NS sec3.apnic.net.
1180 uri.arpa. 86400 IN RRSIG NS 8 2 86400 (
1181 20210217232440 20210120232440 37444 uri.arpa.
1182 M+Iei2lcewWGaMtkPlrhM9FpUAHXFkCHTVpeyrjxjEONeNgKtHZor5e4V4
1183 qJBOzNqo8go/qJpWlFBm+T5Hn3asaBZVstFIYky38/C8UeRLPKq1hTTHAR
1184 YUlFrexr5fMtSUAVOgOQPSBfH3xBq/BgSccTdRb9clD+HE7djpqrLS4= )
1185 uri.arpa. 600 IN MX 10 pechora.icann.org.
1186 uri.arpa. 600 IN RRSIG MX 8 2 600 (
1187 20210217232440 20210120232440 37444 uri.arpa.
1188 kQAJQivmv6A5hqYBK8h6Z13ESY69gmosXwKI6WE09I8RFetfrxr24ecdnY
1189 d0lpnDtgNNSoHkYRSOoB+C4+zuJsoyAAzGo9uoWMWj97/2xeGhf3PTC9me
1190 Q9Ohi6hul9By7OR76XYmGhdWX8PBi60RUmZ1guslFBfQ8izwPqzuphs= )
1191 uri.arpa. 3600 IN DNSKEY 256 3 8 (
1192 AwEAAbMxuFuLeVDuOwIMzYOTD/bTREjLflo7wOi6ieIJhqltEzgjNzmWJf
1193 9kGwwDmzxU7kbthMEhBNBZNn84zmcyRSCMzuStWveL7xmqqUlE3swL8kLO
1194 vdZvc75XnmpHrk3ndTyEb6eZM7slh2C63Oh6K8VR5VkiZAkEGg0uZIT3Nj
1195 sF )
1196 uri.arpa. 3600 IN DNSKEY 257 3 8 (
1197 AwEAAdkTaWkZtZuRh7/OobBUFxM+ytTst+bCu0r9w+rEwXD7GbDs0pIMhM
1198 enrZzoAvmv1fQxw2MGs6Ri6yPKfNULcFOSt9l8i6BVBLI+SKTY6XXeDUQp
1199 SEmSaxohHeRPMQFzpysfjxINp/L2rGtZ7yPmxY/XRiFPSO0myqwGJa9r06
1200 Zw9CHM5UDHKWV/E+zxPFq/I7CfPbrrzbUotBX7Z6Vh3Sarllbe8cGUB2UF
1201 NaTRgwB0TwDBPRD5ER3w2Dzbry9NhbElTr7vVfhaGWeOGuqAUXwlXEg6Cr
1202 NkmJXJ2F1Rzr9WHUzhp7uWxhAbmJREGfi2dEyPAbUAyCjBqhFaqglknvc= )
1203 uri.arpa. 3600 IN DNSKEY 257 3 8 (
1204 AwEAAenQaBoFmDmvRT+/H5oNbm0Tr5FmNRNDEun0Jpj/ELkzeUrTWhNpQm
1205 ZeIMC8I0kZ185tEvOnRvn8OvV39B17QIdrvvKGIh2HlgeDRCLolhaojfn2
1206 QM0DStjF/WWHpxJOmE6CIuvhqYEU37yoJscGAPpPVPzNvnL1HhYTaao1VR
1207 YWQ/maMrJ+bfHg+YX1N6M/8MnRjIKBif1FWjbCKvsn6dnuGGL9oCWYUFJ3
1208 DwofXuhgPyZMkzPc88YkJj5EMvbMH4wtelbCwC+ivx732l0w/rXJn0ciQS
1209 OgoeVvDio8dIJmWQITWQAuP+q/ZHFEFHPlrP3gvQh5mcVS48eLX71Bq7c= )
1210 uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 (
1211 20210217232440 20210120232440 12670 uri.arpa.
1212 DBE2gkKAoxJCfz47KKxzoImN/0AKArhIVHE7TyTwy0DdRPo44V5R+vL6th
1213 UxlQ1CJi2Rw0jwAXymx5Y3Q873pOEllH+4bJoIT4dmoBmPXfYWW7Clvw9U
1214 PKHRP0igKHmCVwIeBYDTU3gfLcMTbR4nEWPDN0GxlL1Mf7ITaC2Ioabo79
1215 Ip3M/MR8I3Vx/xZ4ZKKPHtLn3xUuJluPNanqJrED2gTslL2xWZ1tqjsAjJ
1216 v7JnJo2HJ8XVRB5zBto0IaJ2oBlqcjdcQ/0VlyoM8uOy1pDwHQ2BJl7322
1217 gNMHBP9HSiUPIOaIDNUCwW8eUcW6DIUk+s9u3GN1uTqwWzsYB/rA== )
1218 uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 (
1219 20210217232440 20210120232440 30577 uri.arpa.
1220 Kx6HwP4UlkGc1UZ7SERXtQjPajOF4iUvkwDj7MEG1xbQFB1KoJiEb/eiW0
1221 qmSWdIhMDv8myhgauejRLyJxwxz8HDRV4xOeHWnRGfWBk4XGYwkejVzOHz
1222 oIArVdUVRbr2JKigcTOoyFN+uu52cNB7hRYu7dH5y1hlc6UbOnzRpMtGxc
1223 gVyKQ+/ARbIqGG3pegdEOvV49wTPWEiyY65P2urqhvnRg5ok/jzwAdMx4X
1224 Gshiib7Ojq0sRVl2ZIzj4rFgY/qsSO8SEXEhMo2VuSkoJNiofVzYoqpxEe
1225 GnANkIT7Tx2xJL1BWyJxyc7E8Wr2QSgCcc+rYL6IkHDtJGHy7TaQ== )
1226 uri.arpa. 3600 IN ZONEMD 2018100702 1 1 (
1227 0dbc3c4dbfd75777c12ca19c337854b1577799901307c482e9d91d5d15
1228 cd934d16319d98e30c4201cf25a1d5a0254960 )
1229 uri.arpa. 3600 IN RRSIG ZONEMD 8 2 3600 (
1230 20210217232440 20210120232440 37444 uri.arpa.
1231 QDo4XZcL3HMyn8aAHyCUsu/Tqj4Gkth8xY1EqByOb8XOTwVtA4ZNQORE1s
1232 iqNqjtJUbeJPtJSbLNqCL7rCq0CzNNnBscv6IIf4gnqJZjlGtHO30ohXtK
1233 vEc4z7SU3IASsi6bB3nLmEAyERdYSeU6UBfx8vatQDIRhkgEnnWUTh4= )
1234 uri.arpa. 3600 IN NSEC ftp.uri.arpa. (
1235 NS SOA MX RRSIG NSEC DNSKEY ZONEMD )
1236 uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 (
1237 20210217232440 20210120232440 37444 uri.arpa.
1238 dU/rXLM/naWd1+1PiWiYVaNJyCkiuyZJSccr91pJI673T8r3685B4ODMYF
1239 afZRboVgwnl3ZrXddY6xOhZL3n9V9nxXZwjLJ2HJUojFoKcXTlpnUyYUYv
1240 VQ2kj4GHAo6fcGCEp5QFJ2KbCpeJoS+PhKGRRx28icCiNT4/uXQvO2E= )
1241 ftp.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
1242 "!^ftp://([^:/?#]*).*$!\\1!i" . )
1243 ftp.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
1244 20210217232440 20210120232440 37444 uri.arpa.
1245 EygekDgl+Lyyq4NMSEpPyOrOywYf9Y3FAB4v1DT44J3R5QGidaH8l7ZFjH
1246 oYFI8sY64iYOCV4sBnX/dh6C1L5NgpY+8l5065Xu3vvjyzbtuJ2k6YYwJr
1247 rCbvl5DDn53zAhhO2hL9uLgyLraZGi9i7TFGd0sm3zNyUF/EVL0CcxU= )
1248 ftp.uri.arpa. 3600 IN NSEC http.uri.arpa. (
1249 NAPTR RRSIG NSEC )
1250 ftp.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
1251 20210217232440 20210120232440 37444 uri.arpa.
1252 pbP4KxevPXCu/bDqcvXiuBppXyFEmtHyiy0eAN5gS7mi6mp9Z9bWFjx/Ld
1253 H9+6oFGYa5vGmJ5itu/4EDMe8iQeZbI8yrpM4TquB7RR/MGfBnTd8S+sjy
1254 QtlRYG7yqEu77Vd78Fme22BKPJ+MVqjS0JHMUE/YUGomPkAjLJJwwGw= )
1255 http.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
1256 "!^http://([^:/?#]*).*$!\\1!i" . )
1257 http.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
1258 20210217232440 20210120232440 37444 uri.arpa.
1259 eTqbWvt1GvTeXozuvm4ebaAfkXFQKrtdu0cEiExto80sHIiCbO0WL8UDa/
1260 J3cDivtQca7LgUbOb6c17NESsrsVkc6zNPx5RK2tG7ZQYmhYmtqtfg1oU5
1261 BRdHZ5TyqIXcHlw9Blo2pir1Y9IQgshhD7UOGkbkEmvB1Lrd0aHhAAg= )
1262 http.uri.arpa. 3600 IN NSEC mailto.uri.arpa. (
1263 NAPTR RRSIG NSEC )
1264 http.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
1265 20210217232440 20210120232440 37444 uri.arpa.
1266 R9rlNzw1CVz2N08q6DhULzcsuUm0UKcPaGAWEU40tr81jEDHsFHNM+khCd
1267 OI8nDstzA42aee4rwCEgijxJpRCcY9hrO1Ysrrr2fdqNz60JikMdarvU5O
1268 0p0VXeaaJDfJQT44+o+YXaBwI7Qod3FTMx7aRib8i7istvPm1Rr7ixA= )
1269 mailto.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
1270 "!^mailto:(.*)@(.*)$!\\2!i" . )
1271 mailto.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
1272 20210217232440 20210120232440 37444 uri.arpa.
1273 Ch2zTG2F1plEvQPyIH4Yd80XXLjXOPvMbiqDjpJBcnCJsV8QF7kr0wTLnU
1274 T3dB+asQudOjPyzaHGwFlMzmrrAsszN4XAMJ6htDtFJdsgTMP/NkHhYRSm
1275 Vv6rLeAhd+mVfObY12M//b/GGVTjeUI/gJaLW0fLVZxr1Fp5U5CRjyw= )
1276 mailto.uri.arpa. 3600 IN NSEC urn.uri.arpa. (
1277 NAPTR RRSIG NSEC )
1278 mailto.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
1279 20210217232440 20210120232440 37444 uri.arpa.
1280 fQUbSIE6E7JDi2rosah4SpCOTrKufeszFyj5YEavbQuYlQ5cNFvtm8KuE2
1281 xXMRgRI4RGvM2leVqcoDw5hS3m2pOJLxH8l2WE72YjYvWhvnwc5Rofe/8y
1282 B/vaSK9WCnqN8y2q6Vmy73AGP0fuiwmuBra7LlkOiqmyx3amSFizwms= )
1283 urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
1284 "/urn:([^:]+)/\\1/i" . )
1285 urn.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
1286 20210217232440 20210120232440 37444 uri.arpa.
1287 CVt2Tgz0e5ZmaSXqRfNys/8OtVCk9nfP0zhezhN8Bo6MDt6yyKZ2kEEWJP
1288 jkN7PCYHjO8fGjnUn0AHZI2qBNv7PKHcpR42VY03q927q85a65weOO1YE0
1289 vPYMzACpua9TOtfNnynM2Ws0uN9URxUyvYkXBdqOC81N3sx1dVELcwc= )
1290 urn.uri.arpa. 3600 IN NSEC uri.arpa. NAPTR RRSIG NSEC
1291 urn.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
1292 20210217232440 20210120232440 37444 uri.arpa.
1293 JuKkMiC3/j9iM3V8/izcouXWAVGnSZjkOgEgFPhutMqoylQNRcSkbEZQzF
1294 K8B/PIVdzZF0Y5xkO6zaKQjOzz6OkSaNPIo1a7Vyyl3wDY/uLCRRAHRJfp
1295 knuY7O+AUNXvVVIEYJqZggd4kl/Rjh1GTzPYZTRrVi5eQidI1LqCOeg= )
1296
1297 A.5. The ROOT-SERVERS.NET Zone
1298
1299 The following sample zone is the ROOT-SERVERS.NET zone retrieved
1300 2018-10-21.
1301
1302 root-servers.net. 3600000 IN SOA a.root-servers.net. (
1303 nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
1304 root-servers.net. 3600000 IN NS a.root-servers.net.
1305 root-servers.net. 3600000 IN NS b.root-servers.net.
1306 root-servers.net. 3600000 IN NS c.root-servers.net.
1307 root-servers.net. 3600000 IN NS d.root-servers.net.
1308 root-servers.net. 3600000 IN NS e.root-servers.net.
1309 root-servers.net. 3600000 IN NS f.root-servers.net.
1310 root-servers.net. 3600000 IN NS g.root-servers.net.
1311 root-servers.net. 3600000 IN NS h.root-servers.net.
1312 root-servers.net. 3600000 IN NS i.root-servers.net.
1313 root-servers.net. 3600000 IN NS j.root-servers.net.
1314 root-servers.net. 3600000 IN NS k.root-servers.net.
1315 root-servers.net. 3600000 IN NS l.root-servers.net.
1316 root-servers.net. 3600000 IN NS m.root-servers.net.
1317 a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30
1318 a.root-servers.net. 3600000 IN A 198.41.0.4
1319 b.root-servers.net. 3600000 IN MX 20 mail.isi.edu.
1320 b.root-servers.net. 3600000 IN AAAA 2001:500:200::b
1321 b.root-servers.net. 3600000 IN A 199.9.14.201
1322 c.root-servers.net. 3600000 IN AAAA 2001:500:2::c
1323 c.root-servers.net. 3600000 IN A 192.33.4.12
1324 d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d
1325 d.root-servers.net. 3600000 IN A 199.7.91.13
1326 e.root-servers.net. 3600000 IN AAAA 2001:500:a8::e
1327 e.root-servers.net. 3600000 IN A 192.203.230.10
1328 f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f
1329 f.root-servers.net. 3600000 IN A 192.5.5.241
1330 g.root-servers.net. 3600000 IN AAAA 2001:500:12::d0d
1331 g.root-servers.net. 3600000 IN A 192.112.36.4
1332 h.root-servers.net. 3600000 IN AAAA 2001:500:1::53
1333 h.root-servers.net. 3600000 IN A 198.97.190.53
1334 i.root-servers.net. 3600000 IN MX 10 mx.i.root-servers.org.
1335 i.root-servers.net. 3600000 IN AAAA 2001:7fe::53
1336 i.root-servers.net. 3600000 IN A 192.36.148.17
1337 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30
1338 j.root-servers.net. 3600000 IN A 192.58.128.30
1339 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1
1340 k.root-servers.net. 3600000 IN A 193.0.14.129
1341 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42
1342 l.root-servers.net. 3600000 IN A 199.7.83.42
1343 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35
1344 m.root-servers.net. 3600000 IN A 202.12.27.33
1345 root-servers.net. 3600000 IN SOA a.root-servers.net. (
1346 nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
1347 root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 (
1348 f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97
1349 8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 )
1350
1351 Appendix B. Implementation Status
1352
1353 This section records the status of known implementations of the
1354 protocol defined by this specification at the time of publication,
1355 and is inspired by the concepts described in RFC 7942.
1356
1357 Please note that the listing of any individual implementation here
1358 does not imply endorsement by the IETF. Furthermore, no effort has
1359 been spent to verify the information presented here that was supplied
1360 by IETF contributors. This is not intended as, and must not be
1361 construed to be, a catalog of available implementations or their
1362 features. Readers are advised to note that other implementations may
1363 exist.
1364
1365 B.1. Authors' Implementation
1366
1367 The authors have an open-source implementation in C, using the ldns
1368 library ([LDNS-ZONE-DIGEST]). This implementation is able to perform
1369 the following functions:
1370
1371 * Read an input zone and output a zone with the ZONEMD placeholder.
1372
1373 * Compute the zone digest over the signed zone and update the ZONEMD
1374 record.
1375
1376 * Recompute DNSSEC signatures over the ZONEMD record.
1377
1378 * Verify the zone digest from an input zone.
1379
1380 This implementation does not:
1381
1382 * Perform DNSSEC validation of the ZONEMD record during
1383 verification.
1384
1385 B.2. Shane Kerr's Implementation
1386
1387 Shane Kerr wrote an implementation of this specification during the
1388 IETF 102 hackathon ([ZONE-DIGEST-HACKATHON]). This implementation is
1389 in Python and is able to perform the following functions:
1390
1391 * Read an input zone and output a zone with ZONEMD record.
1392
1393 * Verify the zone digest from an input zone.
1394
1395 * Output the ZONEMD record in its defined presentation format.
1396
1397 This implementation does not:
1398
1399 * Recompute DNSSEC signatures over the ZONEMD record.
1400
1401 * Perform DNSSEC validation of the ZONEMD record.
1402
1403 B.3. NIC Chile Lab's Implementation
1404
1405 NIC Chile Labs wrote an implementation of this specification as part
1406 of "dns-tools" suite ([DNS-TOOLS]), which besides digesting, can also
1407 sign and verify zones. This implementation is in Go and is able to
1408 perform the following functions:
1409
1410 * Compute zone digest over signed zone and update the ZONEMD record.
1411
1412 * Verify the zone digest from an input zone.
1413
1414 * Perform DNSSEC validation of the ZONEMD record during
1415 verification.
1416
1417 * Recompute DNSSEC signatures over the ZONEMD record.
1418
1419 Acknowledgments
1420
1421 The authors wish to thank David Blacka, Scott Hollenbeck, and Rick
1422 Wilhelm for providing feedback on early drafts of this document.
1423 Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
1424 Donald Eastlake 3rd, Richard Gibson, Olafur Gudmundsson, Bob Harold,
1425 Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns,
1426 Burt Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed
1427 Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury,
1428 Willem Toorop, Florian Weimer, Tim Wicinski, Wouter Wijngaards, Paul
1429 Wouters, and other members of the DNSOP Working Group for their
1430 input.
1431
1432 The authors would again like to thank Tim Wicinski, who served as the
1433 Document Shepherd for this document.
1434
1435 Authors' Addresses
1436
1437 Duane Wessels
1438 Verisign
1439 12061 Bluemont Way
1440 Reston, VA 20190
1441 United States of America
1442
1443 Phone: +1 703 948-3200
1444 Email: dwessels@verisign.com
1445 URI: https://verisign.com
1446
1447
1448 Piet Barber
1449 Verisign
1450 12061 Bluemont Way
1451 Reston, VA 20190
1452 United States of America
1453
1454 Phone: +1 703 948-3200
1455 Email: pbarber@verisign.com
1456 URI: https://verisign.com
1457
1458
1459 Matt Weinberg
1460 Amazon
1461
1462 Email: matweinb@amazon.com
1463 URI: https://amazon.com
1464
1465
1466 Warren Kumari
1467 Google
1468 1600 Amphitheatre Parkway
1469 Mountain View, CA 94043
1470 United States of America
1471
1472 Email: warren@kumari.net
1473
1474
1475 Wes Hardaker
1476 USC/ISI
1477 P.O. Box 382
1478 Davis, CA 95617
1479 United States of America
1480
1481 Email: ietf@hardakers.net
1482
example. 86400 IN ZONEMD 2018031900 241 1 (
e1846540e33a9e41
89792d18d5d131f6
05fc283e )
<A ZONEMD record with a digest of length 48>