<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. --><!ENTITY RFC5966 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5966.xml">
<!ENTITY I-D.ietf-dprive-xfr-over-tls SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dprive-xfr-over-tls-02.xml">
<!ENTITY RFC1034 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1995 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml">
<!ENTITY RFC2065 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2065.xml">
<!ENTITY RFC2119 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2136 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml">
<!ENTITY RFC2181 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC2535 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2535.xml">
<!ENTITY RFC2629 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC2845 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2845.xml">
<!ENTITY RFC2931 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml">
<!ENTITY RFC3258 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3258.xml">
<!ENTITY RFC3658 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3658.xml">
<!ENTITY RFC4033 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4509 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4509.xml">
<!ENTITY RFC4880 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml">
<!ENTITY RFC5155 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml">
<!ENTITY RFC5751 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY RFC5933 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5933.xml">
<!ENTITY RFC5936 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml">
<!ENTITY RFC6234 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml">
<!ENTITY RFC7696 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml">
<!ENTITY RFC8806 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml">
<!ENTITY RFC8126 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8484 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml">
<!ENTITY RFC8499 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml">
<!ENTITY RFC8901 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8901.xml">
<!ENTITY RRNAME "ZONEMD">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dnsop-dns-zone-digest-14" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
  ipr values: full3667, noModification3667, noDerivatives3667
  you can add the attributes updates="NNNN" and obsoletes="NNNN"
  they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** --> number="8976" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
version="3">

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
    full title is longer than 39 characters -->

    <title abbrev="DNS Zone Digest">Message Digest for DNS Zones</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->
    <seriesInfo name="RFC" value="8976"/>

    <author fullname="Duane Wessels" initials="D." surname="Wessels">
      <organization>Verisign</organization>
      <address>
        <postal>
          <street>12061 Bluemont Way</street>
          <city>Reston</city>
          <region>VA</region>
          <code>20190</code>
<country>United States of America
</country>
        </postal>

        <phone>+1 703 948-3200</phone>
        <email>dwessels@verisign.com</email>
        <uri>https://verisign.com</uri>
      </address>
    </author>
    <author fullname="Piet Barber" initials="P." surname="Barber">
      <organization>Verisign</organization>
      <address>
        <postal>
          <street>12061 Bluemont Way</street>
          <city>Reston</city>
          <region>VA</region>
          <code>20190</code>
<country>United States of America
</country>
        </postal>
        <phone>+1 703 948-3200</phone>
        <email>pbarber@verisign.com</email>
        <uri>https://verisign.com</uri>
      </address>
    </author>

    <author fullname="Matt Weinberg" initials="M." surname="Weinberg">
      <organization>Amazon</organization>
      <address>
        <email>matweinb@amazon.com</email>
        <uri>https://amazon.com</uri>
      </address>
    </author>

  <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
<country>United States of America
</country>
        </postal>
        <email>warren@kumari.net</email>
      </address>
  </author>

    <author fullname="Wes Hardaker" initials="W." surname="Hardaker">
      <organization>USC/ISI</organization>
      <address>
        <postal>
          <street>P.O. Box 382</street>
          <city>Davis</city>
          <region>CA</region>
          <code>95617</code>
