rfc8976xml2.original.xml   rfc8976.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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 RF
C5966 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/rf
c/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" ?>
<rfc category="std" docName="draft-ietf-dnsop-dns-zone-digest-14" ipr="trust2009
02">
<!-- 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 ***** --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dnsop-dns-zo
ne-digest-14" number="8976" ipr="trust200902" obsoletes="" updates="" submission
Type="IETF" category="std"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sor
tRefs="true"
version="3">
<front> <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> <title abbrev="DNS Zone Digest">Message Digest for DNS Zones</title>
<seriesInfo name="RFC" value="8976"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Duane Wessels" initials="D." surname="Wessels"> <author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>Verisign</organization> <organization>Verisign</organization>
<address> <address>
<postal> <postal>
<street>12061 Bluemont Way</street> <street>12061 Bluemont Way</street>
<city>Reston</city> <city>Reston</city>
<region>VA</region> <region>VA</region>
<code>20190</code> <code>20190</code>
<country>United States of America
</country>
</postal> </postal>
<phone>+1 703 948-3200</phone> <phone>+1 703 948-3200</phone>
<email>dwessels@verisign.com</email> <email>dwessels@verisign.com</email>
<uri>https://verisign.com</uri> <uri>https://verisign.com</uri>
</address> </address>
</author> </author>
<author fullname="Piet Barber" initials="P." surname="Barber"> <author fullname="Piet Barber" initials="P." surname="Barber">
<organization>Verisign</organization> <organization>Verisign</organization>
<address> <address>
<postal> <postal>
<street>12061 Bluemont Way</street> <street>12061 Bluemont Way</street>
<city>Reston</city> <city>Reston</city>
<region>VA</region> <region>VA</region>
<code>20190</code> <code>20190</code>
<country>United States of America
</country>
</postal> </postal>
<phone>+1 703 948-3200</phone> <phone>+1 703 948-3200</phone>
<email>pbarber@verisign.com</email> <email>pbarber@verisign.com</email>
<uri>https://verisign.com</uri> <uri>https://verisign.com</uri>
</address> </address>
</author> </author>
<author fullname="Matt Weinberg" initials="M." surname="Weinberg"> <author fullname="Matt Weinberg" initials="M." surname="Weinberg">
<organization>Amazon</organization> <organization>Amazon</organization>
<address> <address>
<email>matweinb@amazon.com</email> <email>matweinb@amazon.com</email>
<uri>https://amazon.com</uri> <uri>https://amazon.com</uri>
</address> </address>
</author> </author>
<author fullname="Warren Kumari" initials="W." surname="Kumari"> <author fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States of America
</country>
</postal> </postal>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<author fullname="Wes Hardaker" initials="W." surname="Hardaker"> <author fullname="Wes Hardaker" initials="W." surname="Hardaker">
<organization>USC/ISI</organization> <organization>USC/ISI</organization>
<address> <address>
<postal> <postal>
<street>P.O. Box 382</street> <street>P.O. Box 382</street>
<city>Davis</city> <city>Davis</city>
<region>CA</region> <region>CA</region>
<code>95617</code> <code>95617</code>
<country>United States of America
</country>
</postal> </postal>
<email>ietf@hardakers.net</email> <email>ietf@hardakers.net</email>
</address> </address>
</author> </author>
<date day="15" month="October" year="2020"/> <date month="January" year="2021"/>
<area>General</area> <area>General</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<keyword>DNS</keyword> <keyword>DNS</keyword>
<keyword>DNSSEC</keyword> <keyword>DNSSEC</keyword>
<keyword>Checksum</keyword> <keyword>Checksum</keyword>
<keyword>Hash</keyword> <keyword>Hash</keyword>
<keyword>Zone Transfer</keyword> <keyword>Zone Transfer</keyword>
<abstract> <abstract>
<t> <t>
This document describes a protocol and new DNS Resource Record This document describes a protocol and new DNS Resource Record that
that provides a cryptographic message digest over DNS zone data at rest. provides a cryptographic message digest over DNS zone data at rest.
The &RRNAME; Resource Record conveys the digest data in The ZONEMD Resource Record conveys the digest data in the zone itself.
the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to
When used in combination with DNSSEC, &RRNAME; allows recipients verify the zone contents for data integrity and origin authenticity.
to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published
This provides assurance that received zone data matches data, regardless of how the zone data has been transmitted and
published data, regardless of how the zone data has been received. When used without DNSSEC, ZONEMD functions as a checksum,
transmitted and received. When used without DNSSEC, &RRNAME; guarding only against unintentional changes.
functions as a checksum, guarding only against unintentional changes.
</t> </t>
<t> <t>
&RRNAME; does not replace DNSSEC.
Whereas DNSSEC protects individual RRSets (DNS data with ZONEMD does not replace DNSSEC:
fine granularity), &RRNAME; protects a zone's data DNSSEC protects individual RRsets (DNS data with
fine granularity), whereas ZONEMD protects a zone's data
as a whole, whether consumed by authoritative name as a whole, whether consumed by authoritative name
servers, recursive name servers, or any other applications. servers, recursive name servers, or any other applications.
</t> </t>
<t> <t>
As specified herein, &RRNAME; is impractical As specified herein, ZONEMD is impractical
for large, dynamic zones due to the time and resources for large, dynamic zones due to the time and resources
required for digest calculation. required for digest calculation.
However, The &RRNAME; record is extensible However, the ZONEMD record is extensible
so that new digest schemes may be added in the future to support large, dynamic so that new digest schemes may be added in the future to support large, dynamic
zones. zones.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
In the DNS, a zone is the collection of authoritative resource In the DNS, a zone is the collection of authoritative resource records
records (RRs) sharing a common origin (<xref target="RFC8499"/>). (RRs) sharing a common origin (<xref target="RFC8499"
Zones are often stored as files in the so-called format="default"/>). Zones are often stored as files in the so-called
master file format <xref target="RFC1034"/>. "master file format" (<xref target="RFC1034" format="default"/>). Zones
Zones are generally distributed among name servers using are generally distributed among name servers using the zone transfer
the AXFR (zone transfer <xref target="RFC5936"/>), and IXFR (incremental (AXFR) (<xref target="RFC5936" format="default"/>) and incremental zone
zone transfer <xref target="RFC1995"/>) transfer (IXFR) (<xref target="RFC1995" format="default"/>) protocols.
protocols. They can also be distributed outside of the DNS with any file transfer
They can also be distributed outside of the DNS, with any file transfer
protocol such as FTP, HTTP, and rsync, or even as email attachments. 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 Currently, there is no standard way to compute a hash or message
for digest for a stand-alone zone.
a stand-alone zone.
</t> </t>
<t> <t>
This document specifies an RR type that provides a This document specifies an RR type that provides a cryptographic
cryptographic message digest of the data in a zone. message digest of the data in a zone. It allows a receiver of the
It allows a receiver of the zone to verify the zone's zone to verify the zone's integrity and authenticity when used in
integrity and authenticity when used in combination with DNSSEC. combination with DNSSEC. The digest RR is a part of the zone itself,
The allowing verification of the zone, no matter how it is transmitted.
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. The digest uses the wire format of zone data in a canonical ordering.
Thus, it is independent of presentation format, such as Thus, it is independent of presentation format such as whitespace,
whitespace, capitalization, and comments. capitalization, and comments.
</t> </t>
<t> <t>
This specification is OPTIONAL to implement by both publishers This specification is <bcp14>OPTIONAL</bcp14> to implement by both publi shers
and consumers of zone data. and consumers of zone data.
</t> </t>
<section title="Motivation"> <section numbered="true" toc="default">
<name>Motivation</name>
<t> <t>
The primary motivation for this protocol enhancement is the desire The primary motivation for this protocol enhancement is the desire
to verify the data integrity and origin authenticity of a stand-alone to verify the data integrity and origin authenticity of a
zone, stand-alone zone, regardless of how it is transmitted. A consumer
regardless of how it is transmitted. A consumer of zone data of zone data should be able to verify that it is as published by the
should be able to verify that it is as-published by the
zone operator. zone operator.
</t> </t>
<t> <t>
Note, however, that integrity and authenticity can only be Note, however, that integrity and authenticity can only be
assured when the zone is signed. assured when the zone is signed.
DNSSEC provides three strong security guarantees relevant DNSSEC provides three strong security guarantees relevant
to this protocol: to this protocol:
<list style="numbers">
<t>whether or not to expect DNSSEC records in the zone,</t>
<t>whether or not to expect a &RRNAME; record in a signed zone, and</t
>
<t>whether or not the &RRNAME; record has been altered since it was si
gned.</t>
</list>
</t> </t>
<ol spacing="normal" type="1"><li>whether or not to expect DNSSEC
records in the zone,</li>
<li>whether or not to expect a ZONEMD record in a signed zone, and</li
>
<li>whether or not the ZONEMD record has been altered since it was sig
ned.</li>
</ol>
<t> <t>
A secondary motivation is to provide the equivalent of a A secondary motivation is to provide the equivalent of a checksum,
checksum, allowing a zone recipient to check for unintended allowing a zone recipient to check for unintended changes and
changes and operational errors, such as accidental truncation. operational errors such as accidental truncation.
</t> </t>
</section> </section>
<section title="Alternative Approaches"> <section numbered="true" toc="default">
<name>Alternative Approaches</name>
<t> <t>
One approach to preventing data tampering and corruption is One approach to preventing data tampering and corruption is to
to secure the distribution channel. The DNS has a number secure the distribution channel. The DNS has a number of features
of features that are already used for channel security. that are already used for channel security. Perhaps the most widely
Perhaps the most widely used is DNS transaction signatures used is DNS transaction signatures (TSIGs) (<xref target="RFC8945"
(TSIG <xref target="RFC2845"/>). TSIG uses shared secret keys format="default"/>). A TSIG uses shared secret keys and a message
and a message digest to protect individual query and response digest to protect individual query and response messages. It is
messages. It is generally used to authenticate and validate generally used to authenticate and validate UPDATE (<xref
UPDATE <xref target="RFC2136"/>, AXFR <xref target="RFC5936"/>, target="RFC2136" format="default"/>), AXFR (<xref target="RFC5936"
and IXFR <xref target="RFC1995"/> messages. format="default"/>), and IXFR (<xref target="RFC1995"
format="default"/>) messages.
</t> </t>
<t> <t>
DNS Request and Transaction Signatures (SIG(0) <xref DNS Request and Transaction Signatures (SIG(0)) (<xref
target="RFC2931"/>) is another protocol extension that target="RFC2931" format="default"/>) is another protocol extension
authenticates individual DNS transactions. Whereas SIG records that authenticates individual DNS transactions. Whereas SIG records
normally cover specific RR types, SIG(0) normally cover specific RR types, SIG(0) is used to sign an entire
is used to sign an entire DNS message. Unlike TSIG, SIG(0) DNS message. Unlike TSIG, SIG(0) uses public key cryptography
uses public key cryptography rather than shared secrets. rather than shared secrets.
</t> </t>
<t> <t>
The Transport Layer Security protocol suite also The Transport Layer Security protocol suite also provides channel
provides channel security. security. The DPRIVE Working Group is in the process of specifying
The DPRIVE working group is in the process of specifying DNS Zone Transfer-over-TLS (<xref
DNS Zone Transfer-over-TLS <xref target="I-D.ietf-dprive-xfr-over-tls" target="I-D.ietf-dprive-xfr-over-tls" format="default"/>). One can
/>. also easily imagine the distribution of zones over HTTPS-enabled web
One can also easily imagine servers as well as DNS-over-HTTPS (<xref target="RFC8484"
the distribution of zones over HTTPS-enabled web servers, format="default"/>).
as well as DNS-over-HTTPS <xref target="RFC8484"/>.
</t> </t>
<t> <t>
Unfortunately, the protections provided by these channel Unfortunately, the protections provided by these channel security
security techniques are (in practice) ephemeral and are not retained a techniques are (in practice) ephemeral and are not retained after
fter the the data transfer is complete. They ensure that the client receives
data transfer is complete. They ensure that the client the data from the expected server and that the data sent by the
receives the data from the expected server, and that the server is not modified during transmission. However, they do not
data sent by the server is not modified during transmission. guarantee that the server transmits the data as originally published
However, they do not guarantee that the server transmits the and do not provide any methods to verify data that is read after
data as originally published, and do not provide any methods transmission is complete. For example, a name server loading saved
to verify data that is read after transmission is complete. zone data upon restart cannot guarantee that the on-disk data has
For example, a name server loading saved zone data upon restart not been modified. Such modification could be the result of an
cannot guarantee that the on-disk data has not been modified. accidental corruption of the file or perhaps an incomplete saving of
Such modification could be the result of the file (<xref target="DISK-FULL-FAILURE" format="default"/>). For
an accidental corruption of the file, or perhaps an incompletely these reasons, it is preferable to protect the integrity of the data
saved file <xref target="disk-full-failure"/>. itself.
For these reasons, it is preferable to protect the integrity of the da
ta itself.
</t> </t>
<t> <t>
Why not simply rely on DNSSEC, which provides certain data security gu Why not simply rely on DNSSEC, which provides certain data security
arantees? guarantees? For zones that are signed, a recipient could validate
For zones that are signed, a recipient could all of the signed RRsets. Additionally, denial-of-existence records
validate all of the signed RRSets. Additionally, denial-of-existence prove that RRsets have not been added or removed. However,
records prove that RRSets have not been added or delegations (non-apex NS records) are not signed by DNSSEC and
removed. However, neither are any glue records. ZONEMD protects the integrity of
delegations (non-apex NS records) are not signed by DNSSEC, delegation, glue, and other records that are not otherwise covered
and neither are any glue records. &RRNAME; protects the integrity of by DNSSEC. Furthermore, zones that employ NSEC3 with Opt-Out (<xref
delegation, target="RFC5155" format="default"/>) are susceptible to the removal
glue, and other records that are not otherwise covered by DNSSEC. Furt or addition of names between the signed nodes. Whereas DNSSEC
hermore, zones primarily protects consumers of DNS response messages, this protocol
that employ NSEC3 with opt-out <xref target="RFC5155"/> are susceptibl
e 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. protects consumers of zones.
</t> </t>
<t> <t>
There are existing tools and protocols that provide data There are existing tools and protocols that provide data security,
security, such as OpenPGP <xref target="RFC4880"/> and S/MIME such as OpenPGP (<xref target="RFC4880" format="default"/>) and
<xref target="RFC5751"/>. In fact, the internic.net site S/MIME (<xref target="RFC8551" format="default"/>). In fact, the
publishes PGP signatures alongside the root zone and other internic.net site publishes Pretty Good Privacy (PGP) signatures
files available there. However, this is a detached signature alongside the root zone and other files available there. However,
with no strong association to the corresponding zone file other this is a detached signature with no strong association to the
than its timestamp. Non-detached signatures are, of course, corresponding zone file other than its timestamp.
possible, but these necessarily change the format of the file
being distributed; a zone signed with OpenPGP or Attached signatures are of course possible, but these necessarily change the
S/MIME no longer looks like a DNS zone and could not directly format of the file being distributed; a zone signed with OpenPGP or S/MIME
be loaded into a name server. Once loaded the signature data no longer looks like a DNS zone and could not directly be loaded into a name
is lost, so it cannot be further propagated. server. Once loaded, the signature data is lost, so it cannot be further
propagated.
</t> </t>
<t> <t>
It seems the desire for data security in DNS zones was envisioned It seems the desire for data security in DNS zones was envisioned
as far back as 1997. as far back as 1997.
<xref target="RFC2065"/> is an obsoleted specification <xref target="RFC2065" format="default"/> is an obsoleted specificatio n
of the first generation DNSSEC Security Extensions. It of the first generation DNSSEC Security Extensions. It
describes a zone transfer signature, identified as the AXFR SIG, which describes a zone transfer signature, identified as the AXFR SIG, which
is similar to the technique proposed by this document. is similar to the technique proposed by this document.
That is, it proposes ordering all (signed) RRSets in a zone, That is, it proposes ordering all (signed) RRsets in a zone,
hashing their contents, and then signing the zone hash. hashing their contents, and then signing the zone hash.
The AXFR SIG is described only for use during zone The AXFR SIG is described only for use during zone
transfers. It did not postulate the need to validate transfers. It did not postulate the need to validate
zone data distributed outside of the DNS. Furthermore, zone data distributed outside of the DNS.
its successor, <xref target="RFC2535"/>, omits the AXFR
SIG, while at the same time introducing an IXFR SIG. Furthermore, its successor, <xref target="RFC2535"
format="default"/>, omits the AXFR SIG while at the same time introducing an
IXFR SIG. (Note: RFC 2535 was obsoleted by RFCs 4033, 4034, and 4035.)
</t> </t>
</section> </section>
<section title="Design Overview"> <section numbered="true" toc="default">
<name>Design Overview</name>
<t> <t>
This document specifies a new Resource Record type This document specifies a new Resource Record type
to convey a message digest of the content of a zone. to convey a message digest of the content of a zone.
The digest is calculated at the time of zone publication. The digest is calculated at the time of zone publication.
If the zone is signed with DNSSEC, any If the zone is signed with DNSSEC, any
modifications of the digest can be detected. The procedures for modifications of the digest can be detected. The procedures for
digest calculation and DNSSEC signing are similar. Both require digest calculation and DNSSEC signing are similar. Both require
data to be processed in a well-defined order and format. data to be processed in a well-defined order and format.
It may be possible to perform DNSSEC signing and It may be possible to perform DNSSEC signing and
digest calculation in parallel. digest calculation in parallel.
</t> </t>
<t> <t>
The zone digest is designed to be used on zones that The zone digest is designed to be used on zones that
have infrequent updates. As specified herein, have infrequent updates. As specified herein,
the digest is re-calculated over the entire zone the digest is recalculated over the entire zone
content each time the zone is updated. This specification does not pr ovide content each time the zone is updated. This specification does not pr ovide
an efficient mechanism for updating the digest on incremental updates of zone an efficient mechanism for updating the digest on incremental updates of zone
data. It is, however, extensible so that data. It is, however, extensible so that
future schemes may be defined to support efficient incremental future schemes may be defined to support efficient incremental
digest updates. digest updates.
</t> </t>
<t> <t>
It is expected that verification of a zone digest will be It is expected that verification of a zone digest will be
implemented in name server software. That is, a name server implemented in name server software. That is, a name server
can verify the zone data it was given and refuse to serve a can verify the zone data it was given and refuse to serve a
zone which fails verification. For signed zones, the name zone that fails verification. For signed zones, the name
server needs a trust anchor to perform DNSSEC validation. server needs a trust anchor to perform DNSSEC validation.
For signed non-root zones, the name server may need to send For signed non-root zones, the name server may need to send
queries to validate a chain of trust. Digest verification queries to validate a chain of trust. Digest verification
could also be performed externally. could also be performed externally.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Use Cases"> <name>Use Cases</name>
<section title="Root Zone"> <section numbered="true" toc="default">
<name>Root Zone</name>
<t> <t>
The root zone <xref target="InterNIC"/> The root zone (<xref target="InterNIC" format="default"/>) is one of
is one of the most widely distributed DNS zone on the Internet, the most widely distributed DNS zones on the Internet, served by
served by more than 1000 separate instances <xref target="RootServer more than 1000 separate instances (<xref target="ROOT-SERVERS"
s"/> format="default"/>) at the time of this writing. Additionally,
at the time of this writing. Additionally, many organizations many organizations configure their own name servers to serve the
configure their own name servers to serve the root zone locally. root zone locally. Reasons for doing so include privacy and
Reasons for doing so include privacy and reduced access time. reduced access time. <xref target="RFC8806" format="default"/>
<xref target="RFC8806"/> describes one way describes one way to do this. As the root zone spreads beyond its
to do this. As the root zone spreads beyond its traditional traditional deployment boundaries, the verification of the
deployment boundaries, the verification of the completeness of the zone contents becomes more important.
completeness of the zone contents becomes more
important.
</t> </t>
</section> </section>
<section title="Providers, Secondaries, and Anycast"> <section numbered="true" toc="default">
<name>Providers, Secondaries, and Anycast</name>
<t> <t>
Since its very early days, the developers of the DNS Since its very early days, the developers of the DNS recognized
recognized the importance of secondary name servers and the importance of secondary name servers and service diversity.
service diversity. However, However, modern DNS service has complex provisioning that includes
modern DNS service has complex provisioning which multiple third-party providers (<xref target="RFC8901"
includes multiple third-party providers (<xref target="RFC8901"/>) a format="default"/>) and hundreds of anycast instances (<xref
nd hundreds target="RFC3258" format="default"/>). Instead of a simple
of anycast instances (<xref target="RFC3258"/>). Instead of a simpl primary-to-secondary zone distribution system, today it is
e primary-to-secondary possible to have multiple levels, multiple parties, and multiple
zone distribution system, today it is possible to have protocols involved in the distribution of zone data. This
multiple levels, multiple parties, and multiple protocols complexity introduces new places for problems to arise. The zone
involved in the distribution of zone data. This complexity digest protects the integrity of data that flows through such
introduces new places for problems to arise. The zone digest systems.
protects the integrity of data that flows through such systems.
</t> </t>
</section>
<section title="Response Policy Zones"> </section>
<section numbered="true" toc="default">
<name>Response Policy Zones</name>
<t> <t>
A Response Policy Zone (RPZ) is "a mechanism to introduce a A Response Policy Zone (RPZ) is "a mechanism to introduce a
customized policy in Domain Name System servers, so that customized policy in Domain Name System servers, so that recursive
recursive resolvers return possibly modified results" resolvers return possibly modified results" (<xref target="RPZ"
<xref target="RPZ"/>. format="default"/>). The policy information is carried inside
The policy information is carried inside specially constructed DNS z specially constructed DNS zones. A number of companies provide
ones. RPZ feeds, which are consumed by name server and firewall
A number of companies provide RPZ feeds, which are products. While RPZs can be signed with DNSSEC, the data is
consumed by name server and firewall products. not queried directly and would not be subject to DNSSEC
While RPZ zones can validation.
be signed with DNSSEC, the data is not queried directly,
and would not be subject to DNSSEC validation.
</t> </t>
</section> </section>
<section title="Centralized Zone Data Service"> <section numbered="true" toc="default">
<name>Centralized Zone Data Service</name>
<t> <t>
ICANN operates the Centralized Zone Data Service <xref ICANN operates the Centralized Zone Data Service (<xref
target="CZDS"/>, which is a repository of top-level target="CZDS" format="default"/>), which is a repository of
domain zone files. Users that have been granted access are then abl top-level domain zone files. Users that have been granted access
e to download are then able to download zone data. Adding a zone digest to
zone data. Adding a zone digest to these would provide CZDS users with assurances that the data has
these would provide CZDS users with assurances that the not been modified between origination and retrieval. Note that
data has not been modified between origination and retrieval. ZONEMD could be added to zone data supplied to CZDS without
Note that &RRNAME; could be added to zone data supplied to requiring it to be present in the zone data served by production
CZDS without requiring it to be present in the zone data name servers, since the digest is inherently attached to the
served by production name servers, since the digest is specific copy of the zone.
inherently attached to the specific copy of the zone.
</t> </t>
</section> </section>
<section title="General Purpose Comparison Check"> <section numbered="true" toc="default">
<name>General Purpose Comparison Check</name>
<t> <t>
Since the zone digest calculation does not depend on presentation Since the zone digest calculation does not depend on presentation
format, it could be used to compare multiple copies of format, it could be used to compare multiple copies of
a zone received from different sources, or copies a zone received from different sources, or copies
generated by different processes. In this case, it serves generated by different processes. In this case, it serves
as a checksum and can be useful even for unsigned zones. as a checksum and can be useful even for unsigned zones.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology">
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and onl "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
y when, they appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
capitals, as shown here. to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t> </t>
<t> <t>
The terms Private Use, Reserved, Unassigned, and Specification The terms Private Use, Reserved, Unassigned, and Specification
Required are to be interpreted as defined in <xref Required are to be interpreted as defined in <xref target="RFC8126" fo
target="RFC8126"/>. rmat="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="rrtype" numbered="true" toc="default">
<section title="The &RRNAME; Resource Record" anchor="rrtype"> <name>The ZONEMD Resource Record</name>
<t> <t>
This section describes the &RRNAME; Resource Record, including its field This section describes the ZONEMD Resource Record, including its fields,
s, wire format, and presentation format. wire format, and presentation format.
The Type value for the &RRNAME; RR is 63. The Type value for the ZONEMD RR is 63.
The &RRNAME; RR is class independent. The ZONEMD RR is class independent.
The RDATA of the resource record consists of four fields: Serial, Scheme , Hash Algorithm, and Digest. The RDATA of the resource record consists of four fields: Serial, Scheme , Hash Algorithm, and Digest.
</t> </t>
<section numbered="true" toc="default">
<section title="Non-apex &RRNAME; Records"> <name>Non-apex ZONEMD Records</name>
<t> <t>
This document specifies &RRNAME; RRs located at the This document specifies ZONEMD RRs located at the
zone apex. Non-apex &RRNAME; RRs are not forbidden, but zone apex. Non-apex ZONEMD RRs are not forbidden, but
have no meaning in this specification. have no meaning in this specification.
Non-apex &RRNAME; RRs MUST NOT be used for verification. Non-apex ZONEMD RRs <bcp14>MUST NOT</bcp14> be used for verification.
</t> </t>
<t> <t>
During digest calculation, During digest calculation,
non-apex &RRNAME; RRs are treated as ordinary RRs. non-apex ZONEMD RRs are treated as ordinary RRs.
They are digested as-is and the RR is not replaced They are digested as is, and the RR is not replaced
by a placeholder RR. by a placeholder RR.
</t> </t>
<t> <t>
Unless explicitly stated otherwise, "&RRNAME;" always refers Unless explicitly stated otherwise, "ZONEMD" always refers
to apex records throughout this document. to apex records throughout this document.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="&RRNAME; RDATA Wire Format"> <name>ZONEMD RDATA Wire Format</name>
<t>The &RRNAME; RDATA wire format is encoded as follows:</t> <t>The 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 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 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 | | Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheme |Hash Algorithm | | | Scheme |Hash Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Digest | | Digest |
/ / / /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
<section numbered="true" toc="default">
<section title="The Serial Field"> <name>The Serial Field</name>
<t> <t>
The Serial field is a 32-bit unsigned integer in network byte The Serial field is a 32-bit unsigned integer in network byte
order. It is the serial number from the zone's order. It is the serial number from the zone's SOA record (<xref
SOA record (<xref target="RFC1035"/> section 3.3.13) for target="RFC1035" sectionFormat="comma" section="3.3.13"/>) for
which the zone digest was generated. which the zone digest was generated.
</t> </t>
<t> <t>
It is included here to clearly bind the &RRNAME; RR It is included here to clearly bind the ZONEMD RR to a particular
to a particular version of the zone's content. version of the zone's content. Without the serial number, a
Without the serial number, a stand-alone &RRNAME; digest stand-alone ZONEMD digest has no obvious association to any
has no obvious association to any particular instance of a zone. particular instance of a zone.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="The Scheme Field"> <name>The Scheme Field</name>
<t> <t>
The Scheme field is an 8-bit unsigned integer that identifies The Scheme field is an 8-bit unsigned integer that identifies
the methods by which data is collated and presented the methods by which data is collated and presented
as input to the hashing function. as input to the hashing function.
</t> </t>
<t> <t>
Herein, SIMPLE, with Scheme value 1, is the only Herein, SIMPLE, with Scheme value 1, is the only standardized
standardized Scheme defined for &RRNAME; records and it MUST be supp Scheme defined for ZONEMD records and it <bcp14>MUST</bcp14> be
orted by implementations. The Scheme registry supported by implementations. The "ZONEMD Schemes" registry is furt
is further described in <xref target="iana"/>. her
described in <xref target="iana" format="default"/>.
</t> </t>
<t> <t>
Scheme values 240-254 are allocated for Private Use. Scheme values 240-254 are allocated for Private Use.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="The Hash Algorithm Field"> <name>The Hash Algorithm Field</name>
<t> <t>
The Hash Algorithm field is an 8-bit unsigned integer The Hash Algorithm field is an 8-bit unsigned integer
that identifies the cryptographic hash algorithm that identifies the cryptographic hash algorithm
used to construct the digest. used to construct the digest.
</t> </t>
<t> <t>
Herein, SHA384 <xref target="RFC6234"/>, with Hash Algorithm value 1 Herein, SHA384 (<xref target="RFC6234" format="default"/>), with
, is the only Hash Algorithm value 1, is the only standardized Hash Algorithm
standardized defined for ZONEMD records that <bcp14>MUST</bcp14> be supported
Hash Algorithm defined for &RRNAME; records that MUST be supported b by implementations. When SHA384 is used, the size of the Digest
y implementations. field is 48 octets. The result of the SHA384 digest algorithm
When SHA384 is used, the size of the Digest field is 48 octets. <bcp14>MUST NOT</bcp14> be truncated, and the entire 48-octet
The result of the SHA384 digest algorithm MUST NOT be truncated, and digest is published in the ZONEMD record.
the entire
48 octet digest is published in the &RRNAME; record.
</t> </t>
<t> <t>
SHA512 <xref target="RFC6234"/>, with Hash Algorithm value 2, is als SHA512 (<xref target="RFC6234" format="default"/>), with Hash
o defined for &RRNAME; records, Algorithm value 2, is also defined for ZONEMD records and
and SHOULD be supported by implementations. <bcp14>SHOULD</bcp14> be supported by implementations. When
When SHA512 is used, the size of the Digest field is 64 octets. SHA512 is used, the size of the Digest field is 64 octets. The
The result of the SHA512 digest algorithm MUST NOT be truncated, and result of the SHA512 digest algorithm <bcp14>MUST NOT</bcp14> be
the entire truncated, and the entire 64-octet digest is published in the
64 octet digest is published in the &RRNAME; record. ZONEMD record.
</t> </t>
<t> <t>
Hash Algorithm values 240-254 are allocated for Private Use. Hash Algorithm values 240-254 are allocated for Private Use.
</t> </t>
<t> <t>
The Hash Algorithm registry The "ZONEMD Hash Algorithms" registry
is further described in <xref target="iana"/>. is further described in <xref target="iana" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="The Digest Field"> <name>The Digest Field</name>
<t> <t>
The Digest field is a variable-length sequence of octets The Digest field is a variable-length sequence of octets
containing the output of the hash algorithm. containing the output of the hash algorithm.
The length of the Digest field is determined by deducting The length of the Digest field is determined by deducting
the fixed size of the Serial, Scheme, and Hash Algorithm the fixed size of the Serial, Scheme, and Hash Algorithm
fields from the RDATA size in the &RRNAME; RR header. fields from the RDATA size in the ZONEMD RR header.
</t> </t>
<t> <t>
The Digest field MUST NOT be shorter than 12 octets. The Digest field <bcp14>MUST NOT</bcp14> be shorter than 12
Digests for the SHA384 and SHA512 hash algorithms specified herein a octets. Digests for the SHA384 and SHA512 hash algorithms
re specified herein are never truncated. Digests for future hash
never truncated. Digests for future hash algorithms MAY be truncate algorithms <bcp14>MAY</bcp14> be truncated but <bcp14>MUST
d, NOT</bcp14> be truncated to a length that results in less than 96
but MUST NOT be truncated to a length that results in less than bits (12 octets) of equivalent strength.
96-bits (12 octets) of equivalent strength.
</t> </t>
<t> <t>
<xref target="calculating"/> <xref target="calculating" format="default"/>
describes how to calculate the digest for a zone. describes how to calculate the digest for a zone.
<xref target="verifying"/> describes how to use the digest to <xref target="verifying" format="default"/> describes how to use the digest to
verify the contents of a zone. verify the contents of a zone.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="&RRNAME; Presentation Format"> <name>ZONEMD Presentation Format</name>
<t> <t>
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
</t> </t>
<t>
<ul>
<li>
The Serial field is represented as an unsigned decimal integer. The Serial field is represented as an unsigned decimal integer.
</t> </li>
<t> <li>
The Scheme field is represented as an unsigned decimal integer. The Scheme field is represented as an unsigned decimal integer.
</t> </li>
<t> <li>
The Hash Algorithm field is represented as an unsigned decimal The Hash Algorithm field is represented as an unsigned decimal
integer. integer.
</t> </li>
<t> <li>
The Digest is represented as a sequence of case-insensitive The Digest is represented as a sequence of case-insensitive
hexadecimal digits. Whitespace is allowed within the hexadecimal hexadecimal digits. Whitespace is allowed within the hexadecimal
text. text.
</t> </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="&RRNAME; Example"> <name>ZONEMD Example</name>
<t> <t>
The following example shows a &RRNAME; RR in presentation format: The following example shows a ZONEMD RR in presentation format:
</t> </t>
<figure><artwork>
example.com. 86400 IN &RRNAME; 2018031500 1 1 ( <sourcecode type="dns-rr">
example.com. 86400 IN ZONEMD 2018031500 1 1 (
FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
</artwork></figure> </sourcecode>
</section> </section>
<section numbered="true" toc="default">
<section title="Including &RRNAME; RRs in a Zone"> <name>Including ZONEMD RRs in a Zone</name>
<t> <t>
The zone operator chooses an appropriate hash algorithm and The zone operator chooses an appropriate hash algorithm and
scheme, and includes the calculated zone digest in the apex scheme and includes the calculated zone digest in the apex
&RRNAME; RRset. ZONEMD RRset.
The zone operator MAY choose any of the defined hash algorithms The zone operator <bcp14>MAY</bcp14> choose any of the defined hash al
and schemes, including the private use code points. gorithms
and schemes, including the Private Use code points.
</t> </t>
<t> <t>
The &RRNAME; RRSet MAY contain multiple records to support algorithm The ZONEMD RRset <bcp14>MAY</bcp14> contain multiple records to suppor
agility <xref target="RFC7696"/>. t algorithm
[RFC Editor: change that to BCP 201] agility (<xref target="BCP201" format="default"/>).
When multiple &RRNAME; RRs are present, each MUST specify a unique Sch
eme and Hash Algorithm tuple. When multiple ZONEMD RRs are present, each <bcp14>MUST</bcp14>
It is RECOMMENDED that a zone include only one &RRNAME; RR, unless specify a unique Scheme and Hash Algorithm tuple. It is
the zone operator is in the process of transitioning to a new <bcp14>RECOMMENDED</bcp14> that a zone include only one ZONEMD RR,
unless the zone operator is in the process of transitioning to a new
scheme or hash algorithm. scheme or hash algorithm.
</t> </t>
</section> </section>
</section> </section>
<section anchor="calculating" numbered="true" toc="default">
<section title="Calculating the Digest" anchor="calculating"> <name>Calculating the Digest</name>
<t> <t>
The algorithm described in this section is designed for the The algorithm described in this section is designed for the
common case of offline DNSSEC signing. common case of offline DNSSEC signing.
Slight deviations may be permitted or necessary in other Slight deviations may be permitted or necessary in other
situations, such as with unsigned zones or online DNSSEC signing. situations, such as with unsigned zones or online DNSSEC signing.
Implementations that deviate from the described algorithm are Implementations that deviate from the described algorithm are
advised to ensure that it produces &RRNAME; RRs, signatures, advised to ensure that it produces ZONEMD RRs, signatures,
and dential-of-existence records that are identical to the and denial-of-existence records that are identical to the
ones generated by this procedure. ones generated by this procedure.
</t> </t>
<section anchor="placeholder" numbered="true" toc="default">
<section title="Add &RRNAME; Placeholder" anchor="placeholder"> <name>Add ZONEMD Placeholder</name>
<t> <t>
In preparation for calculating the zone digest(s), any existing &RRNAM E; records In preparation for calculating the zone digest(s), any existing ZONEMD records
(and covering RRSIGs) (and covering RRSIGs)
at the zone apex at the zone apex
are first deleted. are first deleted.
</t> </t>
<t> <t>
Prior to calculation of the digest, and prior to signing with Prior to calculation of the digest, and prior to signing with
DNSSEC, one or more placeholder &RRNAME; records are added to the DNSSEC, one or more placeholder ZONEMD records are added to the
zone apex. This zone apex. This
ensures that ensures that
denial-of-existence (NSEC, NSEC3) records are created correctly denial-of-existence (NSEC, NSEC3) records are created correctly
if the zone is signed with DNSSEC. If placeholders were not added pri or to if the zone is signed with DNSSEC. If placeholders were not added pri or to
signing, the later addition of &RRNAME; records would also require upd ating the signing, the later addition of ZONEMD records would also require updat ing the
Type Bit Maps field of any apex NSEC/NSEC3 RRs, which then invalidates Type Bit Maps field of any apex NSEC/NSEC3 RRs, which then invalidates
the calculated digest value. the calculated digest value.
</t> </t>
<t> <t>
When multiple &RRNAME; RRs are published in the zone, e.g., When multiple ZONEMD RRs are published in the zone, e.g.,
during an algorithm rollover, each MUST specify a unique Scheme during an algorithm rollover, each <bcp14>MUST</bcp14> specify a uniqu
e Scheme
and Hash Algorithm tuple. and Hash Algorithm tuple.
</t> </t>
<t> <t>
It is RECOMMENDED that the TTL of the &RRNAME; record match the TTL of It is <bcp14>RECOMMENDED</bcp14> that the TTL of the ZONEMD record
the SOA. match the TTL of the Start of Authority (SOA). However, the TTL of
However, the TTL of the &RRNAME; record may be safely ignored during v the ZONEMD record may be safely ignored during verification in all
erification cases.
in all cases.
</t> </t>
<t> <t>
In the placeholder record, the Serial field is In the placeholder record, the Serial field is
set to the current SOA Serial. set to the current SOA Serial.
The Scheme field is set to the value for the chosen collation scheme. The Scheme field is set to the value for the chosen collation scheme.
The Hash Algorithm field is set The Hash Algorithm field is set
to the value for the chosen hash algorithm. to the value for the chosen hash algorithm.
Since apex &RRNAME; records are excluded from digest calculation, Since apex ZONEMD records are excluded from digest calculation,
the value of the Digest field does not matter at this point the value of the Digest field does not matter at this point
in the process. in the process.
</t> </t>
</section> </section>
<section title="Optionally Sign the Zone"> <section numbered="true" toc="default">
<name>Optionally, Sign the Zone</name>
<t> <t>
Following addition of placeholder records, the zone may be signed with Following the addition of placeholder records, the zone may be
DNSSEC. signed with DNSSEC. When the digest calculation is complete, and
When the digest calculation is complete, and the &RRNAME; record is up the ZONEMD record is updated, the signature(s) for the ZONEMD RRset
dated, <bcp14>MUST</bcp14> be recalculated and updated as well. Therefore,
the signature(s) for the &RRNAME; RRSet MUST be recalculated and the signer is not required to calculate a signature over the
updated as well. placeholder record at this step in the process, but it is harmless
Therefore, the signer is not required to calculate a signature over th to do so.
e placeholder record at
this step in the process, but it is harmless to do so.
</t> </t>
</section> </section>
<section anchor="collate-iterate" numbered="true" toc="default">
<section title="Scheme-Specific Processing" anchor="collate-iterate"> <name>Scheme-Specific Processing</name>
<t> <t>
Herein, only the SIMPLE collation scheme is defined. Herein, only the SIMPLE collation scheme is defined.
Additional schemes may be defined in future updates to this document. Additional schemes may be defined in future updates to this document.
</t> </t>
<section anchor="scheme-simple" numbered="true" toc="default">
<section title="The SIMPLE Scheme" anchor="scheme-simple"> <name>The SIMPLE Scheme</name>
<t> <t>
For the SIMPLE scheme, the digest is calculated over the zone as 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 a whole. This means that a change to a single RR in the zone
requires iterating over all RRs in the zone to recalculate requires iterating over all RRs in the zone to recalculate
the digest. SIMPLE is a good choice for zones that are small the digest. SIMPLE is a good choice for zones that are small
and/or stable, but probably not good for zones that are and/or stable, but it is probably not good for zones that are
large and/or dynamic. large and/or dynamic.
</t> </t>
<t> <t>
Calculation of a zone digest requires RRs Calculation of a zone digest requires RRs to be processed in a
to be processed in a consistent format and ordering. consistent format and ordering. This specification uses DNSSEC's
This specification uses DNSSEC’s canonical on-the-wire RR canonical on-the-wire RR format (without name compression) and
format (without name compression) and ordering as specified ordering as specified in Sections <xref target="RFC4034"
in Sections 6.1, 6.2, and 6.3 of <xref target="RFC4034"/> with the a section="6.1" sectionFormat="bare"/>, <xref target="RFC4034"
dditional section="6.2" sectionFormat="bare"/>, and <xref target="RFC4034"
provision that section="6.3" sectionFormat="bare"/> of <xref target="RFC4034"
RRSets having format="default"/> with the additional provision that RRsets
the same owner name MUST be numerically ordered, in ascending order, having the same owner name <bcp14>MUST</bcp14> be numerically
by their numeric RR TYPE. ordered, in ascending order, by their numeric RR TYPE.
</t> </t>
<section title="SIMPLE Scheme Inclusion/Exclusion Rules" anchor="simpl <section anchor="simple-inclusion-exclusion" numbered="true" toc="defa
e-inclusion-exclusion"> ult">
<name>SIMPLE Scheme Inclusion/Exclusion Rules</name>
<t> <t>
When iterating over records in the zone, the following inclusion/e When iterating over records in the zone, the following
xclusion rules apply: inclusion/exclusion rules apply:
<list style="symbols">
<t>All records in the zone, including glue records, MUST be includ
ed, unless excluded by a subsequent rule.</t>
<t>Occluded data (<xref target="RFC5936"/> Section 3.5) MUST be in
cluded.</t>
<!-- V1: Duplicate RRs with equal owner, class, type, and RDATA MU
ST NOT be included. -->
<!-- V2: Only one instance of duplicate RRs with equal owner, clas
s, type and RDATA SHALL be included (<xref target="RFC4034"/> Section 6.3). -->
<t>If there are duplicate RRs with equal owner, class, type, and R
DATA, only one instance is included (<xref target="RFC4034"/> Section 6.3), and
the duplicates MUST be omitted.</t>
<t>The placeholder apex &RRNAME; RR(s) MUST NOT be included.</t>
<t>If the zone is signed, DNSSEC RRs MUST be included, except:</t>
<t>The RRSIG covering the apex &RRNAME; RRSet MUST NOT be included
because the RRSIG will be updated after all digests have been ca
lculated.</t>
</list>
</t> </t>
</section> <ul spacing="normal">
<li>All records in the zone, including glue records,
<bcp14>MUST</bcp14> be included unless excluded by a subsequent
rule.</li>
<li>Occluded data (<xref target="RFC5936" sectionFormat="comma"
section="3.5"/>) <bcp14>MUST</bcp14> be included.</li>
<section title="SIMPLE Scheme Digest Calculation"> <li>If there are duplicate RRs with equal owner, class, type,
and RDATA, only one instance is included (<xref target="RFC4034"
sectionFormat="comma" section="6.3"/>) and the duplicates
<bcp14>MUST</bcp14> be omitted.</li>
<li>The placeholder apex ZONEMD RR(s) <bcp14>MUST NOT</bcp14> be i
ncluded.</li>
<li>If the zone is signed, DNSSEC RRs <bcp14>MUST</bcp14> be inclu
ded, except:</li>
<li>The RRSIG covering the apex ZONEMD RRset <bcp14>MUST NOT</bcp1
4> be included
because the RRSIG will be updated after all digests have been ca
lculated.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>SIMPLE Scheme Digest Calculation</name>
<t> <t>
A zone digest using the SIMPLE scheme is calculated by concatenati A zone digest using the SIMPLE scheme is calculated by
ng all RRs in the zone, concatenating all RRs in the zone, in the format and order
in the format and order described in <xref target="scheme-simple"/ described in <xref target="scheme-simple" format="default"/>
> subject to the inclusion/exclusion rules described in <xref
subject to the inclusion/exclusion rules described in <xref target target="simple-inclusion-exclusion" format="default"/>, and then
="simple-inclusion-exclusion"/>, applying the chosen hash algorithm:
and then applying the chosen hash algorithm:
</t> </t>
<figure><artwork>
<sourcecode type="pseudocode">
digest = hash( RR(1) | RR(2) | RR(3) | ... ) digest = hash( RR(1) | RR(2) | RR(3) | ... )
where "|" denotes concatenation. where "|" denotes concatenation.
</artwork></figure> </sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section title="Update &RRNAME; RR"> <section numbered="true" toc="default">
<name>Update ZONEMD RR</name>
<t> <t>
The calculated zone digest The calculated zone digest is inserted into the placeholder ZONEMD
is inserted into the placeholder RR. Repeat for each digest if multiple digests are to be published.
&RRNAME; RR.
Repeat for each digest if multiple
digests are to be published.
</t> </t>
<t> <t>
If the zone is signed with DNSSEC, the RRSIG record(s) covering the &R If the zone is signed with DNSSEC, the RRSIG record(s) covering the ZO
RNAME; NEMD
RRSet MUST then be added or updated. Because the &RRNAME; placeholder RRset <bcp14>MUST</bcp14> then be added or updated. Because the ZONEM
was added prior to signing, D placeholder was added prior to signing,
the zone will already have the appropriate denial-of-existence (NSEC, NSEC3) records. the zone will already have the appropriate denial-of-existence (NSEC, NSEC3) records.
</t> </t>
<t> <t>
Some DNSSEC implementations (especially "online signing") might Some DNSSEC implementations (especially "online signing") might
update the SOA serial number whenever update the SOA serial number whenever
a new signature is made. To preserve the calculated digest, a new signature is made. To preserve the calculated digest,
generation of a &RRNAME; signature MUST NOT also result in generation of a ZONEMD signature <bcp14>MUST NOT</bcp14> also result i
a change to the SOA serial number. The &RRNAME; RR and the n
matching SOA MUST be published at the same time. a change to the SOA serial number. The ZONEMD RR and the
matching SOA <bcp14>MUST</bcp14> be published at the same time.
</t> </t>
</section> </section>
</section> </section>
<section title="Verifying Zone Digest" anchor="verifying"> <section anchor="verifying" numbered="true" toc="default">
<name>Verifying Zone Digest</name>
<t> <t>
The recipient of a zone that has a &RRNAME; RR verifies the zone The recipient of a zone that has a ZONEMD RR verifies the zone by
by calculating the digest as follows. calculating the digest as follows:
If multiple &RRNAME; RRs are present in the zone, e.g.,
during an algorithm rollover, a match using any one of the recipient's
supported Schemes and Hash Algorithms is sufficient to verify the zone
.
The verifier MAY ignore a &RRNAME; RR if its Scheme and Hash Algorithm
violates local policy.
</t> </t>
<t> <aside><t>Note: If multiple ZONEMD RRs are present in the zone, e.g., during an
<list style="numbers"> algorithm rollover, a match using any one of the recipient's supported Schemes
<t anchor="verify-check-dnssec"> and Hash Algorithms is sufficient to verify the zone. The verifier
The verifier MUST first determine <bcp14>MAY</bcp14> ignore a ZONEMD RR if its Scheme and Hash Algorithm
whether or not to expect DNSSEC records in the zone. violates local policy. </t></aside>
By examining locally configured trust <ol spacing="normal" type="1"><li anchor="verify-check-dnssec"> The
anchors, and, if necessary, querying for and validating DS RRs in th verifier <bcp14>MUST</bcp14> first determine whether or not to expect
e DNSSEC records in the zone. By examining locally configured trust
parent zone, the verifier knows whether or not the zone to be verifi anchors and, if necessary, querying for and validating Delegation Signer
ed (DS) RRs in the parent zone, the verifier knows whether or not the zone
should include DNSSEC keys and signatures. to be verified should include DNSSEC keys and signatures. For zones
For zones where signatures are not expected, where signatures are not expected, or if DNSSEC validation is not
or if DNSSEC validation is not performed, performed, digest verification continues at step <xref
digest verification continues at step <xref target="verify-check-dig target="verify-check-digest-count" format="counter"/> below.
est-count" format="counter"/> below. </li>
</t> <li anchor="verify-check-existence">
<t anchor="verify-check-existence"> For zones where signatures are expected, the existence of the apex
For zones where signatures are expected, the existence of ZONEMD record <bcp14>MUST</bcp14> be validated. If the DNSSEC
the apex &RRNAME; record MUST be validated. If the DNSSEC data prov data proves the ZONEMD RRset does not exist, digest verification
es the &RRNAME; cannot occur. If the DNSSEC data proves the ZONEMD does exist,
RRSet does not exist, digest verification but is not found in the zone, digest verification <bcp14>MUST
cannot occur. If the DNSSEC data proves the &RRNAME; does NOT</bcp14> be considered successful.
exist, but is not found in the zone, digest verification </li>
MUST NOT be considered successful. <li anchor="verify-dnssec-validate">
</t> For zones where signatures are expected, the SOA and ZONEMD RRsets
<t anchor="verify-dnssec-validate"> <bcp14>MUST</bcp14> have valid signatures, chaining up to a trust
For zones where signatures are expected, the SOA and anchor. If DNSSEC validation of the SOA or ZONEMD RRsets fails,
&RRNAME; RRSets MUST have valid signatures, chaining digest verification <bcp14>MUST NOT</bcp14> be considered
up to a trust anchor. If DNSSEC validation of the SOA successful.
or &RRNAME; RRSets fails, digest verification MUST NOT </li>
be considered successful. <li anchor="verify-check-digest-count">
</t> When multiple ZONEMD RRs are present, each <bcp14>MUST</bcp14>
<t anchor="verify-check-digest-count"> specify a unique Scheme and Hash Algorithm tuple. If the ZONEMD
When multiple &RRNAME; RRs are present, each MUST specify a unique S RRset contains more than one RR with the same Scheme and Hash
cheme and Hash Algorithm tuple. Algorithm, digest verification for those ZONEMD RRs <bcp14>MUST
If the &RRNAME; RRSet contains more than one RR with the same Scheme NOT</bcp14> be considered successful.
and Hash Algorithm, digest verification </li>
for those &RRNAME; RRs <li>
MUST NOT be considered successful.
</t>
<t> <t>
Loop over all apex &RRNAME; RRs and perform the following steps: Loop over all apex ZONEMD RRs and perform the following steps:
<list style="letters">
<t anchor="verify-check-serials">
The SOA Serial field MUST exactly match the &RRNAME;
Serial field. If the fields do not match, digest
verification MUST NOT be considered successful with this &RRNAME
; RR.
</t>
<t>
The Scheme field MUST be checked. If the
verifier does not support the given scheme, verification MUST NO
T be considered successful with this &RRNAME; RR.
</t>
<t>
The Hash Algorithm field MUST be checked. If the
verifier does not support the given hash algorithm, verification
MUST NOT be considered successful with this &RRNAME; RR.
</t>
<t>
The Digest field size MUST be checked. If the size of the
given Digest field is smaller than 12 octets, or if the size is
not equal to the size expected for the
corresponding Hash Algorithm,
verification MUST NOT be considered successful with this &RRNAME
; RR.
</t>
<t>
The zone digest is computed over the zone data as
described in <xref target="collate-iterate"/>,
using the Scheme and Hash Algorithm for the current &RRNAME; RR.
</t>
<t>
The computed digest is compared to the received digest.
If the two digest values match, verification is considered
successful. Otherwise, verification MUST NOT be
considered successful for this &RRNAME; RR.
</t>
</list>
</t> </t>
</list> <ol spacing="normal" type="a"><li anchor="verify-check-serials"> The
</t> SOA Serial field <bcp14>MUST</bcp14> exactly match the ZONEMD Serial
field. If the fields do not match, digest verification <bcp14>MUST
NOT</bcp14> be considered successful with this ZONEMD RR.
</li>
<li>
The Scheme field <bcp14>MUST</bcp14> be checked. If the
verifier does not support the given scheme, verification
<bcp14>MUST NOT</bcp14> be considered successful with this
ZONEMD RR.
</li>
<li>
The Hash Algorithm field <bcp14>MUST</bcp14> be checked. If
the verifier does not support the given hash algorithm,
verification <bcp14>MUST NOT</bcp14> be considered successful
with this ZONEMD RR.
</li>
<li>
The Digest field size <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 <bcp14>MUST
NOT</bcp14> be considered successful with this ZONEMD RR.
</li>
<li>
The zone digest is computed over the zone data as described in
<xref target="collate-iterate" format="default"/> using the
Scheme and Hash Algorithm for the current ZONEMD RR.
</li>
<li>
The computed digest is compared to the received digest. If
the two digest values match, verification is considered
successful. Otherwise, verification <bcp14>MUST NOT</bcp14>
be considered successful for this ZONEMD RR.
</li>
</ol>
</li>
</ol>
<t> <t>
Each time zone verification is performed, the verifier SHOULD Each time zone verification is performed, the verifier <bcp14>SHOULD</bc p14>
report the status as either successful or unsuccessful. report the status as either successful or unsuccessful.
When unsuccessful, the verifier SHOULD report the reason(s) that When unsuccessful, the verifier <bcp14>SHOULD</bcp14> report the reason( s) that
verification did not succeed. verification did not succeed.
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section title="IANA Considerations" anchor="iana"> <name>IANA Considerations</name>
<section title="&RRNAME; RRtype"> <section numbered="true" toc="default">
<name>ZONEMD RRtype</name>
<t> <t>
This document defines a new DNS RR type, &RRNAME;, whose This document defines a new DNS RR type, ZONEMD, whose
value 63 has been allocated by IANA from the "Resource value 63 has been allocated by IANA from the "Resource
Record (RR) TYPEs" subregistry of the "Domain Name System Record (RR) TYPEs" subregistry of the "Domain Name System
(DNS) Parameters" registry: (DNS) Parameters" registry:
</t> </t>
<t>Type: &RRNAME;</t>
<t>Value: 63</t>
<t>Meaning: Message Digest Over Zone Data</t>
<t>Reference: [this document]</t>
</section>
<section title="&RRNAME; Scheme"> <dl spacing="compact">
<dt>Type:
</dt>
<dd>ZONEMD
</dd>
<dt>Value:
</dt>
<dd>63
</dd>
<dt>Meaning:
</dt>
<dd>Message Digest Over Zone Data
</dd>
<dt>Reference:
</dt>
<dd>[RFC8976]
</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>ZONEMD Scheme</name>
<t> <t>
IANA is requested to create a new IANA has created a new subregistry in the "Domain Name
registry System (DNS) Parameters" registry as follows:
on the "Domain Name System (DNS) Parameters" web page
as follows:
</t> </t>
<t>Registry Name: &RRNAME; Schemes</t>
<t>Registration Procedure: Specification Required</t>
<t>Reference: [this document]</t>
<texttable anchor="scheme-table" title="&RRNAME; 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> <dl spacing="compact">
<c>Reserved</c>
<c></c>
<c></c>
<c>1</c> <dt>Registry Name:
<c>Simple &RRNAME; collation</c> </dt>
<c>SIMPLE</c> <dd>ZONEMD Schemes
<c>[this document]</c> </dd>
<c>2-239</c> <dt>Registration Procedure:
<c>Unassigned</c> </dt>
<c></c> <dd>Specification Required
<c></c> </dd>
<c>240-254</c> <dt>Reference:
<c>Private Use</c> </dt>
<c>N/A</c> <dd>[RFC8976]
<c>[this document]</c> </dd>
<c>255</c> </dl>
<c>Reserved</c>
<c></c>
<c></c>
</texttable> <table anchor="scheme-table" align="center">
<name>ZONEMD Scheme 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>
<section anchor="hash-alg-registry" numbered="true" toc="default">
<section title="&RRNAME; Hash Algorithm" anchor="hash-alg-registry"> <name>ZONEMD Hash Algorithms</name>
<t> <t>
IANA is requested to create a new IANA has created a new subregistry in the "Domain Name
registry System (DNS) Parameters" registry as follows:
on the "Domain Name System (DNS) Parameters" web page
as follows:
</t> </t>
<t>Registry Name: &RRNAME; Hash Algorithms</t>
<t>Registration Procedure: Specification Required</t>
<t>Reference: [this document]</t>
<texttable anchor="digest-type-table" title="&RRNAME; Hash Algorithm Reg
istry">
<ttcol align="left">Value</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Mnemonic</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c> <dl spacing="compact">
<c>Reserved</c>
<c></c>
<c></c>
<c>1</c>
<c>SHA-384</c>
<c>SHA384</c>
<c>[this document]</c>
<c>2</c> <dt>Registry Name:
<c>SHA-512</c> </dt>
<c>SHA512</c> <dd>ZONEMD Hash Algorithms
<c>[this document]</c> </dd>
<c>3-239</c> <dt>Registration Procedure:
<c>Unassigned</c> </dt>
<c></c> <dd>Specification Required
<c></c> </dd>
<c>240-254</c> <dt>Reference:
<c>Private Use</c> </dt>
<c>N/A</c> <dd>[RFC8976]
<c>[his document]</c> </dd>
<c>255</c> </dl>
<c>Reserved</c>
<c></c>
<c></c>
</texttable> <table anchor="digest-type-table" align="center">
<name>ZONEMD Hash 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> </section>
<section anchor="security" numbered="true" toc="default">
<section title="Security Considerations" anchor="security"> <name>Security Considerations</name>
<section title="Using Zone Digest Without DNSSEC"> <section numbered="true" toc="default">
<name>Using Zone Digest without DNSSEC</name>
<t> <t>
Users of &RRNAME; with unsigned zones are advised that Users of ZONEMD with unsigned zones are advised that
it provides no real protection against attacks. it provides no real protection against attacks.
While zone digests can be used in the absence of While zone digests can be used in the absence of
DNSSEC, this only provides protection against accidental DNSSEC, this only provides protection against accidental
zone corruption, such as transmission errors and truncation. When used in this zone corruption such as transmission errors and truncation. When used in this
manner, it effectively serves only as a checksum. manner, it effectively serves only as a checksum.
For zones not signed with DNSSEC, an attacker For zones not signed with DNSSEC, an attacker
can make any zone modifications appear to be valid can make any zone modifications appear to be valid
by recomputing Digest field of a &RRNAME; RR. by recomputing the Digest field of a ZONEMD RR.
</t> </t>
</section> </section>
<section title="Attacks Against the Zone Digest"> <section numbered="true" toc="default">
<name>Attacks against the Zone Digest</name>
<t> <t>
An attacker, whose goal is to modify zone content before it is used An attacker, whose goal is to modify zone content before it is used
by the victim, may consider a number of different approaches. by the victim, may consider a number of different approaches.
</t> </t>
<t> <t>
The attacker might perform a downgrade attack to an unsigned The attacker might perform a downgrade attack to an unsigned
zone. This is why <xref target="verifying"/> talks about zone. This is why <xref target="verifying" format="default"/> talks a bout
determining whether or not to expect DNSSEC determining whether or not to expect DNSSEC
signatures for the zone in step <xref target="verify-check-dnssec" for mat="counter"/>. signatures for the zone in step <xref target="verify-check-dnssec" for mat="counter"/>.
</t> </t>
<t> <t>
The attacker might perform a downgrade attack by removing The attacker might perform a downgrade attack by removing
one or more &RRNAME; records. Such a removal is detectable only with one or more ZONEMD records. Such a removal is detectable only with DN
DNSSEC SSEC
validation and is why <xref target="verifying"/> validation and is why <xref target="verifying" format="default"/>
talks about checking denial-of-existence talks about checking denial-of-existence
proofs in step <xref target="verify-check-existence" format="counter"/ > proofs in step <xref target="verify-check-existence" format="counter"/ >
and signature validation in step <xref target="verify-dnssec-validate" format="counter"/>. and signature validation in step <xref target="verify-dnssec-validate" format="counter"/>.
</t> </t>
<t> <t>
The attacker might alter the Scheme, Hash Algorithm, or Digest fields The attacker might alter the Scheme, Hash Algorithm, or Digest fields
of the &RRNAME; record. Such modifications are detectable of the ZONEMD record. Such modifications are detectable
only with DNSSEC validation. only with DNSSEC validation.
</t> </t>
<t> <t>
As stated in <xref target="RFC7696"/>, cryptographic algorithms As stated in <xref target="BCP201" format="default"/>,
age and become weaker as cryptanalysis techniques and computing cryptographic algorithms age and become weaker as cryptanalysis
resources improve with time. techniques and computing resources improve with time. Implementors
Implementors and publishers of zone digests should anticipate and publishers of zone digests should anticipate the need for
the need for algorithm agility on long timescales. algorithm agility on long timescales.
</t> </t>
</section> </section>
<section title="Use of Multiple &RRNAME; Hash Algorithms"> <section numbered="true" toc="default">
<name>Use of Multiple ZONEMD Hash Algorithms</name>
<t> <t>
When a zone publishes multiple &RRNAME; RRs, the overall security is When a zone publishes multiple ZONEMD RRs, the overall security is
only as good as the weakest hash algorithm in use. For this reason, only as good as the weakest hash algorithm in use. For this reason,
<xref target="rrtype"/> recommends only publishing multiple &RRNAME; R Rs <xref target="rrtype" format="default"/> recommends only publishing mu ltiple ZONEMD RRs
when transitioning to a new scheme or hash algorithm. Once the transi tion when transitioning to a new scheme or hash algorithm. Once the transi tion
is complete, the old scheme or hash algorithm should be removed from is complete, the old scheme or hash algorithm should be removed from
the &RRNAME; RRSet. the ZONEMD RRset.
</t> </t>
</section> </section>
<section title="DNSSEC Timing Considerations"> <section numbered="true" toc="default">
<name>DNSSEC Timing Considerations</name>
<t> <t>
As with all DNSSEC signatures, the ability to perform signature As with all DNSSEC signatures, the ability to perform signature
validation of a &RRNAME; record is limited in time. validation of a ZONEMD record is limited in time.
If the DS record(s) or trust anchors for the zone to be verified If the DS record(s) or trust anchors for the zone to be verified
are no longer available, the recipient cannot validate are no longer available, the recipient cannot validate
the &RRNAME; RRSet. the ZONEMD RRset.
This could happen even if the &RRNAME; signature is still current This could happen even if the ZONEMD signature is still current
(not expired), since the zone's DS record(s) (not expired), since the zone's DS record(s)
may have been withdrawn following a Key Signing Key (KSK) rollover. may have been withdrawn following a Key Signing Key (KSK) rollover.
</t> </t>
<t> <t>
For zones where it may be important to validate a &RRNAME; For zones where it may be important to validate a ZONEMD
RRSet through its entire signature validity period, the zone RRset through its entire signature validity period, the zone
operator should ensure that KSK rollover timing takes this operator should ensure that KSK rollover timing takes this
into consideration. into consideration.
</t> </t>
</section> </section>
<section title="Attacks Utilizing &RRNAME; Queries"> <section numbered="true" toc="default">
<name>Attacks Utilizing ZONEMD Queries</name>
<t> <t>
Nothing in this specification prevents clients from making, Nothing in this specification prevents clients from making,
and servers from responding to, &RRNAME; queries. and servers from responding to, ZONEMD queries.
Servers SHOULD NOT calculate zone digests dynamically (for Servers <bcp14>SHOULD NOT</bcp14> calculate zone digests dynamically (
for
each query) as this can be used as a CPU resource exhaustion each query) as this can be used as a CPU resource exhaustion
attack. attack.
</t> </t>
<t> <t>
&RRNAME; responses could be used in ZONEMD responses could be used in
a distributed denial-of-service amplification attack. a distributed denial-of-service amplification attack.
The &RRNAME; RR is moderately sized, much like the DS RR. The 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 ZONEMD RR contributes approximately 65 to 95
A single &RRNAME; RR contributes approximately 65 to 95 octets to a DNS response for digest
octets to a DNS response, for digest types defined herein. Other RR types, such as DNS Public Key (DNSKEY)
types defined herein. Other RR types, such as DNSKEY, can result in l , can result in larger
arger
amplification effects. amplification effects.
</t> </t>
</section> </section>
<section title="Resilience and Fragility"> <section numbered="true" toc="default">
<name>Resilience and Fragility</name>
<t> <t>
&RRNAME; is used to detect incomplete or corrupted ZONEMD is used to detect incomplete or corrupted zone data prior to
zone data prior to its use, thereby increasing resilience by not using its use, thereby increasing resilience by not using corrupt data,
corrupt data, but also introduces some denial-of-service fragility by making good
but also introduces some denial-of-service fragility data in a zone unavailable if some other data is missing or corrupt.
by making good data in a zone unavailable if some other data is missin Publishers and consumers of zones containing ZONEMD records should
g or corrupt. be aware of these trade-offs. While the intention is to secure the
Publishers and consumers of zones containing &RRNAME; zone data, misconfigurations or implementation bugs are generally
records should be aware of these tradeoffs. indistinguishable from intentional tampering and could lead to
While the intention is to secure the zone data, service failures when verification is performed automatically.
misconfigurations or implementation bugs are generally
indistinguishable from intentional tampering, and could lead
to service failures when verification is performed automatically.
</t> </t>
<t> <t>
Zone publishers may want to deploy &RRNAME; gradually, perhaps Zone publishers may want to deploy ZONEMD gradually perhaps
by utilizing one of the private use hash algorithm code points listed by utilizing one of the Private Use hash algorithm code points listed
in <xref target="hash-alg-registry"/>. Similarly, recipients in <xref target="hash-alg-registry" format="default"/>. Similarly, re
cipients
may want to initially configure verification failures only as may want to initially configure verification failures only as
a warning, and later as an error after gaining experience and a warning, and later as an error after gaining experience and
confidence with the feature. confidence with the feature.
</t> </t>
</section> </section>
</section>
<section title="Performance Considerations" anchor="performance"> </section>
<section anchor="performance" numbered="true" toc="default">
<name>Performance Considerations</name>
<t> <t>
This section is provided to make zone publishers aware of the This section is provided to make zone publishers aware of the
performance requirements and implications of including &RRNAME; performance requirements and implications of including ZONEMD
RRs in a zone. RRs in a zone.
</t> </t>
<section title="SIMPLE SHA384"> <section numbered="true" toc="default">
<name>SIMPLE SHA384</name>
<t> <t>
As mentioned previously, the SIMPLE scheme may be As mentioned previously, the SIMPLE scheme may be
impractical for use in zones that are either large or impractical for use in zones that are either large or
highly dynamic. highly dynamic.
Zone publishers should carefully consider the use of &RRNAME; Zone publishers should carefully consider the use of ZONEMD
in such zones, since it might cause consumers of zone data in such zones since it might cause consumers of zone data
(e.g., secondary name servers) to expend resources on digest (e.g., secondary name servers) to expend resources on digest
calculation. calculation.
For such use cases, it is recommended that &RRNAME; For such use cases, it is recommended that ZONEMD
only be used when digest calculation time is significantly only be used when digest calculation time is significantly
less than propagation times and update intervals. less than propagation times and update intervals.
</t> </t>
<t> <t>
The authors' implementation (<xref The authors' implementation (<xref target="authors-implementation"
target="authors-implementation"/>) includes an option to record format="default"/>) includes an option to record and report CPU
and report CPU usage of its operation. usage of its operation. The software was used to generate digests
The software was used to generate digests for more than 800 for more than 800 Top-Level Domain (TLD) zones available from <xref
TLD zones available from <xref target="CZDS"/>. target="CZDS" format="default"/>. The table below summarizes the
The table below summarizes the results for the SIMPLE scheme and SHA38 results for the SIMPLE scheme and SHA384 hash algorithm grouped by
4 hash algorithm zone size. The Rate column is the mean amount of time per RR to
grouped by zone size. calculate the digest, running on commodity hardware in early 2020.
The Rate column is the mean amount of time per RR to calculate the dig
est,
running on commodity hardware in early 2020.
</t> </t>
<texttable> <table align="center">
<ttcol align="right">Zone Size (RRs)</ttcol> <thead>
<ttcol align="right">Rate (msec/RR)</ttcol> <tr>
<c>10 - 99</c> <c>0.00683</c> <th align="right">Zone Size (RRs)</th>
<c>100 - 999</c> <c>0.00551</c> <th align="right">Rate (msec/RR)</th>
<c>1000 - 9999</c> <c>0.00505</c> </tr>
<c>10000 - 99999</c> <c>0.00602</c> </thead>
<c>100000 - 999999</c> <c>0.00845</c> <tbody>
<c>1000000 - 9999999</c> <c>0.0108</c> <tr>
<c>10000000 - 99999999</c> <c>0.0148</c> <td align="right">10 - 99</td>
</texttable> <td align="right">0.00683</td>
</tr>
<tr>
<td align="right">100 - 999</td>
<td align="right">0.00551</td>
</tr>
<tr>
<td align="right">1000 - 9999</td>
<td align="right">0.00505</td>
</tr>
<tr>
<td align="right">10000 - 99999</td>
<td align="right">0.00602</td>
</tr>
<tr>
<td align="right">100000 - 999999</td>
<td align="right">0.00845</td>
</tr>
<tr>
<td align="right">1000000 - 9999999</td>
<td align="right">0.0108</td>
</tr>
<tr>
<td align="right">10000000 - 99999999</td>
<td align="right">0.0148</td>
</tr>
</tbody>
</table>
<t> <t>
For example, based on the above table, it takes approximately For example, based on the above table, it takes approximately
0.13 seconds to calculate a SIMPLE SHA384 digest for a zone with 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. 22,000 RRs, and about 2.5 seconds for a zone with 300,000 RRs.
</t> </t>
<t> <t>
These benchmarks attempt to emulate a worst-case scenario and These benchmarks attempt to emulate a worst-case scenario and take
take into account the time required to canonicalize the zone into account the time required to canonicalize the zone for
for processing. processing. Each of the 800+ zones were measured three times and
Each of the 800+ zones were measured three times, and then then averaged, with a different random sorting of the input data
averaged, with a different random sorting of the input data
prior to each measurement. prior to each measurement.
</t> </t>
</section> </section>
</section> </section>
<section anchor="privacy" numbered="true" toc="default">
<section title="Privacy Considerations" anchor="privacy"> <name>Privacy Considerations</name>
<t>This specification has no impact on user privacy.</t> <t>This specification has no impact on user privacy.</t>
</section> </section>
<section title="Acknowledgments" anchor="acknowledgments">
<t>
The authors wish to thank David Blacka, Scott Hollenbeck, and Rick Wilhe
lm
for providing feedback on early drafts 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 of the
DNSOP working group 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 w
orked 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 s
pecified 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 n
umber 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 adde
d Scope of Experiment section.</t>
<t>Updated Motivation, Introduction, and Design Overview sections in res
ponse 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 ascen
ding.</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 rec
eived 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 m
atch is sufficient.</t>
<t>Updated implementation notes.</t>
<t>Both implementations produce expected results on examples given in th
is 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 g
eneral aspects of digest calculation.</t>
<t>When discussing multiple &RRNAME; RRs, allow for Scheme, as well as H
ash 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 ha
sh 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 dige
st calculation.</t>
<t>Updated examples in the appendix.</t>
<t>Clarified verification procedure by describing a loop over all &RRNAM
E; 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 specif
ic 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 calculatio
n (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 o
f &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 pol
icy.</t>
<t>Moved Implementation Status to an appendix with the intention to reta
in it in RFC.</t>
<t>In registry tables, changed Status column to Implementation Requireme
nt.</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 tru
ncated. 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 s
erial.</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 Consideratio
ns.</t>
<t>Added Using Zone Digest Without DNSSEC to Security Considerations.</t
>
<t>Added notes about the need for algorithm agility due to crypto algori
thm aging.</t>
<t>Further clarified that only with DNSSEC can &RRNAME; guarantee integr
ity 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 Includin
g &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 plac
e 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> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-dprive-xfr-over-tls" to="DPRIVE-XFR-OVER-TLS"
&RFC2119; />
&RFC1034;
&RFC1035;
&RFC4034;
&RFC6234;
&RFC8174;
</references>
<references title="Informative References"> <references>
&RFC1995; <name>References</name>
&RFC2065; <references>
&RFC2136; <name>Normative References</name>
&RFC2535; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC2845; FC.2119.xml"/>
&RFC2931; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC3258; FC.1034.xml"/>
&RFC4880; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC5155; FC.1035.xml"/>
&RFC5751; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC5936; FC.4034.xml"/>
&RFC7696; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8126; FC.6234.xml"/>
&RFC8484; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8499; FC.8174.xml"/>
&RFC8806; </references>
&RFC8901; <references>
&I-D.ietf-dprive-xfr-over-tls; <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1995.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2065.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2136.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2535.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8945.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2931.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3258.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4880.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5155.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5936.xml"/>
<reference anchor="InterNIC" target="ftp://ftp.internic.net/domain/"> <referencegroup anchor="BCP201" target="https://www.rfc-editor.org/info/bcp201">
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>InterNIC FTP site</title> FC.7696.xml"/>
<author> </referencegroup>
<organization>ICANN</organization>
</author>
<date year="2018" month="May" day="31"/>
</front>
</reference>
<reference anchor="RootServers" target="https://www.root-servers.org/"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8126.xml"/>
<title>Root Server Technical Operations</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author> FC.8484.xml"/>
<organization>Root Server Operators</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.8499.xml"/>
<date year="2018" month="July" day="2"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.8806.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8901.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-dprive-xfr-over-tls.xml"/>
<reference anchor="ldns-zone-digest" target="https://github.com/verisign/ld <reference anchor="InterNIC" target="ftp://ftp.internic.net/domain/">
ns-zone-digest"> <front>
<front> <title>Index of ftp://rs.internic.net/</title>
<title>Implementation of Message Digests for DNS Zones using the ldns <author>
library</title> <organization>InterNIC</organization>
<author> </author>
<organization>Verisign</organization> <date year="2018" month="May"/>
</author> </front>
<date year="2018" month="July" day="20"/> </reference>
</front>
</reference>
<reference anchor="ZoneDigestHackathon" target="https://github.com/shane-ke <reference anchor="ROOT-SERVERS" target="https://www.root-servers.org/">
rr/ZoneDigestHackathon"> <front>
<front> <title>root-servers.org</title>
<title>Prototype implementation of &RRNAME; for the IETF 102 hackathon <author>
in Python</title> <organization>Root Server Operators</organization>
<author initials="S." surname="Kerr" fullname="Shane Kerr"> </author>
</author> <date year="2018" month="July"/>
<date year="2018" month="July" day="14"/> </front>
</front> </reference>
</reference>
<reference anchor="DnsTools" target="https://github.com/niclabs/dns-tools"> <reference anchor="LDNS-ZONE-DIGEST" target="https://github.com/verisign
<front> /ldns-zone-digest">
<title>DNS tools for zone signature (file, pkcs11-hsm) <front>
<title>Implementation of Message Digests for DNS Zones using the ldn
s library</title>
<author>
<organization>
</organization>
</author>
<date year="2021" month="January"/>
</front>
<refcontent>commit 71c0cd1</refcontent>
</reference>
<reference anchor="ZONE-DIGEST-HACKATHON" target="https://github.com/sha
ne-kerr/ZoneDigestHackathon">
<front>
<title>Prototype implementation of ZONEMD for the IETF 102 hackathon
</title>
<author>
<organization>
</organization>
</author>
<date year="2019" month="August"/>
</front>
<refcontent>commit 76ad7a7</refcontent>
</reference>
<reference anchor="DNS-TOOLS" target="https://github.com/niclabs/dns-too
ls">
<front>
<title>DNS tools for zone signature (file, pkcs11-hsm)
and validation, and zone digest (ZONEMD)</title> and validation, and zone digest (ZONEMD)</title>
<author> <author>
<organization>NIC Chile Labs</organization> <organization>
</author> </organization>
<date year="2020" month="April"/> </author>
</front> <date year="2020" month="December"/>
</reference> </front>
<refcontent>commit 489de21</refcontent>
</reference>
<reference anchor="CZDS" target="https://czds.icann.org/"> <reference anchor="CZDS" target="https://czds.icann.org/">
<front> <front>
<title>Centralized Zone Data Service</title> <title>Centralized Zone Data Service</title>
<author> <author>
<organization>Internet Corporation for Assigned Names and Numbers</o <organization>Internet Corporation for Assigned Names and Numbers
rganization> (ICANN)</organization>
</author> </author>
<date year="2018" month="October" day="5"/> <date year="2018" month="October"/>
</front> </front>
</reference> </reference>
<reference anchor="RPZ" target="https://en.wikipedia.org/w/index.php?title= <reference anchor="RPZ" target="https://en.wikipedia.org/w/index.php?tit
Response_policy_zone&amp;oldid=960043728"> le=Response_policy_zone&amp;oldid=960043728">
<front> <front>
<title>Response policy zone</title> <title>Response policy zone</title>
<author> <author>
<organization>Wikipedia</organization> <organization>Wikipedia</organization>
</author> </author>
<date year="2020" month="May" day="31"/> <date year="2020" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="disk-full-failure" target="https://web.archive.org/web/2 <reference anchor="DISK-FULL-FAILURE" target="https://web.archive.org/we
0100618032705/https://www.denic.de/en/denic-in-dialogue/news/2733.html"> b/20100618032705/https://www.denic.de/en/denic-in-dialogue/news/2733.html">
<front> <front>
<title>Background of the Partial Failure of the Name Service for .de D <title>Background of the Partial Failure of the Name Service for .de
omains</title> Domains</title>
<author> <author>
<organization>DENIC</organization> <organization>DENIC</organization>
</author> </author>
<date year="2010" month="May" day="14"/> <date year="2010" month="May"/>
</front> </front>
</reference> </reference>
</references> <reference anchor="ZONE-DIGEST-TESTS" target="https://trac.ietf.org/trac/dnsop/w
iki/RFC8976ZONEMDTestCases">
<front>
<title>RFC 8976 ZONEMD Test Cases</title>
<author>
<organization>IETF</organization>
</author>
<date year="2021" month="January"/>
</front>
</reference>
<section title="Example Zones With Digests"> </references>
</references>
<section numbered="true" toc="default">
<name>Example Zones with Digests</name>
<t> <t>
This appendix contains example zones with accurate &RRNAME; records. Th This appendix contains example zones with accurate ZONEMD records.
ese can be used to These can be used to verify an implementation of the zone digest
verify an implementation of the zone digest protocol. 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> </t>
<section numbered="true" toc="default">
<section title="Simple EXAMPLE Zone"> <name>Simple EXAMPLE Zone</name>
<t> <t>
Here, the EXAMPLE zone contains an SOA record, NS and glue records, an d a &RRNAME; record. Here, the EXAMPLE zone contains an SOA record, NS and glue records, an d a ZONEMD record.
</t> </t>
<figure><artwork align="left"><![CDATA[ <sourcecode type="dns-rr">
example. 86400 IN SOA ns1 admin 2018031900 ( example. 86400 IN SOA ns1 admin 2018031900 (
1800 900 604800 86400 ) 1800 900 604800 86400 )
86400 IN NS ns1 86400 IN NS ns1
86400 IN NS ns2 86400 IN NS ns2
86400 IN ZONEMD 2018031900 1 1 ( 86400 IN ZONEMD 2018031900 1 1 (
c68090d90a7aed71 c68090d90a7aed71
6bc459f9340e3d7c 6bc459f9340e3d7c
1370d4d24b7e2fc3 1370d4d24b7e2fc3
a1ddc0b9a87153b9 a1ddc0b9a87153b9
a9713b3c9ae5cc27 a9713b3c9ae5cc27
777f98b8e730044c ) 777f98b8e730044c )
ns1 3600 IN A 203.0.113.63 ns1 3600 IN A 203.0.113.63
ns2 3600 IN AAAA 2001:db8::63 ns2 3600 IN AAAA 2001:db8::63
]]></artwork></figure> </sourcecode>
</section> </section>
<section numbered="true" toc="default">
<section title="Complex EXAMPLE Zone"> <name>Complex EXAMPLE Zone</name>
<t> <t>
Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR, and one out-of-zone RR. Here, the EXAMPLE zone contains duplicate RRs, an occluded RR, upperca se names, a wildcard, a multi-record RRset, a non-apex ZONEMD RR, and one out-of -zone RR.
</t> </t>
<figure><artwork align="left"><![CDATA[ <sourcecode type="dns-rr">
example. 86400 IN SOA ns1 admin 2018031900 ( example. 86400 IN SOA ns1 admin 2018031900 (
1800 900 604800 86400 ) 1800 900 604800 86400 )
86400 IN NS ns1 86400 IN NS ns1
86400 IN NS ns2 86400 IN NS ns2
86400 IN ZONEMD 2018031900 1 1 ( 86400 IN ZONEMD 2018031900 1 1 (
31cefb03814f5062 a3b69bad980a3504
ad12fa951ba0ef5f e1cffcb0fd6397f9
8da6ae354a415767 3848071c93151f55
246f7dc932ceb1e7 2ae2f6b1711d4bd2
42a2108f529db6a3 d8b39808226d7b9d
3a11c01493de358d ) b71e34b72077f8fe )
ns1 3600 IN A 203.0.113.63 ns1 3600 IN A 203.0.113.63
ns2 3600 IN AAAA 2001:db8::63 NS2 3600 IN AAAA 2001:db8::63
occluded.sub 7200 IN TXT "I'm occluded but must be digested" occluded.sub 7200 IN TXT "I'm occluded but must be digested"
sub 7200 IN NS ns1 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"
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" foo.test. 555 IN TXT "out-of-zone data must be excluded"
non-apex 900 IN ZONEMD 2018031900 1 1 ( UPPERCASE 3600 IN TXT "canonicalize uppercase owner names"
616c6c6f77656420 * 777 IN PTR dont-forget-about-wildcards
6275742069676e6f mail 3600 IN MX 20 MAIL1
7265642e20616c6c mail 3600 IN MX 10 Mail2.Example.
6f77656420627574 sortme 3600 IN AAAA 2001:db8::5:61
2069676e6f726564 sortme 3600 IN AAAA 2001:db8::3:62
2e20616c6c6f7765 ) sortme 3600 IN AAAA 2001:db8::4:63
]]></artwork></figure> 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 )
</sourcecode>
</section> </section>
<section numbered="true" toc="default">
<section title="EXAMPLE Zone with multiple digests"> <name>EXAMPLE Zone with Multiple Digests</name>
<t> <t>
Here, the EXAMPLE zone contains multiple &RRNAME; records. It has both Here, the EXAMPLE zone contains multiple ZONEMD records. It has both
SHA384 and SHA512 digests using the SIMPLE scheme. It also includes SHA384 and SHA512 digests using the SIMPLE scheme. It also includes
&RRNAME; records with Scheme and Hash Algorithm ZONEMD records with Scheme and Hash Algorithm
values in the private range (240-254). These additional values in the private range (240-254). These additional
private-range digests are not verifiable. private-range digests are not verifiable.
</t> </t>
<figure><artwork align="left"><![CDATA[ <sourcecode type="dns-rr">
example. 86400 IN SOA ns1 admin 2018031900 ( example. 86400 IN SOA ns1 admin 2018031900 (
1800 900 604800 86400 ) 1800 900 604800 86400 )
example. 86400 IN NS ns1.example. example. 86400 IN NS ns1.example.
example. 86400 IN NS ns2.example. example. 86400 IN NS ns2.example.
example. 86400 IN ZONEMD 2018031900 1 1 ( example. 86400 IN ZONEMD 2018031900 1 1 (
62e6cf51b02e54b9 62e6cf51b02e54b9
b5f967d547ce4313 b5f967d547ce4313
6792901f9f88e637 6792901f9f88e637
493daaf401c92c27 493daaf401c92c27
9dd10f0edb1c56f8 9dd10f0edb1c56f8
080211f8480ee306 ) 080211f8480ee306 )
example. 86400 IN ZONEMD 2018031900 1 2 ( example. 86400 IN ZONEMD 2018031900 1 2 (
08cfa1115c7b948c 08cfa1115c7b948c
4163a901270395ea 4163a901270395ea
226a930cd2cbcf2f 226a930cd2cbcf2f
a9a5e6eb85f37c8a a9a5e6eb85f37c8a
4e114d884e66f176 4e114d884e66f176
eab121cb02db7d65 eab121cb02db7d65
2e0cc4827e7a3204 2e0cc4827e7a3204
f166b47e5613fd27 ) f166b47e5613fd27 )
example. 86400 IN ZONEMD 2018031900 1 240 ( example. 86400 IN ZONEMD 2018031900 1 240 (
e2d523f654b9422a e2d523f654b9422a
96c5a8f44607bbee ) 96c5a8f44607bbee )
example. 86400 IN ZONEMD 2018031900 241 1 ( example. 86400 IN ZONEMD 2018031900 241 1 (
e1846540e33a9e41 e1846540e33a9e41
89792d18d5d131f6 89792d18d5d131f6
05fc283e ) 05fc283e )
ns1.example. 3600 IN A 203.0.113.63 ns1.example. 3600 IN A 203.0.113.63
ns2.example. 86400 IN TXT "This example has multiple digests" ns2.example. 86400 IN TXT "This example has multiple digests"
ns2.example. 3600 IN AAAA 2001:db8::63 NS2.EXAMPLE. 3600 IN AAAA 2001:db8::63
]]></artwork></figure> </sourcecode>
</section> </section>
<section title="The URI.ARPA Zone"> <section numbered="true" toc="default">
<name>The URI.ARPA Zone</name>
<t> <t>
The URI.ARPA zone retrieved 2018-10-21. The following sample zone is the URI.ARPA zone retrieved 2021-01-21.
Note this sample zone has (expired) signatures, but Note this sample zone has
no signature for the &RRNAME; RR. been re-signed with unpublished keys, so that the added ZONEMD RR also
has a signature.
</t> </t>
<figure><artwork align="left"><![CDATA[ <sourcecode type="dns-rr">
; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr uri.arpa. 3600 IN SOA sns.dns.icann.org. (
; (2 servers found) noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
;; global options: +cmd uri.arpa. 3600 IN RRSIG SOA 8 2 3600 (
uri.arpa. 3600 IN SOA sns.dns.icann.org. ( 20210217232440 20210120232440 37444 uri.arpa.
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) GzQw+QzwLDJr13REPGVmpEChjD1D2XlX0ie1DnWHpgaEw1E/dhs3lCN3+B
uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 ( mHd4Kx3tffTRgiyq65HxR6feQ5v7VmAifjyXUYB1DZur1eP5q0Ms2ygCB3
20181028142623 20181007205525 47155 uri.arpa. byoeMgCNsFS1oKZ2LdzNBRpy3oace8xQn1SpmHGfyrsgg+WbHKCT1dY= )
eEC4w/oXLR1Epwgv4MBiDtSBsXhqrJVvJWUpbX8XpetAvD35bxwNCUTi uri.arpa. 86400 IN NS a.iana-servers.net.
/pAJVUXefegWeiriD2rkTgCBCMmn7YQIm3gdR+HjY/+o3BXNQnz97f+e uri.arpa. 86400 IN NS b.iana-servers.net.
HAE9EDDzoNVfL1PyV/2fde9tDeUuAGVVwmD399NGq9jWYMRpyri2kysr q/g= ) uri.arpa. 86400 IN NS c.iana-servers.net.
uri.arpa. 86400 IN RRSIG NS 8 2 86400 ( uri.arpa. 86400 IN NS ns2.lacnic.net.
20181028172020 20181007175821 47155 uri.arpa. uri.arpa. 86400 IN NS sec3.apnic.net.
ATyV2A2A8ZoggC+68u4GuP5MOUuR+2rr3eWOkEU55zAHld/7FiBxl4ln uri.arpa. 86400 IN RRSIG NS 8 2 86400 (
4byJYy7NudUwlMOEXajqFZE7DVl8PpcvrP3HeeGaVzKqaWj+aus0jbKF 20210217232440 20210120232440 37444 uri.arpa.
Bsvs2b1qDZemBfkz/IfAhUTJKnto0vSUicJKfItu0GjyYNJCz2CqEuGD Wxc= ) M+Iei2lcewWGaMtkPlrhM9FpUAHXFkCHTVpeyrjxjEONeNgKtHZor5e4V4
uri.arpa. 600 IN RRSIG MX 8 2 600 ( qJBOzNqo8go/qJpWlFBm+T5Hn3asaBZVstFIYky38/C8UeRLPKq1hTTHAR
20181028170556 20181007175821 47155 uri.arpa. YUlFrexr5fMtSUAVOgOQPSBfH3xBq/BgSccTdRb9clD+HE7djpqrLS4= )
e7/r3KXDohX1lyVavetFFObp8fB8aXT76HnN9KCQDxSnSghNM83UQV0t uri.arpa. 600 IN MX 10 pechora.icann.org.
lTtD8JVeN1mCvcNFZpagwIgB7XhTtm6Beur/m5ES+4uSnVeS6Q66HBZK uri.arpa. 600 IN RRSIG MX 8 2 600 (
A3mR95IpevuVIZvvJ+GcCAQpBo6KRODYvJ/c/ZG6sfYWkZ7qg/Em5/+3 4UI= ) 20210217232440 20210120232440 37444 uri.arpa.
uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 ( kQAJQivmv6A5hqYBK8h6Z13ESY69gmosXwKI6WE09I8RFetfrxr24ecdnY
20181028152832 20181007175821 15796 uri.arpa. d0lpnDtgNNSoHkYRSOoB+C4+zuJsoyAAzGo9uoWMWj97/2xeGhf3PTC9me
nzpbnh0OqsgBBP8St28pLvPEQ3wZAUdEBuUwil+rtjjWlYYiqjPxZ286 Q9Ohi6hul9By7OR76XYmGhdWX8PBi60RUmZ1guslFBfQ8izwPqzuphs= )
XF4Rq1usfV5x71jZz5IqswOaQgia91ylodFpLuXD6FTGs2nXGhNKkg1V uri.arpa. 3600 IN DNSKEY 256 3 8 (
chHgtwj70mXU72GefVgo8TxrFYzxuEFP5ZTP92t97FVWVVyyFd86sbbR AwEAAbMxuFuLeVDuOwIMzYOTD/bTREjLflo7wOi6ieIJhqltEzgjNzmWJf
6DZj3uA2wEvqBVLECgJLrMQ9Yy7MueJl3UA4h4E6zO2JY9Yp0W9woq0B 9kGwwDmzxU7kbthMEhBNBZNn84zmcyRSCMzuStWveL7xmqqUlE3swL8kLO
dqkkwYTwzogyYffPmGAJG91RJ2h6cHtFjEZe2MnaY2glqniZ0WT9vXXd vdZvc75XnmpHrk3ndTyEb6eZM7slh2C63Oh6K8VR5VkiZAkEGg0uZIT3Nj
uFPm0KD9U77Ac+ZtctAF9tsZwSdAoL365E2L1usZbA+K0BnPPqGFJRJk sF )
5R0A1w== ) uri.arpa. 3600 IN DNSKEY 257 3 8 (
uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 ( AwEAAdkTaWkZtZuRh7/OobBUFxM+ytTst+bCu0r9w+rEwXD7GbDs0pIMhM
20181028152832 20181007175821 55480 uri.arpa. enrZzoAvmv1fQxw2MGs6Ri6yPKfNULcFOSt9l8i6BVBLI+SKTY6XXeDUQp
lWtQV/5szQjkXmbcD47/+rOW8kJPksRFHlzxxmzt906+DBYyfrH6uq5X SEmSaxohHeRPMQFzpysfjxINp/L2rGtZ7yPmxY/XRiFPSO0myqwGJa9r06
nHvrUlQO6M12uhqDeL+bDFVgqSpNy+42/OaZvaK3J8EzPZVBHPJykKMV Zw9CHM5UDHKWV/E+zxPFq/I7CfPbrrzbUotBX7Z6Vh3Sarllbe8cGUB2UF
63T83aAiJrAyHzOaEdmzLCpalqcEE2ImzlLHSafManRfJL8Yuv+JDZFj NaTRgwB0TwDBPRD5ER3w2Dzbry9NhbElTr7vVfhaGWeOGuqAUXwlXEg6Cr
2WDWfEcUuwkmIZWX11zxp+DxwzyUlRl7x4+ok5iKZWIg5UnBAf6B8T75 NkmJXJ2F1Rzr9WHUzhp7uWxhAbmJREGfi2dEyPAbUAyCjBqhFaqglknvc= )
WnXzlhCw3F2pXI0a5LYg71L3Tp/xhjN6Yy9jGlIRf5BjB59X2zra3a2R uri.arpa. 3600 IN DNSKEY 257 3 8 (
PkI09SSnuEwHyF1mDaV5BmQrLGRnCjvwXA7ho2m+vv4SP5dUdXf+GTeA AwEAAenQaBoFmDmvRT+/H5oNbm0Tr5FmNRNDEun0Jpj/ELkzeUrTWhNpQm
1HeBfw== ) ZeIMC8I0kZ185tEvOnRvn8OvV39B17QIdrvvKGIh2HlgeDRCLolhaojfn2
uri.arpa. 3600 IN RRSIG SOA 8 2 3600 ( QM0DStjF/WWHpxJOmE6CIuvhqYEU37yoJscGAPpPVPzNvnL1HhYTaao1VR
20181029114753 20181008222815 47155 uri.arpa. YWQ/maMrJ+bfHg+YX1N6M/8MnRjIKBif1FWjbCKvsn6dnuGGL9oCWYUFJ3
qn8yBNoHDjGdT79U2Wu9IIahoS0YPOgYP8lG+qwPcrZ1BwGiHywuoUa2 DwofXuhgPyZMkzPc88YkJj5EMvbMH4wtelbCwC+ivx732l0w/rXJn0ciQS
Mx6BWZlg+HDyaxj2iOmox+IIqoUHhXUbO7IUkJFlgrOKCgAR2twDHrXu OgoeVvDio8dIJmWQITWQAuP+q/ZHFEFHPlrP3gvQh5mcVS48eLX71Bq7c= )
9BUQHy9SoV16wYm3kBTEPyxW5FFm8vcdnKAF7sxSY8BbaYNpRIEjDx4A JUc= ) uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 (
uri.arpa. 3600 IN NSEC ftp.uri.arpa. NS SOA ( 20210217232440 20210120232440 12670 uri.arpa.
MX RRSIG NSEC DNSKEY ) DBE2gkKAoxJCfz47KKxzoImN/0AKArhIVHE7TyTwy0DdRPo44V5R+vL6th
uri.arpa. 86400 IN NS a.iana-servers.net. UxlQ1CJi2Rw0jwAXymx5Y3Q873pOEllH+4bJoIT4dmoBmPXfYWW7Clvw9U
uri.arpa. 86400 IN NS b.iana-servers.net. PKHRP0igKHmCVwIeBYDTU3gfLcMTbR4nEWPDN0GxlL1Mf7ITaC2Ioabo79
uri.arpa. 86400 IN NS c.iana-servers.net. Ip3M/MR8I3Vx/xZ4ZKKPHtLn3xUuJluPNanqJrED2gTslL2xWZ1tqjsAjJ
uri.arpa. 86400 IN NS ns2.lacnic.net. v7JnJo2HJ8XVRB5zBto0IaJ2oBlqcjdcQ/0VlyoM8uOy1pDwHQ2BJl7322
uri.arpa. 86400 IN NS sec3.apnic.net. gNMHBP9HSiUPIOaIDNUCwW8eUcW6DIUk+s9u3GN1uTqwWzsYB/rA== )
uri.arpa. 600 IN MX 10 pechora.icann.org. uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 (
uri.arpa. 3600 IN DNSKEY 256 3 8 ( 20210217232440 20210120232440 30577 uri.arpa.
AwEAAcBi7tSart2J599zbYWspMNGN70IBWb4ziqyQYH9MTB/VCz6WyUK Kx6HwP4UlkGc1UZ7SERXtQjPajOF4iUvkwDj7MEG1xbQFB1KoJiEb/eiW0
uXunwiJJbbQ3bcLqTLWEw134B6cTMHrZpjTAb5WAwg4XcWUu8mdcPTiL qmSWdIhMDv8myhgauejRLyJxwxz8HDRV4xOeHWnRGfWBk4XGYwkejVzOHz
Bl6qVRlRD0WiFCTzuYUfkwsh1Rbr7rvrxSQhF5rh71zSpwV5jjjp65Wx oIArVdUVRbr2JKigcTOoyFN+uu52cNB7hRYu7dH5y1hlc6UbOnzRpMtGxc
SdJjlH0B ) gVyKQ+/ARbIqGG3pegdEOvV49wTPWEiyY65P2urqhvnRg5ok/jzwAdMx4X
uri.arpa. 3600 IN DNSKEY 257 3 8 ( Gshiib7Ojq0sRVl2ZIzj4rFgY/qsSO8SEXEhMo2VuSkoJNiofVzYoqpxEe
AwEAAbNVv6ulgRdO31MtAehz7j3ALRjwZglWesnzvllQl/+hBRZr9QoY GnANkIT7Tx2xJL1BWyJxyc7E8Wr2QSgCcc+rYL6IkHDtJGHy7TaQ== )
cO2I+DkO4Q1NKxox4DUIxj8SxPO3GwDuOFR9q2/CFi2O0mZjafbdYtWc uri.arpa. 3600 IN ZONEMD 2018100702 1 1 (
3zSdBbi3q0cwCIx7GuG9eqlL+pg7mdk9dgdNZfHwB0LnqTD8ebLPsrO/ 0dbc3c4dbfd75777c12ca19c337854b1577799901307c482e9d91d5d15
Id7kBaiqYOfMlZnh2fp+2h6OOJZHtY0DK1UlssyB5PKsE0tVzo5s6zo9 cd934d16319d98e30c4201cf25a1d5a0254960 )
iXKe5u+8WTMaGDY49vG80JPAKE7ezMiH/NZcUMiE0PRZ8D3foq2dYuS5 uri.arpa. 3600 IN RRSIG ZONEMD 8 2 3600 (
ym+vA83Z7v8A+Rwh4UGnjxKB8zmr803V0ASAmHz/gwH5Vb0nH+LObwFt 20210217232440 20210120232440 37444 uri.arpa.
l3wpbp+Wpm8= ) QDo4XZcL3HMyn8aAHyCUsu/Tqj4Gkth8xY1EqByOb8XOTwVtA4ZNQORE1s
uri.arpa. 3600 IN DNSKEY 257 3 8 ( iqNqjtJUbeJPtJSbLNqCL7rCq0CzNNnBscv6IIf4gnqJZjlGtHO30ohXtK
AwEAAbwnFTakCvaUKsXji4mgmxZUJi1IygbnGahbkmFEa0L16J+TchKR vEc4z7SU3IASsi6bB3nLmEAyERdYSeU6UBfx8vatQDIRhkgEnnWUTh4= )
wcgzVfsxUGa2MmeA4hgkAooC3uy+tTmoMsgy8uq/JAj24DjiHzd46LfD uri.arpa. 3600 IN NSEC ftp.uri.arpa. (
FK/qMidVqFpYSHeq2Vv5ojkuIsx4oe4KsafGWYNOczKZgH5loGjN2aJG NS SOA MX RRSIG NSEC DNSKEY ZONEMD )
mrIm++XCphOskgCsQYl65MIzuXffzJyxlAuts+ecAIiVeqRaqQfr8LRU uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 (
7wIsLxinXirprtQrbor+EtvlHp9qXE6ARTZDzf4jvsNpKvLFZtmxzFf3 20210217232440 20210120232440 37444 uri.arpa.
e/UJz5eHjpwDSiZL7xE8aE1o1nGfPtJx9ZnB3bapltaJ5wY+5XOCKgY0 dU/rXLM/naWd1+1PiWiYVaNJyCkiuyZJSccr91pJI673T8r3685B4ODMYF
xmJVvNQlwdE= ) afZRboVgwnl3ZrXddY6xOhZL3n9V9nxXZwjLJ2HJUojFoKcXTlpnUyYUYv
ftp.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( VQ2kj4GHAo6fcGCEp5QFJ2KbCpeJoS+PhKGRRx28icCiNT4/uXQvO2E= )
20181028080856 20181007175821 47155 uri.arpa. ftp.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
HClGAqPxzkYkAT7Q/QNtQeB6YrkP6EPOef+9Qo5/2zngwAewXEAQiyF9
jD1USJiroM11QqBS3v3aIdW/LXORs4Ez3hLcKNO1cKHsOuWAqzmE+BPP
Arfh8N95jqh/q6vpaB9UtMkQ53tM2fYU1GszOLN0knxbHgDHAh2axMGH lqM= )
ftp.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
20181028103644 20181007205525 47155 uri.arpa.
WoLi+vZzkxaoLr2IGZnwkRvcDf6KxiWQd1WZP/U+AWnV+7MiqsWPZaf0
9toRErerGoFOiOASNxZjBGJrRgjmavOM9U+LZSconP9zrNFd4dIu6kp5
YxlQJ0uHOvx1ZHFCj6lAt1ACUIw04ZhMydTmi27c8MzEOMepvn7iH7r7 k7k= )
ftp.uri.arpa. 3600 IN NSEC http.uri.arpa. NAPTR (
RRSIG NSEC )
ftp.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
"!^ftp://([^:/?#]*).*$!\\1!i" . ) "!^ftp://([^:/?#]*).*$!\\1!i" . )
http.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( ftp.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
20181029010647 20181007175821 47155 uri.arpa. 20210217232440 20210120232440 37444 uri.arpa.
U03NntQ73LHWpfLmUK8nMsqkwVsOGW2KdsyuHYAjqQSZvKbtmbv7HBmE EygekDgl+Lyyq4NMSEpPyOrOywYf9Y3FAB4v1DT44J3R5QGidaH8l7ZFjH
H1+Ii3Z+wtfdMZBy5aC/6sHdx69BfZJs16xumycMlAy6325DKTQbIMN+ oYFI8sY64iYOCV4sBnX/dh6C1L5NgpY+8l5065Xu3vvjyzbtuJ2k6YYwJr
ift9GrKBC7cgCd2msF/uzSrYxxg4MJQzBPvlkwXnY3b7eJSlIXisBIn7 3b8= ) rCbvl5DDn53zAhhO2hL9uLgyLraZGi9i7TFGd0sm3zNyUF/EVL0CcxU= )
http.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 ( ftp.uri.arpa. 3600 IN NSEC http.uri.arpa. (
20181029011815 20181007205525 47155 uri.arpa. NAPTR RRSIG NSEC )
T7mRrdag+WSmG+n22mtBSQ/0Y3v+rdDnfQV90LN5Fq32N5K2iYFajF7F ftp.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
Tp56oOznytfcL4fHrqOE0wRc9NWOCCUec9C7Wa1gJQcllEvgoAM+L6f0 20210217232440 20210120232440 37444 uri.arpa.
RsEjWq6+9jvlLKMXQv0xQuMX17338uoD/xiAFQSnDbiQKxwWMqVAimv5 7Zs= ) pbP4KxevPXCu/bDqcvXiuBppXyFEmtHyiy0eAN5gS7mi6mp9Z9bWFjx/Ld
http.uri.arpa. 3600 IN NSEC mailto.uri.arpa. NAPTR ( H9+6oFGYa5vGmJ5itu/4EDMe8iQeZbI8yrpM4TquB7RR/MGfBnTd8S+sjy
RRSIG NSEC ) QtlRYG7yqEu77Vd78Fme22BKPJ+MVqjS0JHMUE/YUGomPkAjLJJwwGw= )
http.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( http.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
"!^http://([^:/?#]*).*$!\\1!i" . ) "!^http://([^:/?#]*).*$!\\1!i" . )
mailto.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( http.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
20181028110727 20181007175821 47155 uri.arpa. 20210217232440 20210120232440 37444 uri.arpa.
GvxzVL85rEukwGqtuLxek9ipwjBMfTOFIEyJ7afC8HxVMs6mfFa/nEM/ eTqbWvt1GvTeXozuvm4ebaAfkXFQKrtdu0cEiExto80sHIiCbO0WL8UDa/
IdFvvFg+lcYoJSQYuSAVYFl3xPbgrxVSLK125QutCFMdC/YjuZEnq5cl J3cDivtQca7LgUbOb6c17NESsrsVkc6zNPx5RK2tG7ZQYmhYmtqtfg1oU5
fQciMRD7R3+znZfm8d8u/snLV9w4D+lTBZrJJUBe1Efc8vum5vvV7819 ZoY= ) BRdHZ5TyqIXcHlw9Blo2pir1Y9IQgshhD7UOGkbkEmvB1Lrd0aHhAAg= )
mailto.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 ( http.uri.arpa. 3600 IN NSEC mailto.uri.arpa. (
20181028141825 20181007205525 47155 uri.arpa. NAPTR RRSIG NSEC )
MaADUgc3fc5v++M0YmqjGk3jBdfIA5RuP62hUSlPsFZO4k37erjIGCfF http.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
j+g84yc+QgbSde0PQHszl9fE/+SU5ZXiS9YdcbzSZxp2erFpZOTchrpg 20210217232440 20210120232440 37444 uri.arpa.
916T4vx6i59scodjb0l6bDyZ+mtIPrc1w6b4hUyOUTsDQoAJYxdfEuMg Vy4= ) R9rlNzw1CVz2N08q6DhULzcsuUm0UKcPaGAWEU40tr81jEDHsFHNM+khCd
mailto.uri.arpa. 3600 IN NSEC urn.uri.arpa. NAPTR ( OI8nDstzA42aee4rwCEgijxJpRCcY9hrO1Ysrrr2fdqNz60JikMdarvU5O
RRSIG NSEC ) 0p0VXeaaJDfJQT44+o+YXaBwI7Qod3FTMx7aRib8i7istvPm1Rr7ixA= )
mailto.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( mailto.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
"!^mailto:(.*)@(.*)$!\\2!i" . ) "!^mailto:(.*)@(.*)$!\\2!i" . )
urn.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( mailto.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
20181028123243 20181007175821 47155 uri.arpa. 20210217232440 20210120232440 37444 uri.arpa.
Hgsw4Deops1O8uWyELGe6hpR/OEqCnTHvahlwiQkHhO5CSEQrbhmFAWe Ch2zTG2F1plEvQPyIH4Yd80XXLjXOPvMbiqDjpJBcnCJsV8QF7kr0wTLnU
UOkmGAdTEYrSz+skLRQuITRMwzyFf4oUkZihGyhZyzHbcxWfuDc/Pd/9 T3dB+asQudOjPyzaHGwFlMzmrrAsszN4XAMJ6htDtFJdsgTMP/NkHhYRSm
DSl56gdeBwy1evn5wBTms8yWQVkNtphbJH395gRqZuaJs3LD/qTyJ5Dp LvA= ) Vv6rLeAhd+mVfObY12M//b/GGVTjeUI/gJaLW0fLVZxr1Fp5U5CRjyw= )
urn.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 ( mailto.uri.arpa. 3600 IN NSEC urn.uri.arpa. (
20181029071816 20181007205525 47155 uri.arpa. NAPTR RRSIG NSEC )
ALIZD0vBqAQQt40GQ0Efaj8OCyE9xSRJRdyvyn/H/wZVXFRFKrQYrLAS mailto.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
D/K7q6CMTOxTRCu2J8yes63WJiaJEdnh+dscXzZkmOg4n5PsgZbkvUSW 20210217232440 20210120232440 37444 uri.arpa.
BiGtxvz5jNncM0xVbkjbtByrvJQAO1cU1mnlDKe1FmVB1uLpVdA9Ib4J hMU= ) fQUbSIE6E7JDi2rosah4SpCOTrKufeszFyj5YEavbQuYlQ5cNFvtm8KuE2
urn.uri.arpa. 3600 IN NSEC uri.arpa. NAPTR RRSIG ( xXMRgRI4RGvM2leVqcoDw5hS3m2pOJLxH8l2WE72YjYvWhvnwc5Rofe/8y
NSEC ) B/vaSK9WCnqN8y2q6Vmy73AGP0fuiwmuBra7LlkOiqmyx3amSFizwms= )
urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
"/urn:([^:]+)/\\1/i" . ) "/urn:([^:]+)/\\1/i" . )
uri.arpa. 3600 IN SOA sns.dns.icann.org. ( urn.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 (
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) 20210217232440 20210120232440 37444 uri.arpa.
;; Query time: 66 msec CVt2Tgz0e5ZmaSXqRfNys/8OtVCk9nfP0zhezhN8Bo6MDt6yyKZ2kEEWJP
;; SERVER: 192.0.32.132#53(192.0.32.132) jkN7PCYHjO8fGjnUn0AHZI2qBNv7PKHcpR42VY03q927q85a65weOO1YE0
;; WHEN: Sun Oct 21 20:39:28 UTC 2018 vPYMzACpua9TOtfNnynM2Ws0uN9URxUyvYkXBdqOC81N3sx1dVELcwc= )
;; XFR size: 34 records (messages 1, bytes 3941) urn.uri.arpa. 3600 IN NSEC uri.arpa. NAPTR RRSIG NSEC
uri.arpa. 3600 IN ZONEMD 2018100702 1 1 ( urn.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 (
1291b78ddf7669b1a39d014d87626b709b55774c5d7d58fa 20210217232440 20210120232440 37444 uri.arpa.
dc556439889a10eaf6f11d615900a4f996bd46279514e473 ) JuKkMiC3/j9iM3V8/izcouXWAVGnSZjkOgEgFPhutMqoylQNRcSkbEZQzF
]]></artwork></figure> K8B/PIVdzZF0Y5xkO6zaKQjOzz6OkSaNPIo1a7Vyyl3wDY/uLCRRAHRJfp
</section> knuY7O+AUNXvVVIEYJqZggd4kl/Rjh1GTzPYZTRrVi5eQidI1LqCOeg= )
</sourcecode>
<section title="The ROOT-SERVERS.NET Zone"> </section>
<section numbered="true" toc="default">
<name>The ROOT-SERVERS.NET Zone</name>
<t> <t>
The ROOT-SERVERS.NET zone retrieved 2018-10-21. The following sample zone is the ROOT-SERVERS.NET zone retrieved 2018- 10-21.
</t> </t>
<figure><artwork align="left"><![CDATA[ <sourcecode type="dns-rr">
root-servers.net. 3600000 IN SOA a.root-servers.net. ( root-servers.net. 3600000 IN SOA a.root-servers.net. (
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) 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 a.root-servers.net.
root-servers.net. 3600000 IN NS b.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 c.root-servers.net.
root-servers.net. 3600000 IN NS d.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 e.root-servers.net.
root-servers.net. 3600000 IN NS f.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 g.root-servers.net.
root-servers.net. 3600000 IN NS h.root-servers.net. root-servers.net. 3600000 IN NS h.root-servers.net.
skipping to change at line 1777 skipping to change at line 1694
k.root-servers.net. 3600000 IN A 193.0.14.129 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 AAAA 2001:500:9f::42
l.root-servers.net. 3600000 IN A 199.7.83.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 AAAA 2001:dc3::35
m.root-servers.net. 3600000 IN A 202.12.27.33 m.root-servers.net. 3600000 IN A 202.12.27.33
root-servers.net. 3600000 IN SOA a.root-servers.net. ( root-servers.net. 3600000 IN SOA a.root-servers.net. (
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 ( root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 (
f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97 f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97
8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 ) 8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 )
]]></artwork></figure> </sourcecode>
</section> </section>
</section> </section>
<section anchor="Implementation" numbered="true" toc="default">
<section anchor="Implementation" title="Implementation Status"> <name>Implementation Status</name>
<t>
RFC Editor: Please retain this section upon publication.
</t>
<t> <t>
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of publication, and i s inspired by the protocol defined by this specification at the time of publication, and i s inspired by the
concepts described in RFC7942. concepts described in RFC 7942.
</t> </t>
<t> <t>
Please note that the listing of any Please note that the listing of any
individual implementation here does not imply endorsement by the individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors. information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers catalog of available implementations or their features. Readers
are advised to note that other implementations may exist. are advised to note that other implementations may exist.
</t> </t>
<section anchor="authors-implementation" numbered="true" toc="default">
<name>Authors' Implementation</name>
<t>
The authors have an open-source implementation in C, using the ldns
library (<xref target="LDNS-ZONE-DIGEST" format="default"/>). This
implementation is able to perform the following functions:
</t>
<ul spacing="normal">
<li>Read an input zone and output a zone with the ZONEMD placeholder.<
/li>
<section title="Authors' Implementation" anchor="authors-implementation"> <li>Compute the zone digest over the signed zone and update the ZONEMD
record.</li>
<li>Recompute DNSSEC signatures over the ZONEMD record.</li>
<li>Verify the zone digest from an input zone.</li>
</ul>
<t> <t>
The authors have an open source implementation in
C, using the ldns library <xref target="ldns-zone-digest"/>. This imp
lementation is able to
perform the following functions:
<list style="symbols">
<t>Read an input zone and output a zone with the &RRNAME; placeholder.
</t>
<t>Compute zone digest over signed zone and update the &RRNAME; record
.</t>
<t>Re-compute DNSSEC signature over the &RRNAME; record.</t>
<t>Verify the zone digest from an input zone.</t>
</list>
This implementation does not: This implementation does not:
<list style="symbols">
<t>Perform DNSSEC validation of the &RRNAME; record during verificatio
n.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>Perform DNSSEC validation of the ZONEMD record during verification
.</li>
</ul>
</section> </section>
<section title="Shane Kerr's Implementation"> <section numbered="true" toc="default">
<t> Shane Kerr wrote an implementation of this specification during the <name>Shane Kerr's Implementation</name>
IETF 102 hackathon <t><contact fullname="Shane Kerr"/> wrote an implementation of this
<xref target="ZoneDigestHackathon"/>. This implementation is in Pytho specification during the IETF 102 hackathon (<xref
n and is able to target="ZONE-DIGEST-HACKATHON" format="default"/>). This implementation
perform the following functions: is in Python and is able to perform the following functions:
<list style="symbols"> </t>
<t>Read an input zone and output a zone with &RRNAME; record.</t> <ul spacing="normal">
<t>Verify the zone digest from an input zone.</t> <li>Read an input zone and output a zone with ZONEMD record.</li>
<t>Output the &RRNAME; record in its defined presentation format.</t> <li>Verify the zone digest from an input zone.</li>
</list> <li>Output the ZONEMD record in its defined presentation format.</li>
</ul>
<t>
This implementation does not: This implementation does not:
<list style="symbols">
<t>Re-compute DNSSEC signature over the &RRNAME; record.</t>
<t>Perform DNSSEC validation of the &RRNAME; record.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>Recompute DNSSEC signatures over the ZONEMD record.</li>
<li>Perform DNSSEC validation of the ZONEMD record.</li>
</ul>
</section> </section>
<section title="NIC Chile Labs Implementation"> <section numbered="true" toc="default">
<name>NIC Chile Lab's Implementation</name>
<t> <t>
NIC Chile Labs wrote an implementation of this specification NIC Chile Labs wrote an implementation of this specification
as part of "dns-tools" suite <xref target="DnsTools"/>, as part of "dns-tools" suite (<xref target="DNS-TOOLS" format="default "/>),
which besides digesting, can also sign and verify zones. This which besides digesting, can also sign and verify zones. This
implementation is in Go and is able to perform the following implementation is in Go and is able to perform the following
functions: functions:
<list style="symbols">
<t>Compute zone digest over signed zone and update the &RRNAME; record
.</t>
<t>Verify the zone digest from an input zone.</t>
<t>Perform DNSSEC validation of the &RRNAME; record during verificatio
n.</t>
<t>Re-compute DNSSEC signature over the &RRNAME; record.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>Compute zone digest over signed zone and update the ZONEMD record.
</li>
<li>Verify the zone digest from an input zone.</li>
<li>Perform DNSSEC validation of the ZONEMD record during verification
.</li>
<li>Recompute DNSSEC signatures over the ZONEMD record.</li>
</ul>
</section> </section>
</section> </section>
</back> <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> </rfc>
 End of changes. 243 change blocks. 
1408 lines changed or deleted 1246 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/