doc: Add RFC documents

1 files changed, 1485 insertions, 0 deletions

diff --git a/doc/rfc/rfc8976.txt b/doc/rfc/rfc8976.txt
new file mode 100644
index 0000000..47857f1
--- /dev/null
+++ b/doc/rfc/rfc8976.txt
@@ -0,0 +1,1485 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        D. Wessels
+Request for Comments: 8976                                     P. Barber
+Category: Standards Track                                       Verisign
+ISSN: 2070-1721                                              M. Weinberg
+                                                                  Amazon
+                                                               W. Kumari
+                                                                  Google
+                                                             W. Hardaker
+                                                                 USC/ISI
+                                                           February 2021
+
+
+                      Message Digest for DNS Zones
+
+Abstract
+
+   This document describes a protocol and new DNS Resource Record that
+   provides a cryptographic message digest over DNS zone data at rest.
+   The ZONEMD Resource Record conveys the digest data in the zone
+   itself.  When used in combination with DNSSEC, ZONEMD allows
+   recipients to verify the zone contents for data integrity and origin
+   authenticity.  This provides assurance that received zone data
+   matches published data, regardless of how the zone data has been
+   transmitted and received.  When used without DNSSEC, ZONEMD functions
+   as a checksum, guarding only against unintentional changes.
+
+   ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets
+   (DNS data with fine granularity), whereas ZONEMD protects a zone's
+   data as a whole, whether consumed by authoritative name servers,
+   recursive name servers, or any other applications.
+
+   As specified herein, ZONEMD is impractical for large, dynamic zones
+   due to the time and resources required for digest calculation.
+   However, the ZONEMD record is extensible so that new digest schemes
+   may be added in the future to support large, dynamic zones.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8976.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Motivation
+     1.2.  Alternative Approaches
+     1.3.  Design Overview
+     1.4.  Use Cases
+       1.4.1.  Root Zone
+       1.4.2.  Providers, Secondaries, and Anycast
+       1.4.3.  Response Policy Zones
+       1.4.4.  Centralized Zone Data Service
+       1.4.5.  General Purpose Comparison Check
+     1.5.  Terminology
+   2.  The ZONEMD Resource Record
+     2.1.  Non-apex ZONEMD Records
+     2.2.  ZONEMD RDATA Wire Format
+       2.2.1.  The Serial Field
+       2.2.2.  The Scheme Field
+       2.2.3.  The Hash Algorithm Field
+       2.2.4.  The Digest Field
+     2.3.  ZONEMD Presentation Format
+     2.4.  ZONEMD Example
+     2.5.  Including ZONEMD RRs in a Zone
+   3.  Calculating the Digest
+     3.1.  Add ZONEMD Placeholder
+     3.2.  Optionally, Sign the Zone
+     3.3.  Scheme-Specific Processing
+       3.3.1.  The SIMPLE Scheme
+         3.3.1.1.  SIMPLE Scheme Inclusion/Exclusion Rules
+         3.3.1.2.  SIMPLE Scheme Digest Calculation
+     3.4.  Update ZONEMD RR
+   4.  Verifying Zone Digest
+   5.  IANA Considerations
+     5.1.  ZONEMD RRtype
+     5.2.  ZONEMD Scheme
+     5.3.  ZONEMD Hash Algorithms
+   6.  Security Considerations
+     6.1.  Using Zone Digest without DNSSEC
+     6.2.  Attacks against the Zone Digest
+     6.3.  Use of Multiple ZONEMD Hash Algorithms
+     6.4.  DNSSEC Timing Considerations
+     6.5.  Attacks Utilizing ZONEMD Queries
+     6.6.  Resilience and Fragility
+   7.  Performance Considerations
+     7.1.  SIMPLE SHA384
+   8.  Privacy Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Appendix A.  Example Zones with Digests
+     A.1.  Simple EXAMPLE Zone
+     A.2.  Complex EXAMPLE Zone
+     A.3.  EXAMPLE Zone with Multiple Digests
+     A.4.  The URI.ARPA Zone
+     A.5.  The ROOT-SERVERS.NET Zone
+   Appendix B.  Implementation Status
+     B.1.  Authors' Implementation
+     B.2.  Shane Kerr's Implementation
+     B.3.  NIC Chile Lab's Implementation
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   In the DNS, a zone is the collection of authoritative resource
+   records (RRs) sharing a common origin ([RFC8499]).  Zones are often
+   stored as files in the so-called "master file format" ([RFC1034]).
+   Zones are generally distributed among name servers using the zone
+   transfer (AXFR) ([RFC5936]) and incremental zone transfer (IXFR)
+   ([RFC1995]) protocols.  They can also be distributed outside of the
+   DNS with any file transfer protocol such as FTP, HTTP, and rsync, or
+   even as email attachments.  Currently, there is no standard way to
+   compute a hash or message digest for a stand-alone zone.
+
+   This document specifies an RR type that provides a cryptographic
+   message digest of the data in a zone.  It allows a receiver of the
+   zone to verify the zone's integrity and authenticity when used in
+   combination with DNSSEC.  The digest RR is a part of the zone itself,
+   allowing verification of the zone, no matter how it is transmitted.
+   The digest uses the wire format of zone data in a canonical ordering.
+   Thus, it is independent of presentation format such as whitespace,
+   capitalization, and comments.
+
+   This specification is OPTIONAL to implement by both publishers and
+   consumers of zone data.
+
+1.1.  Motivation
+
+   The primary motivation for this protocol enhancement is the desire to
+   verify the data integrity and origin authenticity of a stand-alone
+   zone, regardless of how it is transmitted.  A consumer of zone data
+   should be able to verify that it is as published by the zone
+   operator.
+
+   Note, however, that integrity and authenticity can only be assured
+   when the zone is signed.  DNSSEC provides three strong security
+   guarantees relevant to this protocol:
+
+   1.  whether or not to expect DNSSEC records in the zone,
+
+   2.  whether or not to expect a ZONEMD record in a signed zone, and
+
+   3.  whether or not the ZONEMD record has been altered since it was
+       signed.
+
+   A secondary motivation is to provide the equivalent of a checksum,
+   allowing a zone recipient to check for unintended changes and
+   operational errors such as accidental truncation.
+
+1.2.  Alternative Approaches
+
+   One approach to preventing data tampering and corruption is to secure
+   the distribution channel.  The DNS has a number of features that are
+   already used for channel security.  Perhaps the most widely used is
+   DNS transaction signatures (TSIGs) ([RFC8945]).  A TSIG uses shared
+   secret keys and a message digest to protect individual query and
+   response messages.  It is generally used to authenticate and validate
+   UPDATE ([RFC2136]), AXFR ([RFC5936]), and IXFR ([RFC1995]) messages.
+
+   DNS Request and Transaction Signatures (SIG(0)) ([RFC2931]) is
+   another protocol extension that authenticates individual DNS
+   transactions.  Whereas SIG records normally cover specific RR types,
+   SIG(0) is used to sign an entire DNS message.  Unlike TSIG, SIG(0)
+   uses public key cryptography rather than shared secrets.
+
+   The Transport Layer Security protocol suite also provides channel
+   security.  The DPRIVE Working Group is in the process of specifying
+   DNS Zone Transfer-over-TLS ([DPRIVE-XFR-OVER-TLS]).  One can also
+   easily imagine the distribution of zones over HTTPS-enabled web
+   servers as well as DNS-over-HTTPS ([RFC8484]).
+
+   Unfortunately, the protections provided by these channel security
+   techniques are (in practice) ephemeral and are not retained after the
+   data transfer is complete.  They ensure that the client receives the
+   data from the expected server and that the data sent by the server is
+   not modified during transmission.  However, they do not guarantee
+   that the server transmits the data as originally published and do not
+   provide any methods to verify data that is read after transmission is
+   complete.  For example, a name server loading saved zone data upon
+   restart cannot guarantee that the on-disk data has not been modified.
+   Such modification could be the result of an accidental corruption of
+   the file or perhaps an incomplete saving of the file
+   ([DISK-FULL-FAILURE]).  For these reasons, it is preferable to
+   protect the integrity of the data itself.
+
+   Why not simply rely on DNSSEC, which provides certain data security
+   guarantees?  For zones that are signed, a recipient could validate
+   all of the signed RRsets.  Additionally, denial-of-existence records
+   prove that RRsets have not been added or removed.  However,
+   delegations (non-apex NS records) are not signed by DNSSEC and
+   neither are any glue records.  ZONEMD protects the integrity of
+   delegation, glue, and other records that are not otherwise covered by
+   DNSSEC.  Furthermore, zones that employ NSEC3 with Opt-Out
+   ([RFC5155]) are susceptible to the removal or addition of names
+   between the signed nodes.  Whereas DNSSEC primarily protects
+   consumers of DNS response messages, this protocol protects consumers
+   of zones.
+
+   There are existing tools and protocols that provide data security,
+   such as OpenPGP ([RFC4880]) and S/MIME ([RFC8551]).  In fact, the
+   internic.net site publishes Pretty Good Privacy (PGP) signatures
+   alongside the root zone and other files available there.  However,
+   this is a detached signature with no strong association to the
+   corresponding zone file other than its timestamp.  Attached
+   signatures are of course possible, but these necessarily change the
+   format of the file being distributed; a zone signed with OpenPGP or
+   S/MIME no longer looks like a DNS zone and could not directly be
+   loaded into a name server.  Once loaded, the signature data is lost,
+   so it cannot be further propagated.
+
+   It seems the desire for data security in DNS zones was envisioned as
+   far back as 1997.  [RFC2065] is an obsoleted specification of the
+   first generation DNSSEC Security Extensions.  It describes a zone
+   transfer signature, identified as the AXFR SIG, which is similar to
+   the technique proposed by this document.  That is, it proposes
+   ordering all (signed) RRsets in a zone, hashing their contents, and
+   then signing the zone hash.  The AXFR SIG is described only for use
+   during zone transfers.  It did not postulate the need to validate
+   zone data distributed outside of the DNS.  Furthermore, its
+   successor, [RFC2535], omits the AXFR SIG while at the same time
+   introducing an IXFR SIG.  (Note: RFC 2535 was obsoleted by [RFC4033],
+   [RFC4034], and [RFC4035].)
+
+1.3.  Design Overview
+
+   This document specifies a new Resource Record type to convey a
+   message digest of the content of a zone.  The digest is calculated at
+   the time of zone publication.  If the zone is signed with DNSSEC, any
+   modifications of the digest can be detected.  The procedures for
+   digest calculation and DNSSEC signing are similar.  Both require data
+   to be processed in a well-defined order and format.  It may be
+   possible to perform DNSSEC signing and digest calculation in
+   parallel.
+
+   The zone digest is designed to be used on zones that have infrequent
+   updates.  As specified herein, the digest is recalculated over the
+   entire zone content each time the zone is updated.  This
+   specification does not provide an efficient mechanism for updating
+   the digest on incremental updates of zone data.  It is, however,
+   extensible so that future schemes may be defined to support efficient
+   incremental digest updates.
+
+   It is expected that verification of a zone digest will be implemented
+   in name server software.  That is, a name server can verify the zone
+   data it was given and refuse to serve a zone that fails verification.
+   For signed zones, the name server needs a trust anchor to perform
+   DNSSEC validation.  For signed non-root zones, the name server may
+   need to send queries to validate a chain of trust.  Digest
+   verification could also be performed externally.
+
+1.4.  Use Cases
+
+1.4.1.  Root Zone
+
+   The root zone ([InterNIC]) is one of the most widely distributed DNS
+   zones on the Internet, served by more than 1000 separate instances
+   ([ROOT-SERVERS]) at the time of this writing.  Additionally, many
+   organizations configure their own name servers to serve the root zone
+   locally.  Reasons for doing so include privacy and reduced access
+   time.  [RFC8806] describes one way to do this.  As the root zone
+   spreads beyond its traditional deployment boundaries, the
+   verification of the completeness of the zone contents becomes more
+   important.
+
+1.4.2.  Providers, Secondaries, and Anycast
+
+   Since its very early days, the developers of the DNS recognized the
+   importance of secondary name servers and service diversity.  However,
+   modern DNS service has complex provisioning that includes multiple
+   third-party providers ([RFC8901]) and hundreds of anycast instances
+   ([RFC3258]).  Instead of a simple primary-to-secondary zone
+   distribution system, today it is possible to have multiple levels,
+   multiple parties, and multiple protocols involved in the distribution
+   of zone data.  This complexity introduces new places for problems to
+   arise.  The zone digest protects the integrity of data that flows
+   through such systems.
+
+1.4.3.  Response Policy Zones
+
+   A Response Policy Zone (RPZ) is "a mechanism to introduce a
+   customized policy in Domain Name System servers, so that recursive
+   resolvers return possibly modified results" ([RPZ]).  The policy
+   information is carried inside specially constructed DNS zones.  A
+   number of companies provide RPZ feeds, which are consumed by name
+   server and firewall products.  While RPZs can be signed with DNSSEC,
+   the data is not queried directly and would not be subject to DNSSEC
+   validation.
+
+1.4.4.  Centralized Zone Data Service
+
+   ICANN operates the Centralized Zone Data Service ([CZDS]), which is a
+   repository of top-level domain zone files.  Users that have been
+   granted access are then able to download zone data.  Adding a zone
+   digest to these would provide CZDS users with assurances that the
+   data has not been modified between origination and retrieval.  Note
+   that ZONEMD could be added to zone data supplied to CZDS without
+   requiring it to be present in the zone data served by production name
+   servers, since the digest is inherently attached to the specific copy
+   of the zone.
+
+1.4.5.  General Purpose Comparison Check
+
+   Since the zone digest calculation does not depend on presentation
+   format, it could be used to compare multiple copies of a zone
+   received from different sources, or copies generated by different
+   processes.  In this case, it serves as a checksum and can be useful
+   even for unsigned zones.
+
+1.5.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   The terms Private Use, Reserved, Unassigned, and Specification
+   Required are to be interpreted as defined in [RFC8126].
+
+2.  The ZONEMD Resource Record
+
+   This section describes the ZONEMD Resource Record, including its
+   fields, wire format, and presentation format.  The Type value for the
+   ZONEMD RR is 63.  The ZONEMD RR is class independent.  The RDATA of
+   the resource record consists of four fields: Serial, Scheme, Hash
+   Algorithm, and Digest.
+
+2.1.  Non-apex ZONEMD Records
+
+   This document specifies ZONEMD RRs located at the zone apex.  Non-
+   apex ZONEMD RRs are not forbidden, but have no meaning in this
+   specification.  Non-apex ZONEMD RRs MUST NOT be used for
+   verification.
+
+   During digest calculation, non-apex ZONEMD RRs are treated as
+   ordinary RRs.  They are digested as is, and the RR is not replaced by
+   a placeholder RR.
+
+   Unless explicitly stated otherwise, "ZONEMD" always refers to apex
+   records throughout this document.
+
+2.2.  ZONEMD RDATA Wire Format
+
+   The ZONEMD RDATA wire format is encoded as follows:
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Serial                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Scheme     |Hash Algorithm |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+   |                             Digest                            |
+   /                                                               /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.2.1.  The Serial Field
+
+   The Serial field is a 32-bit unsigned integer in network byte order.
+   It is the serial number from the zone's SOA record ([RFC1035],
+   Section 3.3.13) for which the zone digest was generated.
+
+   It is included here to clearly bind the ZONEMD RR to a particular
+   version of the zone's content.  Without the serial number, a stand-
+   alone ZONEMD digest has no obvious association to any particular
+   instance of a zone.
+
+2.2.2.  The Scheme Field
+
+   The Scheme field is an 8-bit unsigned integer that identifies the
+   methods by which data is collated and presented as input to the
+   hashing function.
+
+   Herein, SIMPLE, with Scheme value 1, is the only standardized Scheme
+   defined for ZONEMD records and it MUST be supported by
+   implementations.  The "ZONEMD Schemes" registry is further described
+   in Section 5.
+
+   Scheme values 240-254 are allocated for Private Use.
+
+2.2.3.  The Hash Algorithm Field
+
+   The Hash Algorithm field is an 8-bit unsigned integer that identifies
+   the cryptographic hash algorithm used to construct the digest.
+
+   Herein, SHA384 ([RFC6234]), with Hash Algorithm value 1, is the only
+   standardized Hash Algorithm defined for ZONEMD records that MUST be
+   supported by implementations.  When SHA384 is used, the size of the
+   Digest field is 48 octets.  The result of the SHA384 digest algorithm
+   MUST NOT be truncated, and the entire 48-octet digest is published in
+   the ZONEMD record.
+
+   SHA512 ([RFC6234]), with Hash Algorithm value 2, is also defined for
+   ZONEMD records and SHOULD be supported by implementations.  When
+   SHA512 is used, the size of the Digest field is 64 octets.  The
+   result of the SHA512 digest algorithm MUST NOT be truncated, and the
+   entire 64-octet digest is published in the ZONEMD record.
+
+   Hash Algorithm values 240-254 are allocated for Private Use.
+
+   The "ZONEMD Hash Algorithms" registry is further described in
+   Section 5.
+
+2.2.4.  The Digest Field
+
+   The Digest field is a variable-length sequence of octets containing
+   the output of the hash algorithm.  The length of the Digest field is
+   determined by deducting the fixed size of the Serial, Scheme, and
+   Hash Algorithm fields from the RDATA size in the ZONEMD RR header.
+
+   The Digest field MUST NOT be shorter than 12 octets.  Digests for the
+   SHA384 and SHA512 hash algorithms specified herein are never
+   truncated.  Digests for future hash algorithms MAY be truncated but
+   MUST NOT be truncated to a length that results in less than 96 bits
+   (12 octets) of equivalent strength.
+
+   Section 3 describes how to calculate the digest for a zone.
+   Section 4 describes how to use the digest to verify the contents of a
+   zone.
+
+2.3.  ZONEMD Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   *  The Serial field is represented as an unsigned decimal integer.
+
+   *  The Scheme field is represented as an unsigned decimal integer.
+
+   *  The Hash Algorithm field is represented as an unsigned decimal
+      integer.
+
+   *  The Digest is represented as a sequence of case-insensitive
+      hexadecimal digits.  Whitespace is allowed within the hexadecimal
+      text.
+
+2.4.  ZONEMD Example
+
+   The following example shows a ZONEMD RR in presentation format:
+
+   example.com. 86400 IN ZONEMD 2018031500 1 1 (
+       FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
+       7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
+
+2.5.  Including ZONEMD RRs in a Zone
+
+   The zone operator chooses an appropriate hash algorithm and scheme
+   and includes the calculated zone digest in the apex ZONEMD RRset.
+   The zone operator MAY choose any of the defined hash algorithms and
+   schemes, including the Private Use code points.
+
+   The ZONEMD RRset MAY contain multiple records to support algorithm
+   agility ([BCP201]).  When multiple ZONEMD RRs are present, each MUST
+   specify a unique Scheme and Hash Algorithm tuple.  It is RECOMMENDED
+   that a zone include only one ZONEMD RR, unless the zone operator is
+   in the process of transitioning to a new scheme or hash algorithm.
+
+3.  Calculating the Digest
+
+   The algorithm described in this section is designed for the common
+   case of offline DNSSEC signing.  Slight deviations may be permitted
+   or necessary in other situations, such as with unsigned zones or
+   online DNSSEC signing.  Implementations that deviate from the
+   described algorithm are advised to ensure that it produces ZONEMD
+   RRs, signatures, and denial-of-existence records that are identical
+   to the ones generated by this procedure.
+
+3.1.  Add ZONEMD Placeholder
+
+   In preparation for calculating the zone digest(s), any existing
+   ZONEMD records (and covering RRSIGs) at the zone apex are first
+   deleted.
+
+   Prior to calculation of the digest, and prior to signing with DNSSEC,
+   one or more placeholder ZONEMD records are added to the zone apex.
+   This ensures that denial-of-existence (NSEC, NSEC3) records are
+   created correctly if the zone is signed with DNSSEC.  If placeholders
+   were not added prior to signing, the later addition of ZONEMD records
+   would also require updating the Type Bit Maps field of any apex NSEC/
+   NSEC3 RRs, which then invalidates the calculated digest value.
+
+   When multiple ZONEMD RRs are published in the zone, e.g., during an
+   algorithm rollover, each MUST specify a unique Scheme and Hash
+   Algorithm tuple.
+
+   It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of
+   the Start of Authority (SOA).  However, the TTL of the ZONEMD record
+   may be safely ignored during verification in all cases.
+
+   In the placeholder record, the Serial field is set to the current SOA
+   Serial.  The Scheme field is set to the value for the chosen
+   collation scheme.  The Hash Algorithm field is set to the value for
+   the chosen hash algorithm.  Since apex ZONEMD records are excluded
+   from digest calculation, the value of the Digest field does not
+   matter at this point in the process.
+
+3.2.  Optionally, Sign the Zone
+
+   Following the addition of placeholder records, the zone may be signed
+   with DNSSEC.  When the digest calculation is complete, and the ZONEMD
+   record is updated, the signature(s) for the ZONEMD RRset MUST be
+   recalculated and updated as well.  Therefore, the signer is not
+   required to calculate a signature over the placeholder record at this
+   step in the process, but it is harmless to do so.
+
+3.3.  Scheme-Specific Processing
+
+   Herein, only the SIMPLE collation scheme is defined.  Additional
+   schemes may be defined in future updates to this document.
+
+3.3.1.  The SIMPLE Scheme
+
+   For the SIMPLE scheme, the digest is calculated over the zone as a
+   whole.  This means that a change to a single RR in the zone requires
+   iterating over all RRs in the zone to recalculate the digest.  SIMPLE
+   is a good choice for zones that are small and/or stable, but it is
+   probably not good for zones that are large and/or dynamic.
+
+   Calculation of a zone digest requires RRs to be processed in a
+   consistent format and ordering.  This specification uses DNSSEC's
+   canonical on-the-wire RR format (without name compression) and
+   ordering as specified in Sections 6.1, 6.2, and 6.3 of [RFC4034] with
+   the additional provision that RRsets having the same owner name MUST
+   be numerically ordered, in ascending order, by their numeric RR TYPE.
+
+3.3.1.1.  SIMPLE Scheme Inclusion/Exclusion Rules
+
+   When iterating over records in the zone, the following inclusion/
+   exclusion rules apply:
+
+   *  All records in the zone, including glue records, MUST be included
+      unless excluded by a subsequent rule.
+
+   *  Occluded data ([RFC5936], Section 3.5) MUST be included.
+
+   *  If there are duplicate RRs with equal owner, class, type, and
+      RDATA, only one instance is included ([RFC4034], Section 6.3) and
+      the duplicates MUST be omitted.
+
+   *  The placeholder apex ZONEMD RR(s) MUST NOT be included.
+
+   *  If the zone is signed, DNSSEC RRs MUST be included, except:
+
+   *  The RRSIG covering the apex ZONEMD RRset MUST NOT be included
+      because the RRSIG will be updated after all digests have been
+      calculated.
+
+3.3.1.2.  SIMPLE Scheme Digest Calculation
+
+   A zone digest using the SIMPLE scheme is calculated by concatenating
+   all RRs in the zone, in the format and order described in
+   Section 3.3.1 subject to the inclusion/exclusion rules described in
+   Section 3.3.1.1, and then applying the chosen hash algorithm:
+
+   digest = hash( RR(1) | RR(2) | RR(3) | ... )
+
+   where "|" denotes concatenation.
+
+3.4.  Update ZONEMD RR
+
+   The calculated zone digest is inserted into the placeholder ZONEMD
+   RR.  Repeat for each digest if multiple digests are to be published.
+
+   If the zone is signed with DNSSEC, the RRSIG record(s) covering the
+   ZONEMD RRset MUST then be added or updated.  Because the ZONEMD
+   placeholder was added prior to signing, the zone will already have
+   the appropriate denial-of-existence (NSEC, NSEC3) records.
+
+   Some DNSSEC implementations (especially "online signing") might
+   update the SOA serial number whenever a new signature is made.  To
+   preserve the calculated digest, generation of a ZONEMD signature MUST
+   NOT also result in a change to the SOA serial number.  The ZONEMD RR
+   and the matching SOA MUST be published at the same time.
+
+4.  Verifying Zone Digest
+
+   The recipient of a zone that has a ZONEMD RR verifies the zone by
+   calculating the digest as follows:
+
+      |  Note: If multiple ZONEMD RRs are present in the zone, e.g.,
+      |  during an algorithm rollover, a match using any one of the
+      |  recipient's supported Schemes and Hash Algorithms is sufficient
+      |  to verify the zone.  The verifier MAY ignore a ZONEMD RR if its
+      |  Scheme and Hash Algorithm violates local policy.
+
+   1.  The verifier MUST first determine whether or not to expect DNSSEC
+       records in the zone.  By examining locally configured trust
+       anchors and, if necessary, querying for and validating Delegation
+       Signer (DS) RRs in the parent zone, the verifier knows whether or
+       not the zone to be verified should include DNSSEC keys and
+       signatures.  For zones where signatures are not expected, or if
+       DNSSEC validation is not performed, digest verification continues
+       at step 4 below.
+
+   2.  For zones where signatures are expected, the existence of the
+       apex ZONEMD record MUST be validated.  If the DNSSEC data proves
+       the ZONEMD RRset does not exist, digest verification cannot
+       occur.  If the DNSSEC data proves the ZONEMD does exist, but is
+       not found in the zone, digest verification MUST NOT be considered
+       successful.
+
+   3.  For zones where signatures are expected, the SOA and ZONEMD
+       RRsets MUST have valid signatures, chaining up to a trust anchor.
+       If DNSSEC validation of the SOA or ZONEMD RRsets fails, digest
+       verification MUST NOT be considered successful.
+
+   4.  When multiple ZONEMD RRs are present, each MUST specify a unique
+       Scheme and Hash Algorithm tuple.  If the ZONEMD RRset contains
+       more than one RR with the same Scheme and Hash Algorithm, digest
+       verification for those ZONEMD RRs MUST NOT be considered
+       successful.
+
+   5.  Loop over all apex ZONEMD RRs and perform the following steps:
+
+       a.  The SOA Serial field MUST exactly match the ZONEMD Serial
+           field.  If the fields do not match, digest verification MUST
+           NOT be considered successful with this ZONEMD RR.
+
+       b.  The Scheme field MUST be checked.  If the verifier does not
+           support the given scheme, verification MUST NOT be considered
+           successful with this ZONEMD RR.
+
+       c.  The Hash Algorithm field MUST be checked.  If the verifier
+           does not support the given hash algorithm, verification MUST
+           NOT be considered successful with this ZONEMD RR.
+
+       d.  The Digest field size MUST be checked.  If the size of the
+           given Digest field is smaller than 12 octets, or if the size
+           is not equal to the size expected for the corresponding Hash
+           Algorithm, verification MUST NOT be considered successful
+           with this ZONEMD RR.
+
+       e.  The zone digest is computed over the zone data as described
+           in Section 3.3 using the Scheme and Hash Algorithm for the
+           current ZONEMD RR.
+
+       f.  The computed digest is compared to the received digest.  If
+           the two digest values match, verification is considered
+           successful.  Otherwise, verification MUST NOT be considered
+           successful for this ZONEMD RR.
+
+   Each time zone verification is performed, the verifier SHOULD report
+   the status as either successful or unsuccessful.  When unsuccessful,
+   the verifier SHOULD report the reason(s) that verification did not
+   succeed.
+
+5.  IANA Considerations
+
+5.1.  ZONEMD RRtype
+
+   This document defines a new DNS RR type, ZONEMD, whose value 63 has
+   been allocated by IANA from the "Resource Record (RR) TYPEs"
+   subregistry of the "Domain Name System (DNS) Parameters" registry:
+
+   Type:  ZONEMD
+   Value:  63
+   Meaning:  Message Digest Over Zone Data
+   Reference:  [RFC8976]
+
+5.2.  ZONEMD Scheme
+
+   IANA has created a new subregistry in the "Domain Name System (DNS)
+   Parameters" registry as follows:
+
+   Registry Name:  ZONEMD Schemes
+   Registration Procedure:  Specification Required
+   Reference:  [RFC8976]
+
+       +=========+=========================+==========+===========+
+       | Value   | Description             | Mnemonic | Reference |
+       +=========+=========================+==========+===========+
+       | 0       | Reserved                |          | [RFC8976] |
+       +---------+-------------------------+----------+-----------+
+       | 1       | Simple ZONEMD collation | SIMPLE   | [RFC8976] |
+       +---------+-------------------------+----------+-----------+
+       | 2-239   | Unassigned              |          |           |
+       +---------+-------------------------+----------+-----------+
+       | 240-254 | Private Use             | N/A      | [RFC8976] |
+       +---------+-------------------------+----------+-----------+
+       | 255     | Reserved                |          | [RFC8976] |
+       +---------+-------------------------+----------+-----------+
+
+                     Table 1: ZONEMD Scheme Registry
+
+5.3.  ZONEMD Hash Algorithms
+
+   IANA has created a new subregistry in the "Domain Name System (DNS)
+   Parameters" registry as follows:
+
+   Registry Name:  ZONEMD Hash Algorithms
+   Registration Procedure:  Specification Required
+   Reference:  [RFC8976]
+
+             +=========+=============+==========+===========+
+             | Value   | Description | Mnemonic | Reference |
+             +=========+=============+==========+===========+
+             | 0       | Reserved    |          | [RFC8976] |
+             +---------+-------------+----------+-----------+
+             | 1       | SHA-384     | SHA384   | [RFC8976] |
+             +---------+-------------+----------+-----------+
+             | 2       | SHA-512     | SHA512   | [RFC8976] |
+             +---------+-------------+----------+-----------+
+             | 3-239   | Unassigned  |          |           |
+             +---------+-------------+----------+-----------+
+             | 240-254 | Private Use | N/A      | [RFC8976] |
+             +---------+-------------+----------+-----------+
+             | 255     | Reserved    |          | [RFC8976] |
+             +---------+-------------+----------+-----------+
+
+                 Table 2: ZONEMD Hash Algorithms Registry
+
+6.  Security Considerations
+
+6.1.  Using Zone Digest without DNSSEC
+
+   Users of ZONEMD with unsigned zones are advised that it provides no
+   real protection against attacks.  While zone digests can be used in
+   the absence of DNSSEC, this only provides protection against
+   accidental zone corruption such as transmission errors and
+   truncation.  When used in this manner, it effectively serves only as
+   a checksum.  For zones not signed with DNSSEC, an attacker can make
+   any zone modifications appear to be valid by recomputing the Digest
+   field of a ZONEMD RR.
+
+6.2.  Attacks against the Zone Digest
+
+   An attacker, whose goal is to modify zone content before it is used
+   by the victim, may consider a number of different approaches.
+
+   The attacker might perform a downgrade attack to an unsigned zone.
+   This is why Section 4 talks about determining whether or not to
+   expect DNSSEC signatures for the zone in step 1.
+
+   The attacker might perform a downgrade attack by removing one or more
+   ZONEMD records.  Such a removal is detectable only with DNSSEC
+   validation and is why Section 4 talks about checking denial-of-
+   existence proofs in step 2 and signature validation in step 3.
+
+   The attacker might alter the Scheme, Hash Algorithm, or Digest fields
+   of the ZONEMD record.  Such modifications are detectable only with
+   DNSSEC validation.
+
+   As stated in [BCP201], cryptographic algorithms age and become weaker
+   as cryptanalysis techniques and computing resources improve with
+   time.  Implementors and publishers of zone digests should anticipate
+   the need for algorithm agility on long timescales.
+
+6.3.  Use of Multiple ZONEMD Hash Algorithms
+
+   When a zone publishes multiple ZONEMD RRs, the overall security is
+   only as good as the weakest hash algorithm in use.  For this reason,
+   Section 2 recommends only publishing multiple ZONEMD RRs when
+   transitioning to a new scheme or hash algorithm.  Once the transition
+   is complete, the old scheme or hash algorithm should be removed from
+   the ZONEMD RRset.
+
+6.4.  DNSSEC Timing Considerations
+
+   As with all DNSSEC signatures, the ability to perform signature
+   validation of a ZONEMD record is limited in time.  If the DS
+   record(s) or trust anchors for the zone to be verified are no longer
+   available, the recipient cannot validate the ZONEMD RRset.  This
+   could happen even if the ZONEMD signature is still current (not
+   expired), since the zone's DS record(s) may have been withdrawn
+   following a Key Signing Key (KSK) rollover.
+
+   For zones where it may be important to validate a ZONEMD RRset
+   through its entire signature validity period, the zone operator
+   should ensure that KSK rollover timing takes this into consideration.
+
+6.5.  Attacks Utilizing ZONEMD Queries
+
+   Nothing in this specification prevents clients from making, and
+   servers from responding to, ZONEMD queries.  Servers SHOULD NOT
+   calculate zone digests dynamically (for each query) as this can be
+   used as a CPU resource exhaustion attack.
+
+   ZONEMD responses could be used in a distributed denial-of-service
+   amplification attack.  The ZONEMD RR is moderately sized, much like
+   the DS RR.  A single ZONEMD RR contributes approximately 65 to 95
+   octets to a DNS response for digest types defined herein.  Other RR
+   types, such as DNS Public Key (DNSKEY), can result in larger
+   amplification effects.
+
+6.6.  Resilience and Fragility
+
+   ZONEMD is used to detect incomplete or corrupted zone data prior to
+   its use, thereby increasing resilience by not using corrupt data, but
+   also introduces some denial-of-service fragility by making good data
+   in a zone unavailable if some other data is missing or corrupt.
+   Publishers and consumers of zones containing ZONEMD records should be
+   aware of these trade-offs.  While the intention is to secure the zone
+   data, misconfigurations or implementation bugs are generally
+   indistinguishable from intentional tampering and could lead to
+   service failures when verification is performed automatically.
+
+   Zone publishers may want to deploy ZONEMD gradually perhaps by
+   utilizing one of the Private Use hash algorithm code points listed in
+   Section 5.3.  Similarly, recipients may want to initially configure
+   verification failures only as a warning, and later as an error after
+   gaining experience and confidence with the feature.
+
+7.  Performance Considerations
+
+   This section is provided to make zone publishers aware of the
+   performance requirements and implications of including ZONEMD RRs in
+   a zone.
+
+7.1.  SIMPLE SHA384
+
+   As mentioned previously, the SIMPLE scheme may be impractical for use
+   in zones that are either large or highly dynamic.  Zone publishers
+   should carefully consider the use of ZONEMD in such zones since it
+   might cause consumers of zone data (e.g., secondary name servers) to
+   expend resources on digest calculation.  For such use cases, it is
+   recommended that ZONEMD only be used when digest calculation time is
+   significantly less than propagation times and update intervals.
+
+   The authors' implementation (Appendix B.1) includes an option to
+   record and report CPU usage of its operation.  The software was used
+   to generate digests for more than 800 Top-Level Domain (TLD) zones
+   available from [CZDS].  The table below summarizes the results for
+   the SIMPLE scheme and SHA384 hash algorithm grouped by zone size.
+   The Rate column is the mean amount of time per RR to calculate the
+   digest, running on commodity hardware in early 2020.
+
+                 +=====================+================+
+                 |     Zone Size (RRs) | Rate (msec/RR) |
+                 +=====================+================+
+                 |             10 - 99 |        0.00683 |
+                 +---------------------+----------------+
+                 |           100 - 999 |        0.00551 |
+                 +---------------------+----------------+
+                 |         1000 - 9999 |        0.00505 |
+                 +---------------------+----------------+
+                 |       10000 - 99999 |        0.00602 |
+                 +---------------------+----------------+
+                 |     100000 - 999999 |        0.00845 |
+                 +---------------------+----------------+
+                 |   1000000 - 9999999 |         0.0108 |
+                 +---------------------+----------------+
+                 | 10000000 - 99999999 |         0.0148 |
+                 +---------------------+----------------+
+
+                                 Table 3
+
+   For example, based on the above table, it takes approximately 0.13
+   seconds to calculate a SIMPLE SHA384 digest for a zone with 22,000
+   RRs, and about 2.5 seconds for a zone with 300,000 RRs.
+
+   These benchmarks attempt to emulate a worst-case scenario and take
+   into account the time required to canonicalize the zone for
+   processing.  Each of the 800+ zones were measured three times and
+   then averaged, with a different random sorting of the input data
+   prior to each measurement.
+
+8.  Privacy Considerations
+
+   This specification has no impact on user privacy.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <https://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, DOI 10.17487/RFC4034, March 2005,
+              <https://www.rfc-editor.org/info/rfc4034>.
+
+   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
+              DOI 10.17487/RFC6234, May 2011,
+              <https://www.rfc-editor.org/info/rfc6234>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2.  Informative References
+
+   [BCP201]   Housley, R., "Guidelines for Cryptographic Algorithm
+              Agility and Selecting Mandatory-to-Implement Algorithms",
+              BCP 201, RFC 7696, November 2015.
+
+              <https://www.rfc-editor.org/info/bcp201>
+
+   [CZDS]     Internet Corporation for Assigned Names and Numbers
+              (ICANN), "Centralized Zone Data Service", October 2018,
+              <https://czds.icann.org/>.
+
+   [DISK-FULL-FAILURE]
+              DENIC, "Background of the Partial Failure of the Name
+              Service for .de Domains", May 2010,
+              <https://web.archive.org/web/20100618032705/
+              https://www.denic.de/en/denic-in-dialogue/news/2733.html>.
+
+   [DNS-TOOLS]
+              "DNS tools for zone signature (file, pkcs11-hsm) and
+              validation, and zone digest (ZONEMD)", commit 489de21,
+              December 2020, <https://github.com/niclabs/dns-tools>.
+
+   [DPRIVE-XFR-OVER-TLS]
+              Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
+              Mankin, "DNS Zone Transfer-over-TLS", Work in Progress,
+              Internet-Draft, draft-ietf-dprive-xfr-over-tls-05, 20
+              January 2021, <https://tools.ietf.org/html/draft-ietf-
+              dprive-xfr-over-tls-05>.
+
+   [InterNIC] InterNIC, "Index of ftp://rs.internic.net/", May 2018,
+              <ftp://ftp.internic.net/domain/>.
+
+   [LDNS-ZONE-DIGEST]
+              "Implementation of Message Digests for DNS Zones using the
+              ldns library", commit 71c0cd1, January 2021,
+              <https://github.com/verisign/ldns-zone-digest>.
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              DOI 10.17487/RFC1995, August 1996,
+              <https://www.rfc-editor.org/info/rfc1995>.
+
+   [RFC2065]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System
+              Security Extensions", RFC 2065, DOI 10.17487/RFC2065,
+              January 1997, <https://www.rfc-editor.org/info/rfc2065>.
+
+   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, DOI 10.17487/RFC2136, April 1997,
+              <https://www.rfc-editor.org/info/rfc2136>.
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
+              <https://www.rfc-editor.org/info/rfc2535>.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
+              2000, <https://www.rfc-editor.org/info/rfc2931>.
+
+   [RFC3258]  Hardie, T., "Distributing Authoritative Name Servers via
+              Shared Unicast Addresses", RFC 3258, DOI 10.17487/RFC3258,
+              April 2002, <https://www.rfc-editor.org/info/rfc3258>.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <https://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+              <https://www.rfc-editor.org/info/rfc4035>.
+
+   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+              Thayer, "OpenPGP Message Format", RFC 4880,
+              DOI 10.17487/RFC4880, November 2007,
+              <https://www.rfc-editor.org/info/rfc4880>.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
+              <https://www.rfc-editor.org/info/rfc5155>.
+
+   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
+              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
+              <https://www.rfc-editor.org/info/rfc5936>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
+              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
+              <https://www.rfc-editor.org/info/rfc8484>.
+
+   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
+              January 2019, <https://www.rfc-editor.org/info/rfc8499>.
+
+   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
+              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
+              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
+              April 2019, <https://www.rfc-editor.org/info/rfc8551>.
+
+   [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to
+              a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
+              <https://www.rfc-editor.org/info/rfc8806>.
+
+   [RFC8901]  Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
+              Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
+              DOI 10.17487/RFC8901, September 2020,
+              <https://www.rfc-editor.org/info/rfc8901>.
+
+   [RFC8945]  Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
+              Gudmundsson, O., and B. Wellington, "Secret Key
+              Transaction Authentication for DNS (TSIG)", STD 93,
+              RFC 8945, DOI 10.17487/RFC8945, November 2020,
+              <https://www.rfc-editor.org/info/rfc8945>.
+
+   [ROOT-SERVERS]
+              Root Server Operators, "root-servers.org", July 2018,
+              <https://www.root-servers.org/>.
+
+   [RPZ]      Wikipedia, "Response policy zone", May 2020,
+              <https://en.wikipedia.org/w/
+              index.php?title=Response_policy_zone&oldid=960043728>.
+
+   [ZONE-DIGEST-HACKATHON]
+              "Prototype implementation of ZONEMD for the IETF 102
+              hackathon", commit 76ad7a7, August 2019,
+              <https://github.com/shane-kerr/ZoneDigestHackathon>.
+
+   [ZONE-DIGEST-TESTS]
+              IETF, "RFC 8976 ZONEMD Test Cases", January 2021,
+              <https://trac.ietf.org/trac/dnsop/wiki/
+              RFC8976ZONEMDTestCases>.
+
+Appendix A.  Example Zones with Digests
+
+   This appendix contains example zones with accurate ZONEMD records.
+   These can be used to verify an implementation of the zone digest
+   protocol.  Additional and more extensive test cases can be found via
+   the ZONEMD Tests Wiki ([ZONE-DIGEST-TESTS]) maintained by the IETF
+   DNSOP Working Group.
+
+A.1.  Simple EXAMPLE Zone
+
+   Here, the EXAMPLE zone contains an SOA record, NS and glue records,
+   and a ZONEMD record.
+
+   example.      86400  IN  SOA     ns1 admin 2018031900 (
+                                    1800 900 604800 86400 )
+                 86400  IN  NS      ns1
+                 86400  IN  NS      ns2
+                 86400  IN  ZONEMD  2018031900 1 1 (
+                                    c68090d90a7aed71
+                                    6bc459f9340e3d7c
+                                    1370d4d24b7e2fc3
+                                    a1ddc0b9a87153b9
+                                    a9713b3c9ae5cc27
+                                    777f98b8e730044c )
+   ns1           3600   IN  A       203.0.113.63
+   ns2           3600   IN  AAAA    2001:db8::63
+
+A.2.  Complex EXAMPLE Zone
+
+   Here, the EXAMPLE zone contains duplicate RRs, an occluded RR,
+   uppercase names, a wildcard, a multi-record RRset, a non-apex ZONEMD
+   RR, and one out-of-zone RR.
+
+   example.      86400  IN  SOA     ns1 admin 2018031900 (
+                                    1800 900 604800 86400 )
+                 86400  IN  NS      ns1
+                 86400  IN  NS      ns2
+                 86400  IN  ZONEMD  2018031900 1 1 (
+                                    a3b69bad980a3504
+                                    e1cffcb0fd6397f9
+                                    3848071c93151f55
+                                    2ae2f6b1711d4bd2
+                                    d8b39808226d7b9d
+                                    b71e34b72077f8fe )
+   ns1           3600   IN  A       203.0.113.63
+   NS2           3600   IN  AAAA    2001:db8::63
+   occluded.sub  7200   IN  TXT     "I'm occluded but must be digested"
+   sub           7200   IN  NS      ns1
+   duplicate     300    IN  TXT     "I must be digested just once"
+   duplicate     300    IN  TXT     "I must be digested just once"
+   foo.test.     555    IN  TXT     "out-of-zone data must be excluded"
+   UPPERCASE     3600   IN  TXT     "canonicalize uppercase owner names"
+   *             777    IN  PTR     dont-forget-about-wildcards
+   mail          3600   IN  MX      20 MAIL1
+   mail          3600   IN  MX      10 Mail2.Example.
+   sortme        3600   IN  AAAA    2001:db8::5:61
+   sortme        3600   IN  AAAA    2001:db8::3:62
+   sortme        3600   IN  AAAA    2001:db8::4:63
+   sortme        3600   IN  AAAA    2001:db8::1:65
+   sortme        3600   IN  AAAA    2001:db8::2:64
+   non-apex      900    IN  ZONEMD  2018031900 1 1 (
+                                    616c6c6f77656420
+                                    6275742069676e6f
+                                    7265642e20616c6c
+                                    6f77656420627574
+                                    2069676e6f726564
+                                    2e20616c6c6f7765 )
+
+A.3.  EXAMPLE Zone with Multiple Digests
+
+   Here, the EXAMPLE zone contains multiple ZONEMD records.  It has both
+   SHA384 and SHA512 digests using the SIMPLE scheme.  It also includes
+   ZONEMD records with Scheme and Hash Algorithm values in the private
+   range (240-254).  These additional private-range digests are not
+   verifiable.
+
+   example.      86400  IN  SOA     ns1 admin 2018031900 (
+                                    1800 900 604800 86400 )
+   example.      86400  IN  NS      ns1.example.
+   example.      86400  IN  NS      ns2.example.
+   example.      86400  IN  ZONEMD  2018031900 1 1 (
+                                    62e6cf51b02e54b9
+                                    b5f967d547ce4313
+                                    6792901f9f88e637
+                                    493daaf401c92c27
+                                    9dd10f0edb1c56f8
+                                    080211f8480ee306 )
+   example.      86400  IN  ZONEMD  2018031900 1 2 (
+                                    08cfa1115c7b948c
+                                    4163a901270395ea
+                                    226a930cd2cbcf2f
+                                    a9a5e6eb85f37c8a
+                                    4e114d884e66f176
+                                    eab121cb02db7d65
+                                    2e0cc4827e7a3204
+                                    f166b47e5613fd27 )
+   example.      86400  IN  ZONEMD  2018031900 1 240 (
+                                    e2d523f654b9422a
+                                    96c5a8f44607bbee )
+   example.      86400  IN  ZONEMD  2018031900 241 1 (
+                                    e1846540e33a9e41
+                                    89792d18d5d131f6
+                                    05fc283e )
+   ns1.example.  3600   IN  A       203.0.113.63
+   ns2.example.  86400  IN  TXT     "This example has multiple digests"
+   NS2.EXAMPLE.  3600   IN  AAAA    2001:db8::63
+
+A.4.  The URI.ARPA Zone
+
+   The following sample zone is the URI.ARPA zone retrieved 2021-01-21.
+   Note this sample zone has been re-signed with unpublished keys, so
+   that the added ZONEMD RR also has a signature.
+
+   uri.arpa.       3600    IN      SOA     sns.dns.icann.org. (
+      noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
+   uri.arpa.       3600    IN      RRSIG   SOA 8 2 3600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       GzQw+QzwLDJr13REPGVmpEChjD1D2XlX0ie1DnWHpgaEw1E/dhs3lCN3+B
+       mHd4Kx3tffTRgiyq65HxR6feQ5v7VmAifjyXUYB1DZur1eP5q0Ms2ygCB3
+       byoeMgCNsFS1oKZ2LdzNBRpy3oace8xQn1SpmHGfyrsgg+WbHKCT1dY= )
+   uri.arpa.       86400   IN      NS      a.iana-servers.net.
+   uri.arpa.       86400   IN      NS      b.iana-servers.net.
+   uri.arpa.       86400   IN      NS      c.iana-servers.net.
+   uri.arpa.       86400   IN      NS      ns2.lacnic.net.
+   uri.arpa.       86400   IN      NS      sec3.apnic.net.
+   uri.arpa.       86400   IN      RRSIG   NS 8 2 86400 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       M+Iei2lcewWGaMtkPlrhM9FpUAHXFkCHTVpeyrjxjEONeNgKtHZor5e4V4
+       qJBOzNqo8go/qJpWlFBm+T5Hn3asaBZVstFIYky38/C8UeRLPKq1hTTHAR
+       YUlFrexr5fMtSUAVOgOQPSBfH3xBq/BgSccTdRb9clD+HE7djpqrLS4= )
+   uri.arpa.       600     IN      MX      10 pechora.icann.org.
+   uri.arpa.       600     IN      RRSIG   MX 8 2 600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       kQAJQivmv6A5hqYBK8h6Z13ESY69gmosXwKI6WE09I8RFetfrxr24ecdnY
+       d0lpnDtgNNSoHkYRSOoB+C4+zuJsoyAAzGo9uoWMWj97/2xeGhf3PTC9me
+       Q9Ohi6hul9By7OR76XYmGhdWX8PBi60RUmZ1guslFBfQ8izwPqzuphs= )
+   uri.arpa.       3600    IN      DNSKEY  256 3 8 (
+       AwEAAbMxuFuLeVDuOwIMzYOTD/bTREjLflo7wOi6ieIJhqltEzgjNzmWJf
+       9kGwwDmzxU7kbthMEhBNBZNn84zmcyRSCMzuStWveL7xmqqUlE3swL8kLO
+       vdZvc75XnmpHrk3ndTyEb6eZM7slh2C63Oh6K8VR5VkiZAkEGg0uZIT3Nj
+       sF )
+   uri.arpa.       3600    IN      DNSKEY  257 3 8 (
+       AwEAAdkTaWkZtZuRh7/OobBUFxM+ytTst+bCu0r9w+rEwXD7GbDs0pIMhM
+       enrZzoAvmv1fQxw2MGs6Ri6yPKfNULcFOSt9l8i6BVBLI+SKTY6XXeDUQp
+       SEmSaxohHeRPMQFzpysfjxINp/L2rGtZ7yPmxY/XRiFPSO0myqwGJa9r06
+       Zw9CHM5UDHKWV/E+zxPFq/I7CfPbrrzbUotBX7Z6Vh3Sarllbe8cGUB2UF
+       NaTRgwB0TwDBPRD5ER3w2Dzbry9NhbElTr7vVfhaGWeOGuqAUXwlXEg6Cr
+       NkmJXJ2F1Rzr9WHUzhp7uWxhAbmJREGfi2dEyPAbUAyCjBqhFaqglknvc= )
+   uri.arpa.       3600    IN      DNSKEY  257 3 8 (
+       AwEAAenQaBoFmDmvRT+/H5oNbm0Tr5FmNRNDEun0Jpj/ELkzeUrTWhNpQm
+       ZeIMC8I0kZ185tEvOnRvn8OvV39B17QIdrvvKGIh2HlgeDRCLolhaojfn2
+       QM0DStjF/WWHpxJOmE6CIuvhqYEU37yoJscGAPpPVPzNvnL1HhYTaao1VR
+       YWQ/maMrJ+bfHg+YX1N6M/8MnRjIKBif1FWjbCKvsn6dnuGGL9oCWYUFJ3
+       DwofXuhgPyZMkzPc88YkJj5EMvbMH4wtelbCwC+ivx732l0w/rXJn0ciQS
+       OgoeVvDio8dIJmWQITWQAuP+q/ZHFEFHPlrP3gvQh5mcVS48eLX71Bq7c= )
+   uri.arpa.       3600    IN      RRSIG   DNSKEY 8 2 3600 (
+       20210217232440 20210120232440 12670 uri.arpa.
+       DBE2gkKAoxJCfz47KKxzoImN/0AKArhIVHE7TyTwy0DdRPo44V5R+vL6th
+       UxlQ1CJi2Rw0jwAXymx5Y3Q873pOEllH+4bJoIT4dmoBmPXfYWW7Clvw9U
+       PKHRP0igKHmCVwIeBYDTU3gfLcMTbR4nEWPDN0GxlL1Mf7ITaC2Ioabo79
+       Ip3M/MR8I3Vx/xZ4ZKKPHtLn3xUuJluPNanqJrED2gTslL2xWZ1tqjsAjJ
+       v7JnJo2HJ8XVRB5zBto0IaJ2oBlqcjdcQ/0VlyoM8uOy1pDwHQ2BJl7322
+       gNMHBP9HSiUPIOaIDNUCwW8eUcW6DIUk+s9u3GN1uTqwWzsYB/rA== )
+   uri.arpa.       3600    IN      RRSIG   DNSKEY 8 2 3600 (
+       20210217232440 20210120232440 30577 uri.arpa.
+       Kx6HwP4UlkGc1UZ7SERXtQjPajOF4iUvkwDj7MEG1xbQFB1KoJiEb/eiW0
+       qmSWdIhMDv8myhgauejRLyJxwxz8HDRV4xOeHWnRGfWBk4XGYwkejVzOHz
+       oIArVdUVRbr2JKigcTOoyFN+uu52cNB7hRYu7dH5y1hlc6UbOnzRpMtGxc
+       gVyKQ+/ARbIqGG3pegdEOvV49wTPWEiyY65P2urqhvnRg5ok/jzwAdMx4X
+       Gshiib7Ojq0sRVl2ZIzj4rFgY/qsSO8SEXEhMo2VuSkoJNiofVzYoqpxEe
+       GnANkIT7Tx2xJL1BWyJxyc7E8Wr2QSgCcc+rYL6IkHDtJGHy7TaQ== )
+   uri.arpa.       3600    IN      ZONEMD  2018100702 1 1 (
+       0dbc3c4dbfd75777c12ca19c337854b1577799901307c482e9d91d5d15
+       cd934d16319d98e30c4201cf25a1d5a0254960 )
+   uri.arpa.       3600    IN      RRSIG   ZONEMD 8 2 3600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       QDo4XZcL3HMyn8aAHyCUsu/Tqj4Gkth8xY1EqByOb8XOTwVtA4ZNQORE1s
+       iqNqjtJUbeJPtJSbLNqCL7rCq0CzNNnBscv6IIf4gnqJZjlGtHO30ohXtK
+       vEc4z7SU3IASsi6bB3nLmEAyERdYSeU6UBfx8vatQDIRhkgEnnWUTh4= )
+   uri.arpa.       3600    IN      NSEC    ftp.uri.arpa. (
+       NS SOA MX RRSIG NSEC DNSKEY ZONEMD )
+   uri.arpa.       3600    IN      RRSIG   NSEC 8 2 3600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       dU/rXLM/naWd1+1PiWiYVaNJyCkiuyZJSccr91pJI673T8r3685B4ODMYF
+       afZRboVgwnl3ZrXddY6xOhZL3n9V9nxXZwjLJ2HJUojFoKcXTlpnUyYUYv
+       VQ2kj4GHAo6fcGCEp5QFJ2KbCpeJoS+PhKGRRx28icCiNT4/uXQvO2E= )
+   ftp.uri.arpa.   604800  IN      NAPTR   0 0 "" "" (
+       "!^ftp://([^:/?#]*).*$!\\1!i" . )
+   ftp.uri.arpa.   604800  IN      RRSIG   NAPTR 8 3 604800 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       EygekDgl+Lyyq4NMSEpPyOrOywYf9Y3FAB4v1DT44J3R5QGidaH8l7ZFjH
+       oYFI8sY64iYOCV4sBnX/dh6C1L5NgpY+8l5065Xu3vvjyzbtuJ2k6YYwJr
+       rCbvl5DDn53zAhhO2hL9uLgyLraZGi9i7TFGd0sm3zNyUF/EVL0CcxU= )
+   ftp.uri.arpa.   3600    IN      NSEC    http.uri.arpa. (
+       NAPTR RRSIG NSEC )
+   ftp.uri.arpa.   3600    IN      RRSIG   NSEC 8 3 3600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       pbP4KxevPXCu/bDqcvXiuBppXyFEmtHyiy0eAN5gS7mi6mp9Z9bWFjx/Ld
+       H9+6oFGYa5vGmJ5itu/4EDMe8iQeZbI8yrpM4TquB7RR/MGfBnTd8S+sjy
+       QtlRYG7yqEu77Vd78Fme22BKPJ+MVqjS0JHMUE/YUGomPkAjLJJwwGw= )
+   http.uri.arpa.  604800  IN      NAPTR   0 0 "" "" (
+       "!^http://([^:/?#]*).*$!\\1!i" . )
+   http.uri.arpa.  604800  IN      RRSIG   NAPTR 8 3 604800 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       eTqbWvt1GvTeXozuvm4ebaAfkXFQKrtdu0cEiExto80sHIiCbO0WL8UDa/
+       J3cDivtQca7LgUbOb6c17NESsrsVkc6zNPx5RK2tG7ZQYmhYmtqtfg1oU5
+       BRdHZ5TyqIXcHlw9Blo2pir1Y9IQgshhD7UOGkbkEmvB1Lrd0aHhAAg= )
+   http.uri.arpa.  3600    IN      NSEC    mailto.uri.arpa. (
+       NAPTR RRSIG NSEC )
+   http.uri.arpa.  3600    IN      RRSIG   NSEC 8 3 3600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       R9rlNzw1CVz2N08q6DhULzcsuUm0UKcPaGAWEU40tr81jEDHsFHNM+khCd
+       OI8nDstzA42aee4rwCEgijxJpRCcY9hrO1Ysrrr2fdqNz60JikMdarvU5O
+       0p0VXeaaJDfJQT44+o+YXaBwI7Qod3FTMx7aRib8i7istvPm1Rr7ixA= )
+   mailto.uri.arpa.        604800  IN      NAPTR   0 0 "" "" (
+       "!^mailto:(.*)@(.*)$!\\2!i" . )
+   mailto.uri.arpa.        604800  IN      RRSIG   NAPTR 8 3 604800 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       Ch2zTG2F1plEvQPyIH4Yd80XXLjXOPvMbiqDjpJBcnCJsV8QF7kr0wTLnU
+       T3dB+asQudOjPyzaHGwFlMzmrrAsszN4XAMJ6htDtFJdsgTMP/NkHhYRSm
+       Vv6rLeAhd+mVfObY12M//b/GGVTjeUI/gJaLW0fLVZxr1Fp5U5CRjyw= )
+   mailto.uri.arpa.        3600    IN      NSEC    urn.uri.arpa. (
+       NAPTR RRSIG NSEC )
+   mailto.uri.arpa.        3600    IN      RRSIG   NSEC 8 3 3600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       fQUbSIE6E7JDi2rosah4SpCOTrKufeszFyj5YEavbQuYlQ5cNFvtm8KuE2
+       xXMRgRI4RGvM2leVqcoDw5hS3m2pOJLxH8l2WE72YjYvWhvnwc5Rofe/8y
+       B/vaSK9WCnqN8y2q6Vmy73AGP0fuiwmuBra7LlkOiqmyx3amSFizwms= )
+   urn.uri.arpa.   604800  IN      NAPTR   0 0 "" "" (
+       "/urn:([^:]+)/\\1/i" . )
+   urn.uri.arpa.   604800  IN      RRSIG   NAPTR 8 3 604800 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       CVt2Tgz0e5ZmaSXqRfNys/8OtVCk9nfP0zhezhN8Bo6MDt6yyKZ2kEEWJP
+       jkN7PCYHjO8fGjnUn0AHZI2qBNv7PKHcpR42VY03q927q85a65weOO1YE0
+       vPYMzACpua9TOtfNnynM2Ws0uN9URxUyvYkXBdqOC81N3sx1dVELcwc= )
+   urn.uri.arpa.   3600    IN      NSEC    uri.arpa. NAPTR RRSIG NSEC
+   urn.uri.arpa.   3600    IN      RRSIG   NSEC 8 3 3600 (
+       20210217232440 20210120232440 37444 uri.arpa.
+       JuKkMiC3/j9iM3V8/izcouXWAVGnSZjkOgEgFPhutMqoylQNRcSkbEZQzF
+       K8B/PIVdzZF0Y5xkO6zaKQjOzz6OkSaNPIo1a7Vyyl3wDY/uLCRRAHRJfp
+       knuY7O+AUNXvVVIEYJqZggd4kl/Rjh1GTzPYZTRrVi5eQidI1LqCOeg= )
+
+A.5.  The ROOT-SERVERS.NET Zone
+
+   The following sample zone is the ROOT-SERVERS.NET zone retrieved
+   2018-10-21.
+
+   root-servers.net.     3600000 IN  SOA     a.root-servers.net. (
+       nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
+   root-servers.net.     3600000 IN  NS      a.root-servers.net.
+   root-servers.net.     3600000 IN  NS      b.root-servers.net.
+   root-servers.net.     3600000 IN  NS      c.root-servers.net.
+   root-servers.net.     3600000 IN  NS      d.root-servers.net.
+   root-servers.net.     3600000 IN  NS      e.root-servers.net.
+   root-servers.net.     3600000 IN  NS      f.root-servers.net.
+   root-servers.net.     3600000 IN  NS      g.root-servers.net.
+   root-servers.net.     3600000 IN  NS      h.root-servers.net.
+   root-servers.net.     3600000 IN  NS      i.root-servers.net.
+   root-servers.net.     3600000 IN  NS      j.root-servers.net.
+   root-servers.net.     3600000 IN  NS      k.root-servers.net.
+   root-servers.net.     3600000 IN  NS      l.root-servers.net.
+   root-servers.net.     3600000 IN  NS      m.root-servers.net.
+   a.root-servers.net.   3600000 IN  AAAA    2001:503:ba3e::2:30
+   a.root-servers.net.   3600000 IN  A       198.41.0.4
+   b.root-servers.net.   3600000 IN  MX      20 mail.isi.edu.
+   b.root-servers.net.   3600000 IN  AAAA    2001:500:200::b
+   b.root-servers.net.   3600000 IN  A       199.9.14.201
+   c.root-servers.net.   3600000 IN  AAAA    2001:500:2::c
+   c.root-servers.net.   3600000 IN  A       192.33.4.12
+   d.root-servers.net.   3600000 IN  AAAA    2001:500:2d::d
+   d.root-servers.net.   3600000 IN  A       199.7.91.13
+   e.root-servers.net.   3600000 IN  AAAA    2001:500:a8::e
+   e.root-servers.net.   3600000 IN  A       192.203.230.10
+   f.root-servers.net.   3600000 IN  AAAA    2001:500:2f::f
+   f.root-servers.net.   3600000 IN  A       192.5.5.241
+   g.root-servers.net.   3600000 IN  AAAA    2001:500:12::d0d
+   g.root-servers.net.   3600000 IN  A       192.112.36.4
+   h.root-servers.net.   3600000 IN  AAAA    2001:500:1::53
+   h.root-servers.net.   3600000 IN  A       198.97.190.53
+   i.root-servers.net.   3600000 IN  MX      10 mx.i.root-servers.org.
+   i.root-servers.net.   3600000 IN  AAAA    2001:7fe::53
+   i.root-servers.net.   3600000 IN  A       192.36.148.17
+   j.root-servers.net.   3600000 IN  AAAA    2001:503:c27::2:30
+   j.root-servers.net.   3600000 IN  A       192.58.128.30
+   k.root-servers.net.   3600000 IN  AAAA    2001:7fd::1
+   k.root-servers.net.   3600000 IN  A       193.0.14.129
+   l.root-servers.net.   3600000 IN  AAAA    2001:500:9f::42
+   l.root-servers.net.   3600000 IN  A       199.7.83.42
+   m.root-servers.net.   3600000 IN  AAAA    2001:dc3::35
+   m.root-servers.net.   3600000 IN  A       202.12.27.33
+   root-servers.net.     3600000 IN  SOA     a.root-servers.net. (
+       nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
+   root-servers.net.     3600000 IN  ZONEMD  2018091100 1 1 (
+       f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97
+       8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 )
+
+Appendix B.  Implementation Status
+
+   This section records the status of known implementations of the
+   protocol defined by this specification at the time of publication,
+   and is inspired by the concepts described in RFC 7942.
+
+   Please note that the listing of any individual implementation here
+   does not imply endorsement by the IETF.  Furthermore, no effort has
+   been spent to verify the information presented here that was supplied
+   by IETF contributors.  This is not intended as, and must not be
+   construed to be, a catalog of available implementations or their
+   features.  Readers are advised to note that other implementations may
+   exist.
+
+B.1.  Authors' Implementation
+
+   The authors have an open-source implementation in C, using the ldns
+   library ([LDNS-ZONE-DIGEST]).  This implementation is able to perform
+   the following functions:
+
+   *  Read an input zone and output a zone with the ZONEMD placeholder.
+
+   *  Compute the zone digest over the signed zone and update the ZONEMD
+      record.
+
+   *  Recompute DNSSEC signatures over the ZONEMD record.
+
+   *  Verify the zone digest from an input zone.
+
+   This implementation does not:
+
+   *  Perform DNSSEC validation of the ZONEMD record during
+      verification.
+
+B.2.  Shane Kerr's Implementation
+
+   Shane Kerr wrote an implementation of this specification during the
+   IETF 102 hackathon ([ZONE-DIGEST-HACKATHON]).  This implementation is
+   in Python and is able to perform the following functions:
+
+   *  Read an input zone and output a zone with ZONEMD record.
+
+   *  Verify the zone digest from an input zone.
+
+   *  Output the ZONEMD record in its defined presentation format.
+
+   This implementation does not:
+
+   *  Recompute DNSSEC signatures over the ZONEMD record.
+
+   *  Perform DNSSEC validation of the ZONEMD record.
+
+B.3.  NIC Chile Lab's Implementation
+
+   NIC Chile Labs wrote an implementation of this specification as part
+   of "dns-tools" suite ([DNS-TOOLS]), which besides digesting, can also
+   sign and verify zones.  This implementation is in Go and is able to
+   perform the following functions:
+
+   *  Compute zone digest over signed zone and update the ZONEMD record.
+
+   *  Verify the zone digest from an input zone.
+
+   *  Perform DNSSEC validation of the ZONEMD record during
+      verification.
+
+   *  Recompute DNSSEC signatures over the ZONEMD record.
+
+Acknowledgments
+
+   The authors wish to thank David Blacka, Scott Hollenbeck, and Rick
+   Wilhelm for providing feedback on early drafts of this document.
+   Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
+   Donald Eastlake 3rd, Richard Gibson, Olafur Gudmundsson, Bob Harold,
+   Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns,
+   Burt Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed
+   Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury,
+   Willem Toorop, Florian Weimer, Tim Wicinski, Wouter Wijngaards, Paul
+   Wouters, and other members of the DNSOP Working Group for their
+   input.
+
+   The authors would again like to thank Tim Wicinski, who served as the
+   Document Shepherd for this document.
+
+Authors' Addresses
+
+   Duane Wessels
+   Verisign
+   12061 Bluemont Way
+   Reston, VA 20190
+   United States of America
+
+   Phone: +1 703 948-3200
+   Email: dwessels@verisign.com
+   URI:   https://verisign.com
+
+
+   Piet Barber
+   Verisign
+   12061 Bluemont Way
+   Reston, VA 20190
+   United States of America
+
+   Phone: +1 703 948-3200
+   Email: pbarber@verisign.com
+   URI:   https://verisign.com
+
+
+   Matt Weinberg
+   Amazon
+
+   Email: matweinb@amazon.com
+   URI:   https://amazon.com
+
+
+   Warren Kumari
+   Google
+   1600 Amphitheatre Parkway
+   Mountain View, CA 94043
+   United States of America
+
+   Email: warren@kumari.net
+
+
+   Wes Hardaker
+   USC/ISI
+   P.O. Box 382
+   Davis, CA 95617
+   United States of America
+
+   Email: ietf@hardakers.net