<country>United States of America
</country>
        </postal>
        <email>ietf@hardakers.net</email>
      </address>
    </author>

    <date day="15" month="October" year="2020"/> month="January" year="2021"/>
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>DNS</keyword>
    <keyword>DNSSEC</keyword>
    <keyword>Checksum</keyword>
    <keyword>Hash</keyword>
    <keyword>Zone Transfer</keyword>
    <abstract>
      <t>
        This document describes a protocol and new DNS Resource Record that
        provides a cryptographic message digest over DNS zone data at rest.
        The &RRNAME; ZONEMD Resource Record conveys the digest data in the zone itself.
        When used in combination with DNSSEC, &RRNAME; 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, &RRNAME; ZONEMD functions as a checksum,
        guarding only against unintentional changes.
      </t>
      <t>
        &RRNAME;

        ZONEMD does not replace DNSSEC.
        Whereas DNSSEC:
        DNSSEC protects individual RRSets RRsets (DNS data with
        fine granularity), &RRNAME; whereas ZONEMD protects a zone's data
        as a whole, whether consumed by authoritative name
        servers, recursive name servers, or any other applications.
      </t>
      <t>
        As specified herein, &RRNAME; ZONEMD is impractical
        for large, dynamic zones due to the time and resources
        required for digest calculation.
        However, The &RRNAME; the ZONEMD record is extensible
        so that new digest schemes may be added in the future to support large, dynamic
        zones.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        In the DNS, a zone is the collection of authoritative resource records
        (RRs) sharing a common origin (<xref target="RFC8499"/>). target="RFC8499"
        format="default"/>).  Zones are often stored as files in the so-called
        master
        "master file format <xref target="RFC1034"/>. format" (<xref target="RFC1034" format="default"/>).  Zones
        are generally distributed among name servers using the AXFR (zone zone transfer <xref target="RFC5936"/>),
        (AXFR) (<xref target="RFC5936" format="default"/>) and IXFR (incremental incremental zone
        transfer <xref target="RFC1995"/>) (IXFR) (<xref target="RFC1995" format="default"/>) protocols.
        They can also be distributed outside of the DNS, 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.
      </t>

      <t>
        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, format such as whitespace,
        capitalization, and comments.
      </t>
      <t>
        This specification is OPTIONAL <bcp14>OPTIONAL</bcp14> to implement by both publishers
        and consumers of zone data.
      </t>
      <section title="Motivation"> numbered="true" toc="default">
        <name>Motivation</name>
        <t>
          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 as published by the
          zone operator.
        </t>
        <t>
          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:
          <list style="numbers">
          <t>whether
        </t>
        <ol spacing="normal" type="1"><li>whether or not to expect DNSSEC
        records in the zone,</t>
          <t>whether zone,</li>
          <li>whether or not to expect a &RRNAME; ZONEMD record in a signed zone, and</t>
          <t>whether and</li>
          <li>whether or not the &RRNAME; ZONEMD record has been altered since it was signed.</t>
          </list>
        </t> signed.</li>
        </ol>
        <t>
          A secondary motivation is to provide the equivalent of a checksum,
          allowing a zone recipient to check for unintended changes and
          operational errors, errors such as accidental truncation.
        </t>
      </section>
      <section title="Alternative Approaches"> numbered="true" toc="default">
        <name>Alternative Approaches</name>

        <t>
          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
          (TSIG <xref target="RFC2845"/>). (TSIGs) (<xref target="RFC8945"
          format="default"/>). 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 <xref target="RFC2136"/>, (<xref
          target="RFC2136" format="default"/>), AXFR <xref target="RFC5936"/>, (<xref target="RFC5936"
          format="default"/>), and IXFR <xref target="RFC1995"/> (<xref target="RFC1995"
          format="default"/>) messages.
        </t>
        <t>
          DNS Request and Transaction Signatures (SIG(0) <xref
          target="RFC2931"/>) (SIG(0)) (<xref
          target="RFC2931" format="default"/>) 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.
        </t>
        <t>
          The Transport Layer Security protocol suite also provides channel
          security.  The DPRIVE working group Working Group is in the process of specifying
          DNS Zone Transfer-over-TLS <xref target="I-D.ietf-dprive-xfr-over-tls"/>. (<xref
          target="I-D.ietf-dprive-xfr-over-tls" format="default"/>).  One can
          also easily imagine the distribution of zones over HTTPS-enabled web servers,
          servers as well as DNS-over-HTTPS <xref target="RFC8484"/>. (<xref target="RFC8484"
          format="default"/>).
        </t>
        <t>
          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, 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, 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, file or perhaps an incompletely
          saved incomplete saving of
          the file <xref target="disk-full-failure"/>. (<xref target="DISK-FULL-FAILURE" format="default"/>).  For
          these reasons, it is preferable to protect the integrity of the data
          itself.
        </t>

 <t>
          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. RRsets.  Additionally, denial-of-existence records
          prove that RRSets RRsets have not been added or removed.  However,
          delegations (non-apex NS records) are not signed by DNSSEC, DNSSEC and
          neither are any glue records.  &RRNAME;  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 <xref target="RFC5155"/> Opt-Out (<xref
          target="RFC5155" format="default"/>) 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.
 </t>

        <t>
          There are existing tools and protocols that provide data security,
          such as OpenPGP <xref target="RFC4880"/> (<xref target="RFC4880" format="default"/>) and
          S/MIME
          <xref target="RFC5751"/>. (<xref target="RFC8551" format="default"/>).  In fact, the
          internic.net site publishes PGP 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.  Non-detached

  Attached signatures are, are of course, 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 loaded, the signature data is lost, so it cannot be further
  propagated.
        </t>
        <t>
          It seems the desire for data security in DNS zones was envisioned
          as far back as 1997.
          <xref target="RFC2065"/> target="RFC2065" format="default"/> 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 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, <xref target="RFC2535"/>, target="RFC2535"
  format="default"/>, omits the AXFR
          SIG, SIG while at the same time introducing an
  IXFR SIG.  (Note: RFC 2535 was obsoleted by RFCs 4033, 4034, and 4035.)
        </t>
      </section>

      <section title="Design Overview"> numbered="true" toc="default">
        <name>Design Overview</name>
        <t>
          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.
        </t>
        <t>
          The zone digest is designed to be used on zones that
          have infrequent updates.  As specified herein,
          the digest is re-calculated 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.
        </t>
        <t>
          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 which 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.
        </t>
      </section>
      <section title="Use Cases">
        <section title="Root Zone"> numbered="true" toc="default">
        <name>Use Cases</name>
        <section numbered="true" toc="default">
          <name>Root Zone</name>
          <t>
            The root zone <xref target="InterNIC"/> (<xref target="InterNIC" format="default"/>) is one of
            the most widely distributed DNS zone zones on the Internet, served by
            more than 1000 separate instances <xref target="RootServers"/> (<xref target="ROOT-SERVERS"
            format="default"/>) 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. <xref target="RFC8806"/> target="RFC8806" format="default"/>
            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.
          </t>
        </section>
        <section title="Providers, numbered="true" toc="default">
          <name>Providers, Secondaries, and Anycast"> Anycast</name>
          <t>
            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 which that includes
            multiple third-party providers (<xref target="RFC8901"/>) target="RFC8901"
            format="default"/>) and hundreds of anycast instances (<xref target="RFC3258"/>).
            target="RFC3258" format="default"/>).  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.
          </t>

    </section>
        <section title="Response numbered="true" toc="default">
          <name>Response Policy Zones"> Zones</name>
          <t>
            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"
            <xref target="RPZ"/>. (<xref target="RPZ"
            format="default"/>).  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 RPZ zones RPZs can be signed with DNSSEC, the data is
            not queried directly, directly and would not be subject to DNSSEC
            validation.
          </t>
        </section>
        <section title="Centralized numbered="true" toc="default">
          <name>Centralized Zone Data Service"> Service</name>
          <t>
            ICANN operates the Centralized Zone Data Service <xref
            target="CZDS"/>, (<xref
            target="CZDS" format="default"/>), 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 &RRNAME;
            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.
          </t>
        </section>
        <section title="General numbered="true" toc="default">
          <name>General Purpose Comparison Check"> Check</name>
          <t>
            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.
          </t>
        </section>
      </section>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
          "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in
          BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>

        <t>
          The terms Private Use, Reserved, Unassigned, and Specification
          Required are to be interpreted as defined in <xref
          target="RFC8126"/>. target="RFC8126" format="default"/>.
        </t>
      </section>
    </section>
    <section title="The &RRNAME; anchor="rrtype" numbered="true" toc="default">
      <name>The ZONEMD Resource Record" anchor="rrtype"> Record</name>
      <t>
        This section describes the &RRNAME; ZONEMD Resource Record, including its fields, wire format, and presentation format.
        The Type value for the &RRNAME; ZONEMD RR is 63.
        The &RRNAME; ZONEMD RR is class independent.
        The RDATA of the resource record consists of four fields: Serial, Scheme, Hash Algorithm, and Digest.
      </t>
      <section title="Non-apex &RRNAME; Records"> numbered="true" toc="default">
        <name>Non-apex ZONEMD Records</name>
        <t>
          This document specifies &RRNAME; ZONEMD RRs located at the
          zone apex.  Non-apex &RRNAME; ZONEMD RRs are not forbidden, but
          have no meaning in this specification.
          Non-apex &RRNAME; ZONEMD RRs MUST NOT <bcp14>MUST NOT</bcp14> be used for verification.
        </t>
        <t>
          During digest calculation,
          non-apex &RRNAME; ZONEMD RRs are treated as ordinary RRs.
          They are digested as-is as is, and the RR is not replaced
          by a placeholder RR.
        </t>
        <t>
          Unless explicitly stated otherwise, "&RRNAME;" "ZONEMD" always refers
          to apex records throughout this document.
        </t>
      </section>
      <section title="&RRNAME; numbered="true" toc="default">
        <name>ZONEMD RDATA Wire Format"> Format</name>
        <t>The &RRNAME; ZONEMD RDATA wire format is encoded as follows:</t>
        <figure><artwork align="left"><![CDATA[
        <artwork align="left" name="" type="" alt=""><![CDATA[
                     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                            |
/                                                               /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
]]></artwork>
        <section title="The numbered="true" toc="default">
          <name>The Serial Field"> Field</name>
          <t>
            The Serial field is a 32-bit unsigned integer in network byte
            order. It is the serial number from the zone's SOA record (<xref target="RFC1035"/> section 3.3.13)
            target="RFC1035" sectionFormat="comma" section="3.3.13"/>) for
            which the zone digest was generated.
          </t>
          <t>
            It is included here to clearly bind the &RRNAME; ZONEMD RR to a particular
            version of the zone's content.  Without the serial number, a
            stand-alone &RRNAME; ZONEMD digest has no obvious association to any
            particular instance of a zone.
          </t>
        </section>
        <section title="The numbered="true" toc="default">
          <name>The Scheme Field"> Field</name>
          <t>
            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.
          </t>

          <t>
            Herein, SIMPLE, with Scheme value 1, is the only standardized
            Scheme defined for &RRNAME; ZONEMD records and it MUST <bcp14>MUST</bcp14> be
            supported by implementations.  The Scheme "ZONEMD Schemes" registry is further
            described in <xref target="iana"/>. target="iana" format="default"/>.
          </t>
          <t>
            Scheme values 240-254 are allocated for Private Use.
          </t>
        </section>
        <section title="The numbered="true" toc="default">
          <name>The Hash Algorithm Field"> Field</name>
          <t>
            The Hash Algorithm field is an 8-bit unsigned integer
            that identifies the cryptographic hash algorithm
            used to construct the digest.
          </t>
          <t>
            Herein, SHA384 <xref target="RFC6234"/>, (<xref target="RFC6234" format="default"/>), with
            Hash Algorithm value 1, is the only standardized Hash Algorithm
            defined for &RRNAME; ZONEMD records that MUST <bcp14>MUST</bcp14> 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
            <bcp14>MUST NOT</bcp14> be truncated, and the entire
            48 octet 48-octet
            digest is published in the &RRNAME; ZONEMD record.
          </t>
          <t>
            SHA512 <xref target="RFC6234"/>, (<xref target="RFC6234" format="default"/>), with Hash
            Algorithm value 2, is also defined for &RRNAME; records, ZONEMD records and SHOULD
            <bcp14>SHOULD</bcp14> 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 <bcp14>MUST NOT</bcp14> be
            truncated, and the entire
            64 octet 64-octet digest is published in the &RRNAME;
            ZONEMD record.
          </t>
          <t>
            Hash Algorithm values 240-254 are allocated for Private Use.
          </t>
          <t>
            The "ZONEMD Hash Algorithm Algorithms" registry
            is further described in <xref target="iana"/>. target="iana" format="default"/>.
          </t>
        </section>
        <section title="The numbered="true" toc="default">
          <name>The Digest Field"> Field</name>
          <t>
            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 &RRNAME; ZONEMD RR header.
          </t>
          <t>
            The Digest field MUST NOT <bcp14>MUST NOT</bcp14> be shorter than 12
            octets.  Digests for the SHA384 and SHA512 hash algorithms
            specified herein are never truncated.  Digests for future hash
            algorithms MAY <bcp14>MAY</bcp14> be truncated, truncated but MUST NOT <bcp14>MUST
            NOT</bcp14> be truncated to a length that results in less than
            96-bits 96
            bits (12 octets) of equivalent strength.
          </t>
          <t>
            <xref target="calculating"/> target="calculating" format="default"/>
            describes how to calculate the digest for a zone.
            <xref target="verifying"/> target="verifying" format="default"/> describes how to use the digest to
            verify the contents of a zone.
          </t>
        </section>
      </section>
      <section title="&RRNAME; numbered="true" toc="default">
        <name>ZONEMD Presentation Format"> Format</name>
        <t>
          The presentation format of the RDATA portion is as follows:
        </t>
        <t>

<ul>
        <li>
          The Serial field is represented as an unsigned decimal integer.
        </t>
        <t>
        </li>
        <li>
          The Scheme field is represented as an unsigned decimal integer.
        </t>
        <t>
        </li>
        <li>
          The Hash Algorithm field is represented as an unsigned decimal
          integer.
        </t>
        <t>
        </li>
        <li>
          The Digest is represented as a sequence of case-insensitive
          hexadecimal digits.  Whitespace is allowed within the hexadecimal
          text.
        </t>
        </li>
</ul>
      </section>
      <section title="&RRNAME; Example"> numbered="true" toc="default">
        <name>ZONEMD Example</name>
        <t>
          The following example shows a &RRNAME; ZONEMD RR in presentation format:
        </t>
        <figure><artwork>

<sourcecode type="dns-rr">
example.com. 86400 IN &RRNAME; ZONEMD 2018031500 1 1 (
    FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
    7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
        </artwork></figure>
</sourcecode>
      </section>
      <section title="Including &RRNAME; numbered="true" toc="default">
        <name>Including ZONEMD RRs in a Zone"> Zone</name>
        <t>
          The zone operator chooses an appropriate hash algorithm and
          scheme,
          scheme and includes the calculated zone digest in the apex
          &RRNAME;
          ZONEMD RRset.
          The zone operator MAY <bcp14>MAY</bcp14> choose any of the defined hash algorithms
          and schemes, including the private use Private Use code points.
        </t>

        <t>
          The &RRNAME; RRSet MAY ZONEMD RRset <bcp14>MAY</bcp14> contain multiple records to support algorithm
          agility <xref target="RFC7696"/>.
          [RFC Editor: change that to BCP 201] (<xref target="BCP201" format="default"/>).

          When multiple &RRNAME; ZONEMD RRs are present, each MUST <bcp14>MUST</bcp14>
          specify a unique Scheme and Hash Algorithm tuple.  It is RECOMMENDED
          <bcp14>RECOMMENDED</bcp14> that a zone include only one &RRNAME; ZONEMD RR,
          unless the zone operator is in the process of transitioning to a new
          scheme or hash algorithm.
        </t>
      </section>
    </section>
    <section title="Calculating anchor="calculating" numbered="true" toc="default">
      <name>Calculating the Digest" anchor="calculating"> Digest</name>
      <t>
        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 &RRNAME; ZONEMD RRs, signatures,
        and dential-of-existence denial-of-existence records that are identical to the
        ones generated by this procedure.
      </t>
      <section title="Add &RRNAME; Placeholder" anchor="placeholder"> anchor="placeholder" numbered="true" toc="default">
        <name>Add ZONEMD Placeholder</name>
        <t>
          In preparation for calculating the zone digest(s), any existing &RRNAME; ZONEMD records
          (and covering RRSIGs)
          at the zone apex
          are first deleted.
        </t>
        <t>
          Prior to calculation of the digest, and prior to signing with
          DNSSEC, one or more placeholder &RRNAME; 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 &RRNAME; ZONEMD records would also require updating the
          Type Bit Maps field of any apex NSEC/NSEC3 RRs, which then invalidates
          the calculated digest value.
        </t>
        <t>
          When multiple &RRNAME; ZONEMD RRs are published in the zone, e.g.,
          during an algorithm rollover, each MUST <bcp14>MUST</bcp14> specify a unique Scheme
          and Hash Algorithm tuple.
        </t>
        <t>
          It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the TTL of the &RRNAME; ZONEMD record
          match the TTL of the SOA. Start of Authority (SOA).  However, the TTL of
          the &RRNAME; ZONEMD record may be safely ignored during verification in all
          cases.
        </t>
        <t>
          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 &RRNAME; ZONEMD records are excluded from digest calculation,
          the value of the Digest field does not matter at this point
          in the process.
        </t>
      </section>
      <section title="Optionally numbered="true" toc="default">

        <name>Optionally, Sign the Zone"> Zone</name>
        <t>
          Following the addition of placeholder records, the zone may be
          signed with DNSSEC.  When the digest calculation is complete, and
          the &RRNAME; ZONEMD record is updated, the signature(s) for the &RRNAME; RRSet MUST ZONEMD RRset
          <bcp14>MUST</bcp14> 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.
        </t>
      </section>
      <section title="Scheme-Specific Processing" anchor="collate-iterate"> anchor="collate-iterate" numbered="true" toc="default">
        <name>Scheme-Specific Processing</name>
        <t>
          Herein, only the SIMPLE collation scheme is defined.
          Additional schemes may be defined in future updates to this document.
        </t>
        <section title="The anchor="scheme-simple" numbered="true" toc="default">
          <name>The SIMPLE Scheme" anchor="scheme-simple"> Scheme</name>
          <t>
            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.
          </t>
          <t>
            Calculation of a zone digest requires RRs to be processed in a
            consistent format and ordering.  This specification uses DNSSEC’s DNSSEC's
            canonical on-the-wire RR format (without name compression) and
            ordering as specified in Sections 6.1, 6.2, <xref target="RFC4034"
            section="6.1" sectionFormat="bare"/>, <xref target="RFC4034"
            section="6.2" sectionFormat="bare"/>, and 6.3 <xref target="RFC4034"
            section="6.3" sectionFormat="bare"/> of <xref target="RFC4034"/> target="RFC4034"
            format="default"/> with the additional provision that
            RRSets RRsets
            having the same owner name MUST <bcp14>MUST</bcp14> be numerically
            ordered, in ascending order, by their numeric RR TYPE.
          </t>

          <section title="SIMPLE anchor="simple-inclusion-exclusion" numbered="true" toc="default">
            <name>SIMPLE Scheme Inclusion/Exclusion Rules" anchor="simple-inclusion-exclusion"> Rules</name>
            <t>
              When iterating over records in the zone, the following
              inclusion/exclusion rules apply:
              <list style="symbols">
              <t>All
            </t>
            <ul spacing="normal">
              <li>All records in the zone, including glue records, MUST
              <bcp14>MUST</bcp14> be included, included unless excluded by a subsequent rule.</t>
              <t>Occluded
              rule.</li>
              <li>Occluded data (<xref target="RFC5936"/> Section 3.5) MUST be included.</t>
              <!-- V1: Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be included. -->
              <!-- V2: Only one instance of duplicate RRs with equal owner, class, type and RDATA SHALL target="RFC5936" sectionFormat="comma"
              section="3.5"/>) <bcp14>MUST</bcp14> be included (<xref target="RFC4034"/> Section 6.3). -->
              <t>If included.</li>

              <li>If there are duplicate RRs with equal owner, class, type,
              and RDATA, only one instance is included (<xref target="RFC4034"/> Section 6.3), target="RFC4034"
              sectionFormat="comma" section="6.3"/>) and the duplicates MUST
              <bcp14>MUST</bcp14> be omitted.</t>
              <t>The omitted.</li>
              <li>The placeholder apex &RRNAME; ZONEMD RR(s) MUST NOT <bcp14>MUST NOT</bcp14> be included.</t>
              <t>If included.</li>
              <li>If the zone is signed, DNSSEC RRs MUST <bcp14>MUST</bcp14> be included, except:</t>
              <t>The except:</li>
              <li>The RRSIG covering the apex &RRNAME; RRSet MUST NOT ZONEMD RRset <bcp14>MUST NOT</bcp14> be included
                because the RRSIG will be updated after all digests have been calculated.</t>
              </list>
            </t> calculated.</li>
            </ul>

          </section>
          <section title="SIMPLE numbered="true" toc="default">
            <name>SIMPLE Scheme Digest Calculation"> Calculation</name>
            <t>
              A zone digest using the SIMPLE scheme is calculated by
              concatenating all RRs in the zone, in the format and order
              described in <xref target="scheme-simple"/> target="scheme-simple" format="default"/>
              subject to the inclusion/exclusion rules described in <xref target="simple-inclusion-exclusion"/>,
              target="simple-inclusion-exclusion" format="default"/>, and then
              applying the chosen hash algorithm:
            </t>
            <figure><artwork>

 <sourcecode type="pseudocode">
digest = hash( RR(1) | RR(2) | RR(3) | ... )

where "|" denotes concatenation.
            </artwork></figure>
 </sourcecode>
          </section>
        </section>
      </section>

      <section title="Update &RRNAME; RR"> numbered="true" toc="default">
        <name>Update ZONEMD RR</name>
        <t>
          The calculated zone digest is inserted into the placeholder
          &RRNAME; ZONEMD
          RR.  Repeat for each digest if multiple digests are to be published.
        </t>
        <t>
          If the zone is signed with DNSSEC, the RRSIG record(s) covering the &RRNAME;
          RRSet MUST ZONEMD
          RRset <bcp14>MUST</bcp14> then be added or updated.  Because the &RRNAME; ZONEMD placeholder was added prior to signing,
          the zone will already have the appropriate denial-of-existence (NSEC, NSEC3) records.
        </t>
        <t>
          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 &RRNAME; ZONEMD signature MUST NOT <bcp14>MUST NOT</bcp14> also result in
          a change to the SOA serial number.  The &RRNAME; ZONEMD RR and the
          matching SOA MUST <bcp14>MUST</bcp14> be published at the same time.
        </t>
      </section>
    </section>

    <section title="Verifying anchor="verifying" numbered="true" toc="default">
      <name>Verifying Zone Digest" anchor="verifying"> Digest</name>

      <t>
        The recipient of a zone that has a &RRNAME; ZONEMD RR verifies the zone by
        calculating the digest as follows. follows:
      </t>
<aside><t>Note: If multiple &RRNAME; 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
<bcp14>MAY</bcp14> ignore a &RRNAME; ZONEMD RR if its Scheme and Hash Algorithm
violates local policy.
      </t>
      <t>
        <list style="numbers">
          <t  </t></aside>
      <ol spacing="normal" type="1"><li anchor="verify-check-dnssec"> The
      verifier MUST <bcp14>MUST</bcp14> first determine whether or not to expect
      DNSSEC records in the zone.  By examining locally configured trust
            anchors,
      anchors and, if necessary, querying for and validating DS 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 <xref
      target="verify-check-digest-count" format="counter"/> below.
          </t>
          <t
    </li>
        <li anchor="verify-check-existence">
            For zones where signatures are expected, the existence of the apex &RRNAME;
            ZONEMD record MUST <bcp14>MUST</bcp14> be validated.  If the DNSSEC
            data proves the &RRNAME;
            RRSet ZONEMD RRset does not exist, digest verification
            cannot occur.  If the DNSSEC data proves the &RRNAME; ZONEMD does exist,
            but is not found in the zone, digest verification
            MUST NOT <bcp14>MUST
            NOT</bcp14> be considered successful.
          </t>
          <t
        </li>
        <li anchor="verify-dnssec-validate">
            For zones where signatures are expected, the SOA and
            &RRNAME; RRSets MUST ZONEMD RRsets
            <bcp14>MUST</bcp14> have valid signatures, chaining up to a trust
            anchor.  If DNSSEC validation of the SOA or &RRNAME; RRSets ZONEMD RRsets fails,
            digest verification MUST NOT <bcp14>MUST NOT</bcp14> be considered
            successful.
          </t>
          <t
        </li>
        <li anchor="verify-check-digest-count">
            When multiple &RRNAME; ZONEMD RRs are present, each MUST <bcp14>MUST</bcp14>
            specify a unique Scheme and Hash Algorithm tuple.  If the &RRNAME; RRSet ZONEMD
            RRset contains more than one RR with the same Scheme and Hash
            Algorithm, digest verification for those &RRNAME; ZONEMD RRs
            MUST NOT <bcp14>MUST
            NOT</bcp14> be considered successful.
          </t>
        </li>
        <li>
          <t>
            Loop over all apex &RRNAME; ZONEMD RRs and perform the following steps:
            <list style="letters">
              <t
          </t>
          <ol spacing="normal" type="a"><li anchor="verify-check-serials"> The
          SOA Serial field MUST <bcp14>MUST</bcp14> exactly match the &RRNAME; ZONEMD Serial
          field.  If the fields do not match, digest verification MUST NOT <bcp14>MUST
          NOT</bcp14> be considered successful with this &RRNAME; ZONEMD RR.
              </t>
              <t>
        </li>
            <li>
                The Scheme field MUST <bcp14>MUST</bcp14> be checked.  If the
                verifier does not support the given scheme, verification MUST NOT
                <bcp14>MUST NOT</bcp14> be considered successful with this &RRNAME;
                ZONEMD RR.
              </t>
              <t>
            </li>
            <li>
                The Hash Algorithm field MUST <bcp14>MUST</bcp14> be checked.  If
                the verifier does not support the given hash algorithm,
                verification MUST NOT <bcp14>MUST NOT</bcp14> be considered successful
                with this &RRNAME; ZONEMD RR.
              </t>
              <t>
            </li>
            <li>
                The Digest field size MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST
                NOT</bcp14> be considered successful with this &RRNAME; ZONEMD RR.
              </t>
              <t>
            </li>
            <li>
                The zone digest is computed over the zone data as described in
                <xref target="collate-iterate"/>, target="collate-iterate" format="default"/> using the
                Scheme and Hash Algorithm for the current &RRNAME; ZONEMD RR.
              </t>
              <t>
            </li>
            <li>
                The computed digest is compared to the received digest.  If
                the two digest values match, verification is considered
                successful.  Otherwise, verification MUST NOT <bcp14>MUST NOT</bcp14>
                be considered successful for this &RRNAME; ZONEMD RR.
              </t>
            </list>
          </t>
        </list>
      </t>
            </li>
          </ol>
        </li>
      </ol>
      <t>
        Each time zone verification is performed, the verifier SHOULD <bcp14>SHOULD</bcp14>
        report the status as either successful or unsuccessful.
        When unsuccessful, the verifier SHOULD <bcp14>SHOULD</bcp14> report the reason(s) that
        verification did not succeed.
      </t>
    </section>
    <section title="IANA Considerations" anchor="iana">
      <section title="&RRNAME; RRtype"> anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>ZONEMD RRtype</name>
        <t>
          This document defines a new DNS RR type, &RRNAME;, ZONEMD, whose
          value 63 has been allocated by IANA from the "Resource
          Record (RR) TYPEs" subregistry of the "Domain Name System
          (DNS) Parameters" registry:
        </t>
        <t>Type: &RRNAME;</t>
        <t>Value: 63</t>
        <t>Meaning: Message

<dl spacing="compact">

<dt>Type:
</dt>
<dd>ZONEMD
</dd>

<dt>Value:
</dt>
<dd>63
</dd>

<dt>Meaning:
</dt>
<dd>Message Digest Over Zone Data</t>
        <t>Reference: [this document]</t> Data
</dd>

<dt>Reference:
</dt>
<dd>[RFC8976]
</dd>

</dl>

      </section>
      <section title="&RRNAME; Scheme"> numbered="true" toc="default">
        <name>ZONEMD Scheme</name>
        <t>
          IANA is requested to create has created a new
          registry
          on subregistry in the "Domain Name
          System (DNS) Parameters" web page registry as follows:
        </t>
        <t>Registry

<dl spacing="compact">

<dt>Registry Name: &RRNAME; Schemes</t>
        <t>Registration
</dt>
<dd>ZONEMD Schemes
</dd>

<dt>Registration Procedure: Specification Required</t>
        <t>Reference: [this document]</t>
        <texttable
</dt>
<dd>Specification Required
</dd>

<dt>Reference:
</dt>
<dd>[RFC8976]
</dd>

</dl>

        <table anchor="scheme-table" title="&RRNAME; align="center">
          <name>ZONEMD Scheme Registry">
        <ttcol align="left">Value</ttcol>
        <ttcol align="left">Description</ttcol>
        <ttcol align="left">Mnemonic</ttcol>
        <ttcol align="left">Reference</ttcol>

        <c>0</c>
        <c>Reserved</c>
        <c></c>
        <c></c>

        <c>1</c>
        <c>Simple &RRNAME; collation</c>
        <c>SIMPLE</c>
        <c>[this document]</c>

        <c>2-239</c>
        <c>Unassigned</c>
        <c></c>
        <c></c>

        <c>240-254</c>
        <c>Private Use</c>
        <c>N/A</c>
        <c>[this document]</c>

        <c>255</c>
        <c>Reserved</c>
        <c></c>
        <c></c>

        </texttable>
      </section>

      <section title="&RRNAME; Registry</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Mnemonic</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved</td>
              <td align="left"/>
              <td align="left">[RFC8976]</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">Simple ZONEMD collation</td>
              <td align="left">SIMPLE</td>
              <td align="left">[RFC8976]</td>
            </tr>
            <tr>
              <td align="left">2-239</td>
              <td align="left">Unassigned</td>
              <td align="left"/>
              <td align="left"/>
            </tr>
            <tr>
              <td align="left">240-254</td>
              <td align="left">Private Use</td>
              <td align="left">N/A</td>
              <td align="left">[RFC8976]</td>
            </tr>
            <tr>
              <td align="left">255</td>
              <td align="left">Reserved</td>
              <td align="left"/>
              <td align="left">[RFC8976]</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="hash-alg-registry" numbered="true" toc="default">
        <name>ZONEMD Hash Algorithm" anchor="hash-alg-registry"> Algorithms</name>
        <t>
          IANA is requested to create has created a new
          registry
          on subregistry in the "Domain Name
          System (DNS) Parameters" web page registry as follows:
        </t>
        <t>Registry

<dl spacing="compact">

<dt>Registry Name: &RRNAME;
</dt>
<dd>ZONEMD Hash Algorithms</t>
        <t>Registration Algorithms
</dd>

<dt>Registration Procedure: Specification Required</t>
        <t>Reference: [this document]</t>
        <texttable
</dt>
<dd>Specification Required
</dd>

<dt>Reference:
</dt>
<dd>[RFC8976]
</dd>

</dl>

        <table anchor="digest-type-table" title="&RRNAME; align="center">
          <name>ZONEMD Hash Algorithm Registry">
        <ttcol align="left">Value</ttcol>
        <ttcol align="left">Description</ttcol>
        <ttcol align="left">Mnemonic</ttcol>
        <ttcol align="left">Reference</ttcol>

        <c>0</c>
        <c>Reserved</c>
        <c></c>
        <c></c>

        <c>1</c>
        <c>SHA-384</c>
        <c>SHA384</c>
        <c>[this document]</c>

        <c>2</c>
        <c>SHA-512</c>
        <c>SHA512</c>
        <c>[this document]</c>

        <c>3-239</c>
        <c>Unassigned</c>
        <c></c>
        <c></c>

        <c>240-254</c>
        <c>Private Use</c>
        <c>N/A</c>
        <c>[his document]</c>

        <c>255</c>
        <c>Reserved</c>
        <c></c>
        <c></c>

        </texttable>
      </section>

    </section>

    <section title="Security Considerations" anchor="security">
      <section title="Using Algorithms Registry</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Mnemonic</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved</td>
              <td align="left"/>
              <td align="left">[RFC8976]</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">SHA-384</td>
              <td align="left">SHA384</td>
              <td align="left">[RFC8976]</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">SHA-512</td>
              <td align="left">SHA512</td>
              <td align="left">[RFC8976]</td>
            </tr>
            <tr>
              <td align="left">3-239</td>
              <td align="left">Unassigned</td>
              <td align="left"/>
              <td align="left"/>
            </tr>
            <tr>
              <td align="left">240-254</td>
              <td align="left">Private Use</td>
              <td align="left">N/A</td>
              <td align="left">[RFC8976]</td>
            </tr>
            <tr>
              <td align="left">255</td>
              <td align="left">Reserved</td>
              <td align="left"/>
              <td align="left">[RFC8976]</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <section numbered="true" toc="default">
        <name>Using Zone Digest Without DNSSEC"> without DNSSEC</name>
        <t>
          Users of &RRNAME; 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, 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 &RRNAME; ZONEMD RR.
        </t>
      </section>
      <section title="Attacks Against numbered="true" toc="default">
        <name>Attacks against the Zone Digest"> Digest</name>
        <t>
          An attacker, whose goal is to modify zone content before it is used
          by the victim, may consider a number of different approaches.
        </t>
        <t>
          The attacker might perform a downgrade attack to an unsigned
          zone.  This is why <xref target="verifying"/> target="verifying" format="default"/> talks about
          determining whether or not to expect DNSSEC
          signatures for the zone in step <xref target="verify-check-dnssec" format="counter"/>.
        </t>
        <t>
          The attacker might perform a downgrade attack by removing
          one or more &RRNAME; ZONEMD records.  Such a removal is detectable only with DNSSEC
          validation and is why <xref target="verifying"/> target="verifying" format="default"/>
          talks about checking denial-of-existence
          proofs in step <xref target="verify-check-existence" format="counter"/>
          and signature validation in step <xref target="verify-dnssec-validate" format="counter"/>.
        </t>
        <t>
          The attacker might alter the Scheme, Hash Algorithm, or Digest fields
          of the &RRNAME; ZONEMD record.  Such modifications are detectable
          only with DNSSEC validation.
        </t>
        <t>
          As stated in <xref target="RFC7696"/>, target="BCP201" format="default"/>,
          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.
        </t>
      </section>
      <section title="Use numbered="true" toc="default">
        <name>Use of Multiple &RRNAME; ZONEMD Hash Algorithms"> Algorithms</name>
        <t>
          When a zone publishes multiple &RRNAME; ZONEMD RRs, the overall security is
          only as good as the weakest hash algorithm in use.  For this reason,
          <xref target="rrtype"/> target="rrtype" format="default"/> recommends only publishing multiple &RRNAME; 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 &RRNAME; RRSet. ZONEMD RRset.
        </t>
      </section>
      <section title="DNSSEC numbered="true" toc="default">
        <name>DNSSEC Timing Considerations"> Considerations</name>
        <t>
          As with all DNSSEC signatures, the ability to perform signature
          validation of a &RRNAME; 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 &RRNAME; RRSet. ZONEMD RRset.
          This could happen even if the &RRNAME; 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.
        </t>
        <t>
          For zones where it may be important to validate a &RRNAME;
          RRSet ZONEMD
          RRset through its entire signature validity period, the zone
          operator should ensure that KSK rollover timing takes this
          into consideration.
        </t>
      </section>
      <section title="Attacks numbered="true" toc="default">
        <name>Attacks Utilizing &RRNAME; Queries"> ZONEMD Queries</name>
        <t>
          Nothing in this specification prevents clients from making,
          and servers from responding to, &RRNAME; ZONEMD queries.
          Servers SHOULD NOT <bcp14>SHOULD NOT</bcp14> calculate zone digests dynamically (for
          each query) as this can be used as a CPU resource exhaustion
          attack.
        </t>
        <t>
          &RRNAME;
          ZONEMD responses could be used in
          a distributed denial-of-service amplification attack.
          The &RRNAME; ZONEMD RR is moderately sized, much like the DS RR.
          <!-- SHA384 SIMPLE for . is 65 bytes -->
          <!-- SHA512 SIMPLE for example.com is 93 bytes -->

          A single &RRNAME; ZONEMD RR contributes approximately 65 to 95
          octets to a DNS response, response for digest
          types defined herein.  Other RR types, such as DNSKEY, DNS Public Key (DNSKEY), can result in larger
          amplification effects.
        </t>
      </section>
      <section title="Resilience numbered="true" toc="default">
        <name>Resilience and Fragility"> Fragility</name>
        <t>
          &RRNAME;
          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 &RRNAME; ZONEMD records should
          be aware of these tradeoffs. trade-offs.  While the intention is to secure the
          zone data, misconfigurations or implementation bugs are generally
          indistinguishable from intentional tampering, tampering and could lead to
          service failures when verification is performed automatically.
        </t>
        <t>
          Zone publishers may want to deploy &RRNAME; gradually, ZONEMD gradually perhaps
          by utilizing one of the private use Private Use hash algorithm code points listed
          in <xref target="hash-alg-registry"/>. target="hash-alg-registry" format="default"/>.  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.
        </t>
      </section>

    </section>
    <section title="Performance Considerations" anchor="performance"> anchor="performance" numbered="true" toc="default">
      <name>Performance Considerations</name>
      <t>
        This section is provided to make zone publishers aware of the
        performance requirements and implications of including &RRNAME; ZONEMD
        RRs in a zone.
      </t>
      <section title="SIMPLE SHA384"> numbered="true" toc="default">
        <name>SIMPLE SHA384</name>
        <t>
          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 &RRNAME; ZONEMD
          in such zones, 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 &RRNAME; ZONEMD
          only be used when digest calculation time is significantly
          less than propagation times and update intervals.
        </t>
        <t>
          The authors' implementation (<xref
          target="authors-implementation"/>) target="authors-implementation"
          format="default"/>) includes an option to record and report CPU
          usage of its operation.  The software was used to generate digests
          for more than 800
          TLD Top-Level Domain (TLD) zones available from <xref target="CZDS"/>.
          target="CZDS" format="default"/>.  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.
        </t>
        <texttable>
          <ttcol
        <table align="center">
          <thead>
            <tr>
              <th align="right">Zone Size (RRs)</ttcol>
          <ttcol (RRs)</th>
              <th align="right">Rate (msec/RR)</ttcol>
          <c>10 (msec/RR)</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="right">10 - 99</c>  <c>0.00683</c>
          <c>100 99</td>
              <td align="right">0.00683</td>
            </tr>
            <tr>
              <td align="right">100 - 999</c>  <c>0.00551</c>
          <c>1000 999</td>
              <td align="right">0.00551</td>
            </tr>
            <tr>
              <td align="right">1000 - 9999</c>  <c>0.00505</c>
          <c>10000 9999</td>
              <td align="right">0.00505</td>
            </tr>
            <tr>
              <td align="right">10000 - 99999</c>  <c>0.00602</c>
          <c>100000 99999</td>
              <td align="right">0.00602</td>
            </tr>
            <tr>
              <td align="right">100000 - 999999</c>  <c>0.00845</c>
          <c>1000000 999999</td>
              <td align="right">0.00845</td>
            </tr>
            <tr>
              <td align="right">1000000 - 9999999</c>  <c>0.0108</c>
          <c>10000000 9999999</td>
              <td align="right">0.0108</td>
            </tr>
            <tr>
              <td align="right">10000000 - 99999999</c>  <c>0.0148</c>
        </texttable> 99999999</td>
              <td align="right">0.0148</td>
            </tr>
          </tbody>
        </table>
        <t>
          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.
        </t>
        <t>
          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, times and
          then averaged, with a different random sorting of the input data
          prior to each measurement.
        </t>
      </section>
    </section>
    <section title="Privacy Considerations" anchor="privacy"> anchor="privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>This specification has no impact on user privacy.</t>
    </section>

    <section title="Acknowledgments" anchor="acknowledgments">
      <t>
        The authors wish to thank David Blacka, Scott Hollenbeck, and Rick Wilhelm
        for providing feedback on early drafts

  </middle>
  <back>

<displayreference target="I-D.ietf-dprive-xfr-over-tls" to="DPRIVE-XFR-OVER-TLS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2065.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2535.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3258.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml"/>

<referencegroup anchor="BCP201" target="https://www.rfc-editor.org/info/bcp201">
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml"/>
</referencegroup>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8901.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-dprive-xfr-over-tls.xml"/>

        <reference anchor="InterNIC" target="ftp://ftp.internic.net/domain/">
          <front>
            <title>Index of this document.  Additionally, they
	      thank Joe Abley,  Mark Andrews,  Ralph Dolmans,  Donald Eastlake,
        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 ftp://rs.internic.net/</title>
            <author>
              <organization>InterNIC</organization>
            </author>
            <date year="2018" month="May"/>
          </front>
        </reference>

        <reference anchor="ROOT-SERVERS" target="https://www.root-servers.org/">
          <front>
            <title>root-servers.org</title>
            <author>
              <organization>Root Server Operators</organization>
            </author>
            <date year="2018" month="July"/>
          </front>
        </reference>

        <reference anchor="LDNS-ZONE-DIGEST" target="https://github.com/verisign/ldns-zone-digest">
          <front>
            <title>Implementation of the
        DNSOP working group Message Digests for their input.
      </t>
    </section>

    <section anchor="Changes" title="Change Log">
      <t>RFC Editor: Please remove this section before publication.</t>
      <t>This section lists substantial changes to the document as it is being worked on.</t>
      <t>From -00 to -01:
      <list style="symbols">
        <t>Removed requirement to sort by RR CLASS.</t>
        <t>Added Kumari and Hardaker as coauthors.</t>
        <t>Added Change Log section.</t>
        <t>Minor clarifications and grammatical edits.</t>
      </list></t>
      <t>From -01 to -02:
      <list style="symbols">
        <t>Emphasize desire for data security over channel security.</t>
        <t>Expanded motivation into its own subsection.</t>
        <t>Removed discussion topic whether or not to include serial in &RRNAME;.</t>
        <t>Clarified that a zone's NS records always sort before the SOA record.</t>
        <t>Clarified that all records in the zone must are digested, except as specified in
        the exclusion rules.</t>
        <t>Added for discussion out-of-zone and occluded records.</t>
        <t>Clarified that update of &RRNAME; signature must not cause a serial number change.</t>
        <t>Added persons to acknowledgments.</t>
      </list></t>
      <t>From -02 to -03:
      <list style="symbols">
        <t>Added recommendation to set &RRNAME; TTL to SOA TTL.</t>
        <t>Clarified that digest input uses uncompressed names.</t>
        <t>Updated Implementations section.</t>
        <t>Changed intended status from Standards Track to Experimental and added Scope of Experiment section.</t>
        <t>Updated Motivation, Introduction, and Design Overview sections in response to working group discussion.</t>
        <t>Gave &RRNAME; digest types their own status, separate from DS digest types.  Request IANA to create a registry.</t>
        <t>Added Reserved field for future work supporting dynamic updates.</t>
        <t>Be more rigorous about having just ONE &RRNAME; record in the zone.</t>
        <t>Expanded use cases.</t>
      </list></t>
      <t>From -03 to -04:
      <list style="symbols">
       <t>Added an appendix with example zones and digests.</t>
       <t>Clarified that only apex &RRNAME; RRs shall be processed.</t>
      </list></t>
      <t>From -04 to -05:
      <list style="symbols">
       <t>Made SHA384 the only supported &RRNAME; digest type.</t>
       <t>Disassociated &RRNAME; digest types from DS digest types.</t>
       <t>Updates to Introduction based on list feedback.</t>
       <t>Changed "zone file" to "zone" everywhere.</t>
       <t>Restored text about why &RRNAME; has a Serial field.</t>
       <t>Clarified ordering of RRSets having same owner to be numerically ascending.</t>
       <t>Clarified that all duplicate RRs (not just SOA) must be suppressed in digest calculation.</t>
       <t>Clarified that the Reserved field must be set to zero and checked for zero in verification.</t>
       <t>Clarified that occluded data must be included.</t>
       <t>Clarified procedure for verification, using temporary location for received digest.</t>
       <t>Explained why Reserved field is 8-bits.</t>
       <t>IANA Considerations section now more specific.</t>
       <t>Added complex zone to examples.</t>
       <t></t>
      </list></t>
      <t>From -05 to -06:
      <list style="symbols">
       <t>RR type code 63 was assigned to &RRNAME; by IANA.</t>
      </list></t>
      <t>From -06 to -07:
      <list style="symbols">
       <t>Fixed mistakes in &RRNAME; examples.</t>
       <t>Added private use Digest Type values 240-254.</t>
       <t>Clarified that Digest field must not be empty.</t>
      </list></t>
      <t>From -07 to draft-ietf-dnsop-dns-zone-digest-00:
      <list style="symbols">
        <t>Adopted by dnsop.</t>
        <t>Clarified further that non-apex &RRNAME; RRs have no meaning.</t>
        <t>Changed "provably [un]signed" to "provably [in]secure".</t>
        <t>Allow multiple &RRNAME; RRs to support algorithm agility/rollovers.</t>
        <t>Describe verification when there are multiple &RRNAME; RRs.</t>
      </list></t>
      <t>From -00 to -01:
      <list style="symbols">
        <t>Simplified requirements around verifying multiple digests.  Any one match is sufficient.</t>
        <t>Updated implementation notes.</t>
        <t>Both implementations produce expected results on examples given in this document.</t>
      </list></t>
      <t>From -01 to -02:
      <list style="symbols">
        <t>Changed the name of the Reserved field to Parameter.</t>
        <t>Changed the name of Digest Type 1 from SHA384 to SHA384-STABLE.</t>
        <t>The meaning of the Parameter field now depends on Digest Type.</t>
        <t>No longer require Parameter field to be zero in verification.</t>
        <t>Updated a rule from earlier versions that said multiple &RRNAME; RRs were not allowed.</t>
      </list></t>
      <t>From -02 to -03:
      <list style="symbols">
        <t>Changed the name of Digest Type 1 from SHA384-STABLE to SHA384-SIMPLE.</t>
        <t>Changed document status from Experimental to Standards Track.</t>
        <t>Removed Scope of Experimentation section.</t>
      </list></t>
      <t>From -03 to -04:
      <list style="symbols">
        <t>Addressing WGLC feedback.</t>
        <t>Changed from "Digest Type + Paramter" to "Scheme + Hash Algorithm".  This should make it more obvious how &RRNAME; can be expanded in the future with new schemes and hash algorithms, while sacrificing some of the flexibility that the Parameter was intended to provide.</t>
        <t>Note: old RDATA fields: Serial, Digest Type, Parameter, Digest.</t>
        <t>Note: new RDATA fields: Serial, Scheme, Hash Algorithm, Digest.</t>
        <t>Add new IANA requirement for a Scheme registry.</t>
        <t>Rearranged some sections and separated scheme-specific aspects from general aspects of digest calculation.</t>
        <t>When discussing multiple &RRNAME; RRs, allow for Scheme, as well as Hash Algorithm, transition.</t>
        <t>Added Performance Considerations section with some benchmarks.</t>
        <t>Further clarifications about non-apex &RRNAME; RRs.</t>
        <t>Clarified inclusion rule for duplicate RRs.</t>
        <t>Removed or lowercased some inappropriately used RFC 2119 key words.</t>
        <t>Clarified that all &RRNAME; RRs, even for unsupported hash algorithms, must be zeroized during digest calculation.</t>
        <t>Added Resilience and Fragility to security considerations.</t>
        <t>Updated examples since changes in this version result in different hash values.</t>
      </list></t>
      <t>From -04 to -05:
      <list style="symbols">
        <t>Clarifications about non-apex and multiple &RRNAME; RRs.</t>
        <t>Clarifications about benchmark results.</t>
        <t>Don't compute &RRNAME; on-the-fly.</t>
        <t>Specification Required for updates to &RRNAME; protocol registries.</t>
        <t>Other rewording based on WGLC feedback.</t>
        <t>Updated RFC numbers for some references.</t>
        <t>Use documentation IP addresses instead of loopback.</t>
        <t>Updated examples in the appendix.</t>
      </list></t>
      <t>From -05 to -06:
      <list style="symbols">
        <t>Per WG suggestion, no longer include any apex &RRNAME; record in digest calculation.</t>
        <t>Updated examples in the appendix.</t>
        <t>Clarified verification procedure by describing a loop over all &RRNAME; RRs.</t>
      </list></t>
      <t>From -06 to -07:
      <list style="symbols">
        <t>Added NIC Chile Labs implementation.</t>
      </list></t>
      <t>From -07 to -08:
      <list style="symbols">
        <t>Update an author's affiliation.</t>
        <t>Clarified why placeholder RRs are still important (for NSEC/NSEC3).</t>
        <t>Moved subsection ("Order of RRSets Having the Same Owner Name") with single sentence paragraph up into parent section.</t>
      </list></t>
      <t>From -08 to -09:
      <list style="symbols">
        <t>Moved format, ordering, inclusion/exclusion into a sub section specific to the SIMPLE scheme.</t>
        <t>Further clarified rules about multiple &RRNAME; RRs (AD comments).</t>
        <t>Reworded rules about processing of duplicate zone RRs (AD comments).</t>
        <t>Removed sentence about optional zeroing of digest prior to calculation (AD comments).</t>
        <t>Other minor changes (AD comments).</t>
      </list></t>
      <t>From -09 to -10:
      <list style="symbols">
        <t>Add clarification and reference to on-disk modification / corruption of zone files.</t>
        <t>Added concerns that timing of KSK rollovers could affect validation of &RRNAME; record.</t>
        <t>Addressed SECDIR review and accepted most proposed edits.</t>
        <t>From SECDIR review, require minimum digest length of 12 octets.</t>
        <t>From SECDIR review, add SHA512 has hash algorithm 2.</t>
        <t>From SECDIR review, say that &RRNAME; RRs MAY be ignored by local policy.</t>
        <t>Moved Implementation Status to an appendix with the intention to retain it in RFC.</t>
        <t>In registry tables, changed Status column to Implementation Requirement.</t>
      </list></t>
      <t>From -10 to -11:
      <list style="symbols">
        <t>Fixed people's names in the acknowledgments section (blush)</t>
        <t>Say "has not been modified between origination and retrieval."</t>
        <t>Say that &RRNAME; TTL doesn't matter during verification.</t>
        <t>Further clarification that the SHA-384 and SHA-512 hashes are not truncated.  Future algs might be truncated, but never below 96 bits.</t>
      </list></t>
      <t>From -11 to -12:
      <list style="symbols">
        <t>SECDIR review: make "recommended" all caps.</t>
        <t>SECDIR review: tweak explanation of why &RRNAME; RR has copy of SOA serial.</t>
        <t>SECDIR review: be even more clear about apex &RRNAME; RRs vs non-apex.</t>
        <t>SECDIR review: Forgot to delete sentence about IANA policy for adding new hash algorithms.</t>
        <t>SECDIR review: Spell out Key Signing Key first time.</t>
        <t>SECDIR review: say "private use hash algorithm code points."</t>
        <t>SECDIR review: Update estimates of &RRNAME; RR size.</t>
      </list></t>
      <t>From -12 to -13:
      <list style="symbols">
        <t>Added reference to draft-ietf-dprive-xfr-over-tls.</t>
        <t>Dropped Implementation Requirement from registry tables.</t>
        <t>Added Use of Multiple ZONEMD Hash Algorithms to Security Considerations.</t>
        <t>Added Using Zone Digest Without DNSSEC to Security Considerations.</t>
        <t>Added notes about the need for algorithm agility due to crypto algorithm aging.</t>
        <t>Further clarified that only with DNSSEC can &RRNAME; guarantee integrity and authenticity.</t>
        <t>For unsigned zones, &RRNAME; serves only as a checksum.</t>
        <t>Calculation algorithm is designed for common case of offline signing.  Deviations may be allowed as long as the end result is the same.</t>
        <t>Numerous small edits and clarifications from IESG reviewer comments.</t>
      </list></t>
      <t>From -13 to -14:
      <list style="symbols">
        <t>A few more edits and clarifications from IESG reviewer comments.</t>
        <t>Moved paragraph about multiple digests to new section titled Including &RRNAME; RRs in a Zone.</t>
        <t>MUST be implemented -> MUST be supported by implementations.</t>
        <t>Consolidated SHOULD requirements about error reporting to single place at the conclusion of verification.</t>
        <t>Rephrased "provably insecure" etc as using DNSSEC validation to know whether or not the zone is expected to have keys and signatures.</t>
      </list></t>
    </section>

  </middle>
  <back>

    <references title="Normative References">
    &RFC2119;
    &RFC1034;
    &RFC1035;
    &RFC4034;
    &RFC6234;
    &RFC8174;
    </references>

    <references title="Informative References">
    &RFC1995;
    &RFC2065;
    &RFC2136;
    &RFC2535;
    &RFC2845;
    &RFC2931;
    &RFC3258;
    &RFC4880;
    &RFC5155;
    &RFC5751;
    &RFC5936;
    &RFC7696;
    &RFC8126;
    &RFC8484;
    &RFC8499;
    &RFC8806;
    &RFC8901;
    &I-D.ietf-dprive-xfr-over-tls;

     <reference anchor="InterNIC" target="ftp://ftp.internic.net/domain/">
        <front>
          <title>InterNIC FTP site</title>
          <author>
            <organization>ICANN</organization>
          </author>
          <date year="2018" month="May" day="31"/>
        </front>
     </reference>

     <reference anchor="RootServers" target="https://www.root-servers.org/">
        <front>
          <title>Root Server Technical Operations</title>
          <author>
            <organization>Root Server Operators</organization>
          </author>
          <date year="2018" month="July" day="2"/>
        </front>
     </reference>

     <reference anchor="ldns-zone-digest" target="https://github.com/verisign/ldns-zone-digest">
        <front>
          <title>Implementation of Message Digests for DNS Zones using DNS Zones using the ldns library</title>
<author>
            <organization>Verisign</organization>
<organization>
</organization>
</author>
            <date year="2018" month="July" day="20"/> year="2021" month="January"/>
          </front>
<refcontent>commit 71c0cd1</refcontent>
        </reference>

        <reference anchor="ZoneDigestHackathon" anchor="ZONE-DIGEST-HACKATHON" target="https://github.com/shane-kerr/ZoneDigestHackathon">
          <front>
            <title>Prototype implementation of &RRNAME; ZONEMD for the IETF 102 hackathon in Python</title>
          <author initials="S." surname="Kerr" fullname="Shane Kerr"> hackathon</title>
<author>
<organization>
</organization>
</author>
            <date year="2018" month="July" day="14"/> year="2019" month="August"/>
          </front>
<refcontent>commit 76ad7a7</refcontent>
        </reference>

        <reference anchor="DnsTools" anchor="DNS-TOOLS" target="https://github.com/niclabs/dns-tools">
          <front>
            <title>DNS tools for zone signature (file, pkcs11-hsm)
      and validation, and zone digest (ZONEMD)</title>
<author>
            <organization>NIC Chile Labs</organization>
<organization>
</organization>
</author>
            <date year="2020" month="April"/> month="December"/>
          </front>
<refcontent>commit 489de21</refcontent>
        </reference>

        <reference anchor="CZDS" target="https://czds.icann.org/">
          <front>
            <title>Centralized Zone Data Service</title>
            <author>
              <organization>Internet Corporation for Assigned Names and Numbers</organization> Numbers (ICANN)</organization>
            </author>
            <date year="2018" month="October" day="5"/> month="October"/>
          </front>
        </reference>

        <reference anchor="RPZ" target="https://en.wikipedia.org/w/index.php?title=Response_policy_zone&amp;oldid=960043728">
          <front>
            <title>Response policy zone</title>
            <author>
              <organization>Wikipedia</organization>
            </author>
            <date year="2020" month="May" day="31"/> month="May"/>
          </front>
        </reference>

        <reference anchor="disk-full-failure" anchor="DISK-FULL-FAILURE" target="https://web.archive.org/web/20100618032705/https://www.denic.de/en/denic-in-dialogue/news/2733.html">
          <front>
            <title>Background of the Partial Failure of the Name Service for .de Domains</title>
            <author>
              <organization>DENIC</organization>
            </author>
            <date year="2010" month="May" day="14"/> month="May"/>
          </front>
        </reference>

<reference anchor="ZONE-DIGEST-TESTS" target="https://trac.ietf.org/trac/dnsop/wiki/RFC8976ZONEMDTestCases">
          <front>
            <title>RFC 8976 ZONEMD Test Cases</title>
            <author>
              <organization>IETF</organization>
            </author>
            <date year="2021" month="January"/>
          </front>
</reference>

      </references>
    </references>
    <section title="Example numbered="true" toc="default">
      <name>Example Zones With Digests"> with Digests</name>
      <t>
        This appendix contains example zones with accurate &RRNAME; 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 (<xref target="ZONE-DIGEST-TESTS"/>) maintained by
        the IETF DNSOP Working Group.
      </t>
      <section title="Simple numbered="true" toc="default">
        <name>Simple EXAMPLE Zone"> Zone</name>
        <t>
          Here, the EXAMPLE zone contains an SOA record, NS and glue records, and a &RRNAME; ZONEMD record.
        </t>
        <figure><artwork align="left"><![CDATA[
<sourcecode type="dns-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 (
                                 c68090d90a7aed71
                                 6bc459f9340e3d7c
                                 1370d4d24b7e2fc3
                                 a1ddc0b9a87153b9
                                 a9713b3c9ae5cc27
                                 777f98b8e730044c )
ns1           3600   IN  A       203.0.113.63
ns2           3600   IN  AAAA    2001:db8::63
]]></artwork></figure>
</sourcecode>
      </section>
      <section title="Complex numbered="true" toc="default">
        <name>Complex EXAMPLE Zone"> Zone</name>
        <t>
          Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR, uppercase names, a wildcard, a multi-record RRset, a non-apex ZONEMD RR, and one out-of-zone RR.
        </t>
        <figure><artwork align="left"><![CDATA[
<sourcecode type="dns-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 (
                                  31cefb03814f5062
                                  ad12fa951ba0ef5f
                                  8da6ae354a415767
                                  246f7dc932ceb1e7
                                  42a2108f529db6a3
                                  3a11c01493de358d
                                 a3b69bad980a3504
                                 e1cffcb0fd6397f9
                                 3848071c93151f55
                                 2ae2f6b1711d4bd2
                                 d8b39808226d7b9d
                                 b71e34b72077f8fe )
ns1           3600   IN  A       203.0.113.63
ns2
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 )
]]></artwork></figure>
</sourcecode>
      </section>
      <section title="EXAMPLE numbered="true" toc="default">
        <name>EXAMPLE Zone with multiple digests"> Multiple Digests</name>
        <t>
          Here, the EXAMPLE zone contains multiple &RRNAME; ZONEMD records. It has both
          SHA384 and SHA512 digests using the SIMPLE scheme.  It also includes
          &RRNAME;
          ZONEMD records with Scheme and Hash Algorithm
          values in the private range (240-254).  These additional
          private-range digests are not verifiable.
        </t>
        <figure><artwork align="left"><![CDATA[
<sourcecode type="dns-rr">
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.
NS2.EXAMPLE.  3600   IN  AAAA    2001:db8::63
]]></artwork></figure>
</sourcecode>
      </section>

      <section title="The numbered="true" toc="default">
        <name>The URI.ARPA Zone"> Zone</name>
        <t>
          The following sample zone is the URI.ARPA zone retrieved 2018-10-21. 2021-01-21.  Note this sample zone has (expired) signatures, but
          no signature for
          been re-signed with unpublished keys, so that the &RRNAME; RR. added ZONEMD RR also has a signature.
        </t>
        <figure><artwork align="left"><![CDATA[
; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr
; (2 servers found)
;; global options: +cmd
<sourcecode type="dns-rr">
uri.arpa.       3600    IN      SOA     sns.dns.icann.org. (
   noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
uri.arpa.       3600    IN      RRSIG   NSEC   SOA 8 2 3600 (
    20181028142623 20181007205525 47155
    20210217232440 20210120232440 37444 uri.arpa.
    eEC4w/oXLR1Epwgv4MBiDtSBsXhqrJVvJWUpbX8XpetAvD35bxwNCUTi
    /pAJVUXefegWeiriD2rkTgCBCMmn7YQIm3gdR+HjY/+o3BXNQnz97f+e
    HAE9EDDzoNVfL1PyV/2fde9tDeUuAGVVwmD399NGq9jWYMRpyri2kysr q/g=
    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 (
    20181028172020 20181007175821 47155
    20210217232440 20210120232440 37444 uri.arpa.
    ATyV2A2A8ZoggC+68u4GuP5MOUuR+2rr3eWOkEU55zAHld/7FiBxl4ln
    4byJYy7NudUwlMOEXajqFZE7DVl8PpcvrP3HeeGaVzKqaWj+aus0jbKF
    Bsvs2b1qDZemBfkz/IfAhUTJKnto0vSUicJKfItu0GjyYNJCz2CqEuGD Wxc=
    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 (
    20181028170556 20181007175821 47155
    20210217232440 20210120232440 37444 uri.arpa.
    e7/r3KXDohX1lyVavetFFObp8fB8aXT76HnN9KCQDxSnSghNM83UQV0t
    lTtD8JVeN1mCvcNFZpagwIgB7XhTtm6Beur/m5ES+4uSnVeS6Q66HBZK
    A3mR95IpevuVIZvvJ+GcCAQpBo6KRODYvJ/c/ZG6sfYWkZ7qg/Em5/+3 4UI=
    kQAJQivmv6A5hqYBK8h6Z13ESY69gmosXwKI6WE09I8RFetfrxr24ecdnY
    d0lpnDtgNNSoHkYRSOoB+C4+zuJsoyAAzGo9uoWMWj97/2xeGhf3PTC9me
    Q9Ohi6hul9By7OR76XYmGhdWX8PBi60RUmZ1guslFBfQ8izwPqzuphs= )
uri.arpa.       3600    IN      RRSIG      DNSKEY  256 3 8 2 3600 (
    20181028152832 20181007175821 15796 uri.arpa.
    nzpbnh0OqsgBBP8St28pLvPEQ3wZAUdEBuUwil+rtjjWlYYiqjPxZ286
    XF4Rq1usfV5x71jZz5IqswOaQgia91ylodFpLuXD6FTGs2nXGhNKkg1V
    chHgtwj70mXU72GefVgo8TxrFYzxuEFP5ZTP92t97FVWVVyyFd86sbbR
    6DZj3uA2wEvqBVLECgJLrMQ9Yy7MueJl3UA4h4E6zO2JY9Yp0W9woq0B
    dqkkwYTwzogyYffPmGAJG91RJ2h6cHtFjEZe2MnaY2glqniZ0WT9vXXd
    uFPm0KD9U77Ac+ZtctAF9tsZwSdAoL365E2L1usZbA+K0BnPPqGFJRJk
    5R0A1w==
    AwEAAbMxuFuLeVDuOwIMzYOTD/bTREjLflo7wOi6ieIJhqltEzgjNzmWJf
    9kGwwDmzxU7kbthMEhBNBZNn84zmcyRSCMzuStWveL7xmqqUlE3swL8kLO
    vdZvc75XnmpHrk3ndTyEb6eZM7slh2C63Oh6K8VR5VkiZAkEGg0uZIT3Nj
    sF )
uri.arpa.       3600    IN      RRSIG      DNSKEY  257 3 8 2 3600 (
    20181028152832 20181007175821 55480 uri.arpa.
    lWtQV/5szQjkXmbcD47/+rOW8kJPksRFHlzxxmzt906+DBYyfrH6uq5X
    nHvrUlQO6M12uhqDeL+bDFVgqSpNy+42/OaZvaK3J8EzPZVBHPJykKMV
    63T83aAiJrAyHzOaEdmzLCpalqcEE2ImzlLHSafManRfJL8Yuv+JDZFj
    2WDWfEcUuwkmIZWX11zxp+DxwzyUlRl7x4+ok5iKZWIg5UnBAf6B8T75
    WnXzlhCw3F2pXI0a5LYg71L3Tp/xhjN6Yy9jGlIRf5BjB59X2zra3a2R
    PkI09SSnuEwHyF1mDaV5BmQrLGRnCjvwXA7ho2m+vv4SP5dUdXf+GTeA
    1HeBfw==
    AwEAAdkTaWkZtZuRh7/OobBUFxM+ytTst+bCu0r9w+rEwXD7GbDs0pIMhM
    enrZzoAvmv1fQxw2MGs6Ri6yPKfNULcFOSt9l8i6BVBLI+SKTY6XXeDUQp
    SEmSaxohHeRPMQFzpysfjxINp/L2rGtZ7yPmxY/XRiFPSO0myqwGJa9r06
    Zw9CHM5UDHKWV/E+zxPFq/I7CfPbrrzbUotBX7Z6Vh3Sarllbe8cGUB2UF
    NaTRgwB0TwDBPRD5ER3w2Dzbry9NhbElTr7vVfhaGWeOGuqAUXwlXEg6Cr
    NkmJXJ2F1Rzr9WHUzhp7uWxhAbmJREGfi2dEyPAbUAyCjBqhFaqglknvc= )
uri.arpa.       3600    IN      RRSIG   SOA      DNSKEY  257 3 8 2 3600 (
    20181029114753 20181008222815 47155 uri.arpa.
    qn8yBNoHDjGdT79U2Wu9IIahoS0YPOgYP8lG+qwPcrZ1BwGiHywuoUa2
    Mx6BWZlg+HDyaxj2iOmox+IIqoUHhXUbO7IUkJFlgrOKCgAR2twDHrXu
    9BUQHy9SoV16wYm3kBTEPyxW5FFm8vcdnKAF7sxSY8BbaYNpRIEjDx4A JUc=
    AwEAAenQaBoFmDmvRT+/H5oNbm0Tr5FmNRNDEun0Jpj/ELkzeUrTWhNpQm
    ZeIMC8I0kZ185tEvOnRvn8OvV39B17QIdrvvKGIh2HlgeDRCLolhaojfn2
    QM0DStjF/WWHpxJOmE6CIuvhqYEU37yoJscGAPpPVPzNvnL1HhYTaao1VR
    YWQ/maMrJ+bfHg+YX1N6M/8MnRjIKBif1FWjbCKvsn6dnuGGL9oCWYUFJ3
    DwofXuhgPyZMkzPc88YkJj5EMvbMH4wtelbCwC+ivx732l0w/rXJn0ciQS
    OgoeVvDio8dIJmWQITWQAuP+q/ZHFEFHPlrP3gvQh5mcVS48eLX71Bq7c= )
uri.arpa.       3600    IN      NSEC    ftp.uri.arpa. NS SOA (
    MX      RRSIG NSEC   DNSKEY )
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.         600     IN      MX      10 pechora.icann.org. 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  256 3 8 2 3600 (
    AwEAAcBi7tSart2J599zbYWspMNGN70IBWb4ziqyQYH9MTB/VCz6WyUK
    uXunwiJJbbQ3bcLqTLWEw134B6cTMHrZpjTAb5WAwg4XcWUu8mdcPTiL
    Bl6qVRlRD0WiFCTzuYUfkwsh1Rbr7rvrxSQhF5rh71zSpwV5jjjp65Wx
    SdJjlH0B
    20210217232440 20210120232440 30577 uri.arpa.
    Kx6HwP4UlkGc1UZ7SERXtQjPajOF4iUvkwDj7MEG1xbQFB1KoJiEb/eiW0
    qmSWdIhMDv8myhgauejRLyJxwxz8HDRV4xOeHWnRGfWBk4XGYwkejVzOHz
    oIArVdUVRbr2JKigcTOoyFN+uu52cNB7hRYu7dH5y1hlc6UbOnzRpMtGxc
    gVyKQ+/ARbIqGG3pegdEOvV49wTPWEiyY65P2urqhvnRg5ok/jzwAdMx4X
    Gshiib7Ojq0sRVl2ZIzj4rFgY/qsSO8SEXEhMo2VuSkoJNiofVzYoqpxEe
    GnANkIT7Tx2xJL1BWyJxyc7E8Wr2QSgCcc+rYL6IkHDtJGHy7TaQ== )
uri.arpa.       3600    IN      DNSKEY  257 3 8      ZONEMD  2018100702 1 1 (
    AwEAAbNVv6ulgRdO31MtAehz7j3ALRjwZglWesnzvllQl/+hBRZr9QoY
    cO2I+DkO4Q1NKxox4DUIxj8SxPO3GwDuOFR9q2/CFi2O0mZjafbdYtWc
    3zSdBbi3q0cwCIx7GuG9eqlL+pg7mdk9dgdNZfHwB0LnqTD8ebLPsrO/
    Id7kBaiqYOfMlZnh2fp+2h6OOJZHtY0DK1UlssyB5PKsE0tVzo5s6zo9
    iXKe5u+8WTMaGDY49vG80JPAKE7ezMiH/NZcUMiE0PRZ8D3foq2dYuS5
    ym+vA83Z7v8A+Rwh4UGnjxKB8zmr803V0ASAmHz/gwH5Vb0nH+LObwFt
    l3wpbp+Wpm8=
    0dbc3c4dbfd75777c12ca19c337854b1577799901307c482e9d91d5d15
    cd934d16319d98e30c4201cf25a1d5a0254960 )
uri.arpa.       3600    IN      DNSKEY  257 3      RRSIG   ZONEMD 8 2 3600 (
    AwEAAbwnFTakCvaUKsXji4mgmxZUJi1IygbnGahbkmFEa0L16J+TchKR
    wcgzVfsxUGa2MmeA4hgkAooC3uy+tTmoMsgy8uq/JAj24DjiHzd46LfD
    FK/qMidVqFpYSHeq2Vv5ojkuIsx4oe4KsafGWYNOczKZgH5loGjN2aJG
    mrIm++XCphOskgCsQYl65MIzuXffzJyxlAuts+ecAIiVeqRaqQfr8LRU
    7wIsLxinXirprtQrbor+EtvlHp9qXE6ARTZDzf4jvsNpKvLFZtmxzFf3
    e/UJz5eHjpwDSiZL7xE8aE1o1nGfPtJx9ZnB3bapltaJ5wY+5XOCKgY0
    xmJVvNQlwdE=
    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 3 2 3600 (
    20181028080856 20181007175821 47155
    20210217232440 20210120232440 37444 uri.arpa.
    HClGAqPxzkYkAT7Q/QNtQeB6YrkP6EPOef+9Qo5/2zngwAewXEAQiyF9
    jD1USJiroM11QqBS3v3aIdW/LXORs4Ez3hLcKNO1cKHsOuWAqzmE+BPP
    Arfh8N95jqh/q6vpaB9UtMkQ53tM2fYU1GszOLN0knxbHgDHAh2axMGH lqM=
    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 (
    20181028103644 20181007205525 47155
    20210217232440 20210120232440 37444 uri.arpa.
    WoLi+vZzkxaoLr2IGZnwkRvcDf6KxiWQd1WZP/U+AWnV+7MiqsWPZaf0
    9toRErerGoFOiOASNxZjBGJrRgjmavOM9U+LZSconP9zrNFd4dIu6kp5
    YxlQJ0uHOvx1ZHFCj6lAt1ACUIw04ZhMydTmi27c8MzEOMepvn7iH7r7 k7k=
    EygekDgl+Lyyq4NMSEpPyOrOywYf9Y3FAB4v1DT44J3R5QGidaH8l7ZFjH
    oYFI8sY64iYOCV4sBnX/dh6C1L5NgpY+8l5065Xu3vvjyzbtuJ2k6YYwJr
    rCbvl5DDn53zAhhO2hL9uLgyLraZGi9i7TFGd0sm3zNyUF/EVL0CcxU= )
ftp.uri.arpa.   3600    IN      NSEC    http.uri.arpa. NAPTR (
    NAPTR RRSIG NSEC )
ftp.uri.arpa.     604800  IN      NAPTR   0 0 "" "" (
    "!^ftp://([^:/?#]*).*$!\\1!i" . )
http.uri.arpa.   3600    IN      RRSIG   NSEC 8 3 3600 (
    20181029010647 20181007175821 47155
    20210217232440 20210120232440 37444 uri.arpa.
    U03NntQ73LHWpfLmUK8nMsqkwVsOGW2KdsyuHYAjqQSZvKbtmbv7HBmE
    H1+Ii3Z+wtfdMZBy5aC/6sHdx69BfZJs16xumycMlAy6325DKTQbIMN+
    ift9GrKBC7cgCd2msF/uzSrYxxg4MJQzBPvlkwXnY3b7eJSlIXisBIn7 3b8=
    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 (
    20181029011815 20181007205525 47155
    20210217232440 20210120232440 37444 uri.arpa.
    T7mRrdag+WSmG+n22mtBSQ/0Y3v+rdDnfQV90LN5Fq32N5K2iYFajF7F
    Tp56oOznytfcL4fHrqOE0wRc9NWOCCUec9C7Wa1gJQcllEvgoAM+L6f0
    RsEjWq6+9jvlLKMXQv0xQuMX17338uoD/xiAFQSnDbiQKxwWMqVAimv5 7Zs=
    eTqbWvt1GvTeXozuvm4ebaAfkXFQKrtdu0cEiExto80sHIiCbO0WL8UDa/
    J3cDivtQca7LgUbOb6c17NESsrsVkc6zNPx5RK2tG7ZQYmhYmtqtfg1oU5
    BRdHZ5TyqIXcHlw9Blo2pir1Y9IQgshhD7UOGkbkEmvB1Lrd0aHhAAg= )
http.uri.arpa.  3600    IN      NSEC    mailto.uri.arpa. NAPTR (
    NAPTR RRSIG NSEC )
http.uri.arpa.    604800  IN      NAPTR   0 0 "" "" (
    "!^http://([^:/?#]*).*$!\\1!i" . )
mailto.uri.arpa.  3600    IN      RRSIG   NSEC 8 3 3600 (
    20181028110727 20181007175821 47155
    20210217232440 20210120232440 37444 uri.arpa.
    GvxzVL85rEukwGqtuLxek9ipwjBMfTOFIEyJ7afC8HxVMs6mfFa/nEM/
    IdFvvFg+lcYoJSQYuSAVYFl3xPbgrxVSLK125QutCFMdC/YjuZEnq5cl
    fQciMRD7R3+znZfm8d8u/snLV9w4D+lTBZrJJUBe1Efc8vum5vvV7819 ZoY=
    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 (
    20181028141825 20181007205525 47155
    20210217232440 20210120232440 37444 uri.arpa.
    MaADUgc3fc5v++M0YmqjGk3jBdfIA5RuP62hUSlPsFZO4k37erjIGCfF
    j+g84yc+QgbSde0PQHszl9fE/+SU5ZXiS9YdcbzSZxp2erFpZOTchrpg
    916T4vx6i59scodjb0l6bDyZ+mtIPrc1w6b4hUyOUTsDQoAJYxdfEuMg Vy4=
    Ch2zTG2F1plEvQPyIH4Yd80XXLjXOPvMbiqDjpJBcnCJsV8QF7kr0wTLnU
    T3dB+asQudOjPyzaHGwFlMzmrrAsszN4XAMJ6htDtFJdsgTMP/NkHhYRSm
    Vv6rLeAhd+mVfObY12M//b/GGVTjeUI/gJaLW0fLVZxr1Fp5U5CRjyw= )
mailto.uri.arpa.        3600    IN      NSEC    urn.uri.arpa. NAPTR (
    NAPTR RRSIG NSEC )
mailto.uri.arpa.  604800  IN      NAPTR   0 0 "" "" (
    "!^mailto:(.*)@(.*)$!\\2!i" . )
urn.uri.arpa.        3600    IN      RRSIG   NSEC 8 3 3600 (
    20181028123243 20181007175821 47155
    20210217232440 20210120232440 37444 uri.arpa.
    Hgsw4Deops1O8uWyELGe6hpR/OEqCnTHvahlwiQkHhO5CSEQrbhmFAWe
    UOkmGAdTEYrSz+skLRQuITRMwzyFf4oUkZihGyhZyzHbcxWfuDc/Pd/9
    DSl56gdeBwy1evn5wBTms8yWQVkNtphbJH395gRqZuaJs3LD/qTyJ5Dp LvA=
    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 (
    20181029071816 20181007205525 47155
    20210217232440 20210120232440 37444 uri.arpa.
    ALIZD0vBqAQQt40GQ0Efaj8OCyE9xSRJRdyvyn/H/wZVXFRFKrQYrLAS
    D/K7q6CMTOxTRCu2J8yes63WJiaJEdnh+dscXzZkmOg4n5PsgZbkvUSW
    BiGtxvz5jNncM0xVbkjbtByrvJQAO1cU1mnlDKe1FmVB1uLpVdA9Ib4J hMU=
    CVt2Tgz0e5ZmaSXqRfNys/8OtVCk9nfP0zhezhN8Bo6MDt6yyKZ2kEEWJP
    jkN7PCYHjO8fGjnUn0AHZI2qBNv7PKHcpR42VY03q927q85a65weOO1YE0
    vPYMzACpua9TOtfNnynM2Ws0uN9URxUyvYkXBdqOC81N3sx1dVELcwc= )
urn.uri.arpa.   3600    IN      NSEC    uri.arpa. NAPTR RRSIG ( NSEC )
urn.uri.arpa.     604800  IN      NAPTR   0 0 "" "" (
    "/urn:([^:]+)/\\1/i" . )
uri.arpa.   3600    IN      SOA     sns.dns.icann.org. (
    noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
;; Query time: 66 msec
;; SERVER: 192.0.32.132#53(192.0.32.132)
;; WHEN: Sun Oct 21 20:39:28 UTC 2018
;; XFR size: 34 records (messages 1, bytes 3941)
uri.arpa.      RRSIG   NSEC 8 3 3600    IN      ZONEMD  2018100702 1 1 (
    1291b78ddf7669b1a39d014d87626b709b55774c5d7d58fa
    dc556439889a10eaf6f11d615900a4f996bd46279514e473
    20210217232440 20210120232440 37444 uri.arpa.
    JuKkMiC3/j9iM3V8/izcouXWAVGnSZjkOgEgFPhutMqoylQNRcSkbEZQzF
    K8B/PIVdzZF0Y5xkO6zaKQjOzz6OkSaNPIo1a7Vyyl3wDY/uLCRRAHRJfp
    knuY7O+AUNXvVVIEYJqZggd4kl/Rjh1GTzPYZTRrVi5eQidI1LqCOeg= )
]]></artwork></figure>
  </sourcecode>
</section>
      <section title="The numbered="true" toc="default">
        <name>The ROOT-SERVERS.NET Zone"> Zone</name>
        <t>
          The following sample zone is the ROOT-SERVERS.NET zone retrieved 2018-10-21.
        </t>
        <figure><artwork align="left"><![CDATA[
<sourcecode type="dns-rr">
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 )
]]></artwork></figure>
</sourcecode>
      </section>
    </section>
    <section anchor="Implementation" title="Implementation Status">

      <t>
        RFC Editor: Please retain this section upon publication.
      </t> numbered="true" toc="default">
      <name>Implementation Status</name>

      <t>
        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 RFC7942. RFC 7942.
      </t>
      <t>
        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.
      </t>
      <section title="Authors' Implementation" anchor="authors-implementation"> anchor="authors-implementation" numbered="true" toc="default">
        <name>Authors' Implementation</name>
        <t>
          The authors have an open source open-source implementation in C, using the ldns
          library <xref target="ldns-zone-digest"/>. (<xref target="LDNS-ZONE-DIGEST" format="default"/>).  This
          implementation is able to perform the following functions:
          <list style="symbols">
          <t>Read
        </t>
        <ul spacing="normal">
          <li>Read an input zone and output a zone with the &RRNAME; placeholder.</t>
          <t>Compute ZONEMD placeholder.</li>

          <li>Compute the zone digest over the signed zone and update the &RRNAME; record.</t>
          <t>Re-compute ZONEMD
          record.</li>

          <li>Recompute DNSSEC signature signatures over the &RRNAME; record.</t>
          <t>Verify ZONEMD record.</li>
          <li>Verify the zone digest from an input zone.</t>
          </list> zone.</li>
        </ul>
        <t>
          This implementation does not:
          <list style="symbols">
          <t>Perform
        </t>
        <ul spacing="normal">
          <li>Perform DNSSEC validation of the &RRNAME; ZONEMD record during verification.</t>
          </list>
        </t> verification.</li>
        </ul>
      </section>
      <section title="Shane numbered="true" toc="default">
        <name>Shane Kerr's Implementation">
        <t> Shane Kerr Implementation</name>
        <t><contact fullname="Shane Kerr"/> wrote an implementation of this
        specification during the IETF 102 hackathon
          <xref target="ZoneDigestHackathon"/>. (<xref
        target="ZONE-DIGEST-HACKATHON" format="default"/>).  This implementation
        is in Python and is able to perform the following functions:
          <list style="symbols">
          <t>Read
        </t>
        <ul spacing="normal">
          <li>Read an input zone and output a zone with &RRNAME; record.</t>
          <t>Verify ZONEMD record.</li>
          <li>Verify the zone digest from an input zone.</t>
          <t>Output zone.</li>
          <li>Output the &RRNAME; ZONEMD record in its defined presentation format.</t>
          </list> format.</li>
        </ul>
        <t>
          This implementation does not:
          <list style="symbols">
          <t>Re-compute
        </t>
        <ul spacing="normal">
          <li>Recompute DNSSEC signature signatures over the &RRNAME; record.</t>
          <t>Perform ZONEMD record.</li>
          <li>Perform DNSSEC validation of the &RRNAME; record.</t>
          </list>
        </t> ZONEMD record.</li>
        </ul>
      </section>
      <section title="NIC numbered="true" toc="default">
        <name>NIC Chile Labs Implementation"> Lab's Implementation</name>
        <t>
          NIC Chile Labs wrote an implementation of this specification
          as part of "dns-tools" suite <xref target="DnsTools"/>, (<xref target="DNS-TOOLS" format="default"/>),
          which besides digesting, can also sign and verify zones. This
          implementation is in Go and is able to perform the following
          functions:
          <list style="symbols">
          <t>Compute
        </t>
        <ul spacing="normal">
          <li>Compute zone digest over signed zone and update the &RRNAME; record.</t>
          <t>Verify ZONEMD record.</li>
          <li>Verify the zone digest from an input zone.</t>
          <t>Perform zone.</li>
          <li>Perform DNSSEC validation of the &RRNAME; ZONEMD record during verification.</t>
          <t>Re-compute verification.</li>
          <li>Recompute DNSSEC signature signatures over the &RRNAME; record.</t>
          </list>
        </t> ZONEMD record.</li>
        </ul>
      </section>
    </section>

    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>

        The authors wish to thank <contact fullname="David Blacka"/>, <contact
        fullname="Scott Hollenbeck"/>, and <contact fullname="Rick Wilhelm"/>
        for providing feedback on early drafts of this document.
        Additionally, they thank <contact fullname="Joe Abley"/>, <contact
        fullname="Mark Andrews"/>, <contact fullname="Ralph Dolmans"/>,
        <contact fullname="Donald Eastlake 3rd"/>, <contact fullname="Richard
        Gibson"/>, <contact fullname="Olafur Gudmundsson"/>, <contact
        fullname="Bob Harold"/>, <contact fullname="Paul Hoffman"/>, <contact
        fullname="Evan Hunt"/>, <contact fullname="Shumon Huque"/>, <contact
        fullname="Tatuya Jinmei"/>, <contact fullname="Mike St. Johns"/>,
        <contact fullname="Burt Kaliski"/>, <contact fullname="Shane Kerr"/>,
        <contact fullname="Matt Larson"/>, <contact fullname="Barry Leiba"/>,
        <contact fullname="John Levine"/>, <contact fullname="Ed Lewis"/>,
        <contact fullname="Matt Pounsett"/>, <contact fullname="Mukund
        Sivaraman"/>, <contact fullname="Petr Spacek"/>, <contact
        fullname="Ondrej Sury"/>, <contact fullname="Willem Toorop"/>,
        <contact fullname="Florian Weimer"/>, <contact fullname="Tim
        Wicinski"/>, <contact fullname="Wouter Wijngaards"/>, <contact
        fullname="Paul Wouters"/>, and other members of the DNSOP Working
        Group for their input.
      </t>
    </section>

</back>
</rfc>