< draft-ietf-dnsop-dns-zone-digest-09.txt   draft-ietf-dnsop-dns-zone-digest-10.txt >
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft P. Barber Internet-Draft P. Barber
Intended status: Standards Track Verisign Intended status: Standards Track Verisign
Expires: March 1, 2021 M. Weinberg Expires: March 25, 2021 M. Weinberg
Amazon Amazon
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
August 28, 2020 September 21, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-09 draft-ietf-dnsop-dns-zone-digest-10
Abstract Abstract
This document describes a protocol and new DNS Resource Record that This document describes a protocol and new DNS Resource Record that
can be used to provide a cryptographic message digest over DNS zone provides a cryptographic message digest over DNS zone data. The
data. The ZONEMD Resource Record conveys the digest data in the zone ZONEMD Resource Record conveys the digest data in the zone itself.
itself. When a zone publisher includes an ZONEMD record, recipients When a zone publisher includes a ZONEMD record, recipients can verify
can verify the zone contents for accuracy and completeness. This the zone contents for accuracy and completeness. This provides
provides assurance that received zone data matches published data, assurance that received zone data matches published data, regardless
regardless of how the zone data has been transmitted and received. of how the zone data has been transmitted and received.
ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects ZONEMD does not replace DNSSEC. Whereas DNSSEC protects individual
individual RRSets (DNS data with fine granularity), ZONEMD protects a RRSets (DNS data with fine granularity), ZONEMD protects a zone's
zone's data as a whole, whether consumed by authoritative name data as a whole, whether consumed by authoritative name servers,
servers, recursive name servers, or any other applications. recursive name servers, or any other applications.
As specified at this time, ZONEMD is not designed for use in large, As specified herein, ZONEMD is impractical for large, dynamic zones
dynamic zones due to the time and resources required for digest due to the time and resources required for digest calculation.
calculation. The ZONEMD record described in this document is However, The ZONEMD record is extensible so that new digest schemes
designed so that new digest schemes may be developed in the future to may be added in the future to support large, dynamic zones.
support large, dynamic zones.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 1, 2021. This Internet-Draft will expire on March 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Design Overview . . . . . . . . . . . . . . . . . . . . . 6 1.2. Alternative Approaches . . . . . . . . . . . . . . . . . 4
1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Design Overview . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Providers, Secondaries, and Anycast . . . . . . . . . 6 1.4.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 7 1.4.2. Providers, Secondaries, and Anycast . . . . . . . . . 6
1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.4.3. Response Policy Zones . . . . . . . . . . . . . . . . 7
1.3.5. General Purpose Comparison Check . . . . . . . . . . 7 1.4.4. Centralized Zone Data Service . . . . . . . . . . . . 7
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.4.5. General Purpose Comparison Check . . . . . . . . . . 7
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7
2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8 2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8
2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9 2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9
2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9 2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9
2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9
2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10
3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10
3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 11
3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11 3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11
3.3.1.1. SIMPLE Scheme RR Format . . . . . . . . . . . . . 11 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11
3.3.1.2. SIMPLE Scheme RR Ordering . . . . . . . . . . . . 11 3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12
3.3.1.3. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11
3.3.1.4. SIMPLE Scheme Digest Calculation . . . . . . . . 12
3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14
5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15
6.2. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 15 6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16
6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 16 6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16
7. Performance Considerations . . . . . . . . . . . . . . . . . 16 6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 16
7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 16 7. Performance Considerations . . . . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Authors' Implementation . . . . . . . . . . . . . . . . 17 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.3. NIC Chile Labs Implementation . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 27 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 27
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 28 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 28
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Implementation Status . . . . . . . . . . . . . . . 34
B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34
B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34
B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
In the DNS, a zone is the collection of authoritative resource In the DNS, a zone is the collection of authoritative resource
records (RRs) sharing a common origin ([RFC8499]). Zones are often records (RRs) sharing a common origin ([RFC8499]). Zones are often
stored as files on disk in the so-called master file format stored as files in the so-called master file format [RFC1034]. Zones
[RFC1034]. Zones are generally distributed among name servers using are generally distributed among name servers using the AXFR (zone
the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995])
also be distributed outside of the DNS, with such protocols as FTP, protocols. They can also be distributed outside of the DNS, with any
HTTP, and rsync, and even via email. Currently there is no standard file transfer protocol such as FTP, HTTP, and rsync, or even as email
way to verify the authenticity of a stand-alone zone. attachments. Currently there is no standard way to verify the
authenticity of a stand-alone zone.
This document introduces a new RR type that serves as a cryptographic This document specifies an RR type that provides a cryptographic
message digest of the data in a zone. It allows a receiver of the message digest of the data in a zone. It allows a receiver of the
zone to verify the zone's authenticity, especially when used in zone to verify the zone's integrity, and when used in combination
combination with DNSSEC. This technique makes the digest a part of with DNSSEC, its authenticity. The digest RR is a part of the zone
the zone itself, allowing verification the zone as a whole, no matter itself, allowing verification of the zone, no matter how it is
how it is transmitted. Furthermore, the digest is based on the wire transmitted. The digest uses the wire format of zone data in a
format of zone data. Thus, it is independent of presentation format, canonical ordering. Thus, it is independent of presentation format,
such as changes in whitespace, capitalization, and comments. such as whitespace, capitalization, and comments.
This specification is OPTIONAL to implement by both publishers and
consumers of zone data.
DNSSEC provides three strong security guarantees relevant to this DNSSEC provides three strong security guarantees relevant to this
protocol: protocol:
1. whether or not to expect DNSSEC records in the zone, 1. whether or not to expect DNSSEC records in the zone,
2. whether or not to expect a ZONEMD record in a signed zone, and 2. whether or not to expect a ZONEMD record in a signed zone, and
3. whether or not the ZONEMD record has been altered since it was 3. whether or not the ZONEMD record has been altered since it was
signed. signed.
This specification is OPTIONAL to implement by both publishers and
consumers of zone data.
1.1. Motivation 1.1. Motivation
The motivation for this protocol enhancement is the desire for the The motivation for this protocol enhancement is the desire to verify
ability to verify the authenticity of a stand-alone zone, regardless the authenticity of a stand-alone zone, regardless of how it is
of how it is transmitted. A consumer of zone data should be able to transmitted. A consumer of zone data should be able to verify that
verify that the data is as-published by the zone operator. the data is as-published by the zone operator.
1.2. Alternative Approaches
One approach to preventing data tampering and corruption is to secure One approach to preventing data tampering and corruption is to secure
the distribution channel. The DNS has a number of features that can the distribution channel. The DNS has a number of features that are
already be used for channel security. Perhaps the most widely used already used for channel security. Perhaps the most widely used is
is DNS transaction signatures (TSIG [RFC2845]). TSIG uses shared DNS transaction signatures (TSIG [RFC2845]). TSIG uses shared secret
secret keys and a message digest to protect individual query and keys and a message digest to protect individual query and response
response messages. It is generally used to authenticate and validate messages. It is generally used to authenticate and validate UPDATE
UPDATE [RFC2136], AXFR [RFC5936], and IXFR [RFC1995] messages. [RFC2136], AXFR [RFC5936], and IXFR [RFC1995] messages.
DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another
protocol extension designed to authenticate individual DNS protocol extension that authenticates individual DNS transactions.
transactions. Whereas SIG records were originally designed to cover Whereas SIG records normally cover specific RR types, SIG(0) is used
specific RR types, SIG(0) is used to sign an entire DNS message. to sign an entire DNS message. Unlike TSIG, SIG(0) uses public key
Unlike TSIG, SIG(0) uses public key cryptography rather than shared cryptography rather than shared secrets.
secrets.
The Transport Layer Security protocol suite is also designed to The Transport Layer Security protocol suite also provides channel
provide channel security. One can easily imagine the distribution of security. One can easily imagine the distribution of zones over
zones over HTTPS-enabled web servers, as well as DNS-over-HTTPS HTTPS-enabled web servers, as well as DNS-over-HTTPS [RFC8484], and
[RFC8484], and perhaps even a future version of DNS-over-TLS perhaps even a future version of DNS-over-TLS ([RFC7858]).
([RFC7858]).
Unfortunately, the protections provided by these channel security Unfortunately, the protections provided by these channel security
techniques are (in practice) ephemeral and are not retained after the techniques are (in practice) ephemeral and are not retained after the
data transfer is complete. They can ensure that the client receives data transfer is complete. They ensure that the client receives the
the data from the expected server, and that the data sent by the data from the expected server, and that the data sent by the server
server is not modified during transmission. However, they do not is not modified during transmission. However, they do not guarantee
guarantee that the server transmits the data as originally published, that the server transmits the data as originally published, and do
and do not provide any methods to verify data that is read after not provide any methods to verify data that is read after
transmission is complete. For example, a name server loading saved transmission is complete. For example, a name server loading saved
zone data upon restart cannot guarantee that the on-disk data has not zone data upon restart cannot guarantee that the on-disk data has not
been modified. For these reasons, it is preferable to secure the been modified. Such modification could be the result of an
data itself. accidental corruption of the file, or perhaps an incompletely saved
file [disk-full-failure]. For these reasons, it is preferable to
secure the data itself.
Why not simply rely on DNSSEC, which provides certain data security Why not simply rely on DNSSEC, which provides certain data security
guarantees? Certainly for zones that are signed, a recipient could guarantees? For zones that are signed, a recipient could validate
validate all of the signed RRSets. Additionally, denial-of-existence all of the signed RRSets. Additionally, denial-of-existence records
records can prove that RRSets have not been added or removed. prove that RRSets have not been added or removed. However,
However, not all RRSets in a zone are signed. The design of DNSSEC delegations (non-apex NS records) are not signed by DNSSEC, and
stipulates that delegations (non-apex NS records) are not signed, and
neither are any glue records. ZONEMD protects the integrity of neither are any glue records. ZONEMD protects the integrity of
delegation, glue, and other records that are not otherwise covered by delegation, glue, and other records that are not otherwise covered by
DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are
susceptible to the removal or addition of names between the signed susceptible to the removal or addition of names between the signed
nodes. Whereas DNSSEC is primarily designed to protect consumers of nodes. Whereas DNSSEC is primarily protects consumers of DNS
DNS response messages, this protocol is designed to protect consumers response messages, this protocol protects consumers of zones.
of zones.
There are existing tools and protocols that provide data security, There are existing tools and protocols that provide data security,
such as OpenPGP [RFC4880] and S/MIME [RFC5751]. In fact, the such as OpenPGP [RFC4880] and S/MIME [RFC5751]. In fact, the
internic.net site publishes PGP signatures alongside the root zone internic.net site publishes PGP signatures alongside the root zone
and other files available there. However, this is a detached and other files available there. However, this is a detached
signature with no strong association to the corresponding zone file signature with no strong association to the corresponding zone file
other than its timestamp. Non-detached signatures are, of course, other than its timestamp. Non-detached signatures are, of course,
possible, but these necessarily change the format of the file being possible, but these necessarily change the format of the file being
distributed. That is, a zone signed with OpenPGP or S/MIME no longer distributed; a zone signed with OpenPGP or S/MIME no longer looks
looks like a DNS zone and could not directly be loaded into a name like a DNS zone and could not directly be loaded into a name server.
server. Once loaded the signature data is lost, so it does not Once loaded the signature data is lost, so it cannot be further
survive further propagation. propagated.
It seems the desire for data security in DNS zones was envisioned as It seems the desire for data security in DNS zones was envisioned as
far back as 1997. [RFC2065] is an obsoleted specification of the far back as 1997. [RFC2065] is an obsoleted specification of the
first generation DNSSEC Security Extensions. It describes a zone first generation DNSSEC Security Extensions. It describes a zone
transfer signature, aka AXFR SIG, which is similar to the technique transfer signature, identified as the AXFR SIG, which is similar to
proposed by this document. That is, it proposes ordering all the technique proposed by this document. That is, it proposes
(signed) RRSets in a zone, hashing their contents, and then signing ordering all (signed) RRSets in a zone, hashing their contents, and
the zone hash. The AXFR SIG is described only for use during zone then signing the zone hash. The AXFR SIG is described only for use
transfers. It did not postulate the need to validate zone data during zone transfers. It did not postulate the need to validate
distributed outside of the DNS. Furthermore, its successor, zone data distributed outside of the DNS. Furthermore, its
[RFC2535], omits the AXFR SIG, while at the same time introducing an successor, [RFC2535], omits the AXFR SIG, while at the same time
IXFR SIG. introducing an IXFR SIG.
1.2. Design Overview 1.3. Design Overview
This document introduces a new Resource Record type designed to This document specifies a new Resource Record type to convey a
convey a message digest of the content of a zone. The digest is message digest of the content of a zone. The digest is calculated at
calculated at the time of zone publication. Ideally the zone is the time of zone publication. If the zone is signed with DNSSEC, any
signed with DNSSEC to guarantee that any modifications of the digest modifications of the digest can be detected. The procedures for
can be detected. The procedures for digest calculation and DNSSEC digest calculation and DNSSEC signing are similar. Both require data
signing are similar. Both require data to be processed in a well- to be processed in a well-defined order and format. It may be
defined order and format. In some cases it may be possible to possible to perform DNSSEC signing and digest calculation in
perform DNSSEC signing and digest calculation in parallel. parallel.
The zone digest is designed to be used on zones that are relatively The zone digest is designed to be used on zones that have infrequent
stable and have infrequent updates. As currently specified, the updates. As specified herein, the digest is re-calculated over the
digest is re-calculated over the entire zone content each time. This entire zone content each time. This specification does not provide
specification does not provide an efficient mechanism for incremental an efficient mechanism for updating the digest on incremental updates
updates of zone data. It is, however, extensible so that future of zone data. It is, however, extensible so future schemes to
schemes to support incremental zone digest algorithms (e.g. using support incremental zone digest algorithms (e.g. using Merkle trees)
Merkle trees) can be accommodated. can be accommodated.
It is expected that verification of a zone digest would be It is expected that verification of a zone digest will be implemented
implemented in name server software. That is, a name server can in name server software. That is, a name server can verify the zone
verify the zone data it was given and refuse to serve a zone which data it was given and refuse to serve a zone which fails
fails verification. For signed zones, the name server needs a trust verification. For signed zones, the name server needs a trust anchor
anchor to perform DNSSEC validation. For signed non-root zones, the to perform DNSSEC validation. For signed non-root zones, the name
name server may need to send queries to validate a chain of trust. server may need to send queries to validate a chain of trust. Digest
Digest verification could also be performed externally. verification could also be performed externally.
1.3. Use Cases 1.4. Use Cases
1.3.1. Root Zone 1.4.1. Root Zone
The root zone [InterNIC] is one of the most widely distributed DNS The root zone [InterNIC] is one of the most widely distributed DNS
zone on the Internet, served by more than 1000 separate instances zone on the Internet, served by more than 1000 separate instances
[RootServers] at the time of this writing. Additionally, many [RootServers] at the time of this writing. Additionally, many
organizations configure their own name servers to serve the root zone organizations configure their own name servers to serve the root zone
locally. Reasons for doing so include privacy and reduced access locally. Reasons for doing so include privacy and reduced access
time. [RFC8806] describes one, but not the only, way to do this. As time. [RFC8806] describes one way to do this. As the root zone
the root zone spreads beyond its traditional deployment boundaries, spreads beyond its traditional deployment boundaries, the
the need for verification of the completeness of the zone contents verification of the completeness of the zone contents becomes more
becomes increasingly important. important.
1.3.2. Providers, Secondaries, and Anycast 1.4.2. Providers, Secondaries, and Anycast
Since its very early days, the developers of the DNS recognized the Since its very early days, the developers of the DNS recognized the
importance of secondary name servers and service diversity. However, importance of secondary name servers and service diversity. However,
they may not have anticipated the complexity of modern DNS service modern DNS service has complex provisioning which includes multiple
provisioning which can include multiple third-party providers and third-party providers and hundreds of anycast instances. Instead of
hundreds of anycast instances. Instead of a simple primary-to- a simple primary-to-secondary zone distribution system, today it is
secondary zone distribution system, today it is possible to have possible to have multiple levels, multiple parties, and multiple
multiple levels, multiple parties, and multiple protocols involved in protocols involved in the distribution of zone data. This complexity
the distribution of zone data. This complexity introduces new places introduces new places for problems to arise. The zone digest
for problems to arise. The zone digest protects the integrity of protects the integrity of data that flows through such systems.
data that flows through such systems.
1.3.3. Response Policy Zones 1.4.3. Response Policy Zones
DNS Response Policy Zones is "a method of expressing DNS response DNS Response Policy Zones is "a method of expressing DNS response
policy information inside specially constructed DNS zones..." [RPZ]. policy information inside specially constructed DNS zones..." [RPZ].
A number of companies provide RPZ feeds, which can be consumed by A number of companies provide RPZ feeds, which are consumed by name
name server and firewall products. Since these are zones, AXFR is server and firewall products. While RPZ zones can be signed with
often, but not necessarily used for transmission. While RPZ zones DNSSEC, the data is not queried directly, and would not be subject to
can certainly be signed with DNSSEC, the data is not queried DNSSEC validation.
directly, and would not be subject to DNSSEC validation.
1.3.4. Centralized Zone Data Service 1.4.4. Centralized Zone Data Service
ICANN operates the Centralized Zone Data Service [CZDS], which is a ICANN operates the Centralized Zone Data Service [CZDS], which is a
repository of top-level domain zone files. Users request access to repository of top-level domain zone files. Users that have been
the system, and to individual zones, and are then able to download granted access are then able to download zone data. Adding a zone
zone data for certain uses. Adding a zone digest to these would digest to these would provide CZDS users with assurances that the
provide CZDS users with assurances that the data has not been data has not been modified. ZONEMD could be added to CZDS zone data
modified. Note that ZONEMD could be added to CZDS zone data
independently of the zone served by production name servers. independently of the zone served by production name servers.
1.3.5. General Purpose Comparison Check 1.4.5. General Purpose Comparison Check
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 a zone format, it could be used to compare multiple copies of a zone
received from different sources, or copies generated by different received from different sources, or copies generated by different
processes. processes.
1.4. Requirements Language 1.5. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terms Private Use, Reserved, Unassigned, and Specification
Required are to be interpreted as defined in [RFC8126].
2. The ZONEMD Resource Record 2. The ZONEMD Resource Record
This section describes the ZONEMD Resource Record, including its This section describes the ZONEMD Resource Record, including its
fields, wire format, and presentation format. The Type value for the fields, wire format, and presentation format. The Type value for the
ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
the resource record consists of four fields: Serial, Scheme, Hash the resource record consists of four fields: Serial, Scheme, Hash
Algorithm, and Digest. Algorithm, and Digest.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility A zone MAY contain multiple ZONEMD RRs to support algorithm agility
[RFC7696] and rollovers. When multiple ZONEMD RRs are present, each [RFC7696] and rollovers. When multiple ZONEMD RRs are present, each
must specify a unique Scheme and Hash Algorithm tuple. It is must specify a unique Scheme and Hash Algorithm tuple. It is
recommended that a zone include only one ZONEMD RR, unless the zone recommended that a zone include only one ZONEMD RR, unless the zone
publisher is in the process of transitioning to a new Scheme or Hash publisher is in the process of transitioning to a new Scheme or Hash
Algorithm. Algorithm.
2.1. Non-apex ZONEMD Records 2.1. Non-apex ZONEMD Records
This specification utilizes ZONEMD RRs located at the zone apex. This document specifies ZONEMD RRs located at the zone apex. Non-
Non-apex ZONEMD RRs are not forbidden, but have no meaning in this apex ZONEMD RRs are not forbidden, but have no meaning in this
specification. Non-apex ZONEMD RRs MUST NOT be used for specification. Non-apex ZONEMD RRs MUST NOT be used for
verification. verification.
During digest calculation, non-apex ZONEMD RRs are treated like any During digest calculation, non-apex ZONEMD RRs are treated as
other RRs. They are digested as-is and the RR is not replaced by a ordinary RRs. They are digested as-is and the RR is not replaced by
placeholder RR. a placeholder RR.
Unless explicitly stated otherwise, "ZONEMD" always refers to apex Unless explicitly stated otherwise, "ZONEMD" always refers to apex
records throughout this document. records throughout this document.
2.2. ZONEMD RDATA Wire Format 2.2. ZONEMD RDATA Wire Format
The ZONEMD RDATA wire format is encoded as follows: The ZONEMD RDATA wire format is encoded as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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
skipping to change at page 8, line 44 skipping to change at page 8, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheme |Hash Algorithm | | | Scheme |Hash Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Digest | | Digest |
/ / / /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.1. The Serial Field 2.2.1. The Serial Field
The Serial field is a 32-bit unsigned integer in network order. It The Serial field is a 32-bit unsigned integer in network byte order.
is equal to the serial number from the zone's SOA record ([RFC1035] It is the serial number from the zone's SOA record ([RFC1035] section
section 3.3.13) for which the zone digest was generated. 3.3.13) for which the zone digest was generated.
The zone's serial number is included here in order to make DNS It is included here in order to make DNS response messages of type
response messages of type ZONEMD meaningful. Without the serial ZONEMD meaningful. Without the serial number, a stand-alone ZONEMD
number, a stand-alone ZONEMD digest has no association to any digest has no association to any particular instance of a zone.
particular instance of a zone.
2.2.2. The Scheme Field 2.2.2. The Scheme Field
The Scheme field is an 8-bit unsigned integer that identifies the The Scheme field is an 8-bit unsigned integer that identifies the
methods by which data is collated and presented as input to the methods by which data is collated and presented as input to the
hashing function. hashing function.
At the time of this writing, SIMPLE, with value 1, is the only Herein, SIMPLE, with value 1, is the only standardized Scheme defined
standardized Scheme defined for ZONEMD records. The Scheme registry for ZONEMD records and it MUST be implemented. The Scheme registry
is further described in Section 5. is further described in Section 5.
Scheme values 240-254 are allocated for Private Use as described in Scheme values 240-254 are allocated for Private Use.
[RFC8126].
2.2.3. The Hash Algorithm Field 2.2.3. The Hash Algorithm Field
The Hash Algorithm field is an 8-bit unsigned integer that identifies The Hash Algorithm field is an 8-bit unsigned integer that identifies
the cryptographic hash algorithm used to construct the digest. the cryptographic hash algorithm used to construct the digest.
At the time of this writing, SHA384, with value 1, is the only Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
standardized Hash Algorithm defined for ZONEMD records. The Hash Algorithm defined for ZONEMD records that MUST be implemented. When
Algorithm registry is further described in Section 5. SHA384 is used, the size of the Digest field is 48 octets.
Hash Algorithm values 240-254 are allocated for Private Use as SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
described in [RFC8126]. ZONEMD records, and SHOULD be implemented. When SHA512 is used, the
size of the Digest field is 64 octets.
Hash Algorithm values 240-254 are allocated for Private Use.
The Hash Algorithm registry is further described in Section 5.
2.2.4. The Digest Field 2.2.4. The Digest Field
The Digest field is a variable-length sequence of octets containing The Digest field is a variable-length sequence of octets containing
the output of the hash algorithm. The Digest field must not be the output of the hash algorithm. The Digest field MUST NOT be
empty. Section 3 describes how to calculate the digest for a zone. shorter than 12 octets. The length of the Digest field is determined
Section 4 describes how to use the digest to verify the contents of a by deducting the fixed size of the Serial, Scheme, and Hash Algorithm
zone. fields from the RDATA size in the ZONEMD RR header. Section 3
describes how to calculate the digest for a zone. Section 4
describes how to use the digest to verify the contents of a zone.
2.3. ZONEMD Presentation Format 2.3. ZONEMD Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Serial field is represented as an unsigned decimal integer. The Serial field is represented as an unsigned decimal integer.
The Scheme field is represented as an unsigned decimal integer. The Scheme field is represented as an unsigned decimal integer.
The Hash Algorithm field is represented as an unsigned decimal The Hash Algorithm field is represented as an unsigned decimal
integer. integer.
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.
2.4. ZONEMD Example 2.4. ZONEMD Example
The following example shows a ZONEMD RR. The following example shows a ZONEMD RR in presentation format:
example.com. 86400 IN ZONEMD 2018031500 1 1 ( example.com. 86400 IN ZONEMD 2018031500 1 1 (
FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
3. Calculating the Digest 3. Calculating the Digest
3.1. Add ZONEMD Placeholder 3.1. Add ZONEMD Placeholder
In preparation for calculating the zone digest, any existing ZONEMD In preparation for calculating the zone digest, any existing ZONEMD
records (and covering RRSIGs) at the zone apex are first deleted. records (and covering RRSIGs) at the zone apex are first deleted.
Prior to calculation of the digest, and prior to signing with DNSSEC, Prior to calculation of the digest, and prior to signing with DNSSEC,
one or more placeholder ZONEMD records are added to the zone apex. one or more placeholder ZONEMD records are added to the zone apex.
This ensures that denial-of-existence (NSEC, NSEC3) records are This ensures that denial-of-existence (NSEC, NSEC3) records are
created correctly if the zone is signed with DNSSEC. If placeholders created correctly if the zone is signed with DNSSEC. If placeholders
are not added prior to signing, the later addition of ZONEMD records were not added prior to signing, the later addition of ZONEMD records
would also require updating the Type Bit Maps field of any apex NSEC/ would also require updating the Type Bit Maps field of any apex NSEC/
NSEC3 RRs, which then invalidates the calculated digest value. NSEC3 RRs, which then invalidates the calculated digest value.
When multiple ZONEMD RRs are published in the zone, e.g., during an When multiple ZONEMD RRs are published in the zone, e.g., during an
algorithm rollover, each must specify a unique Scheme and Hash algorithm rollover, each MUST specify a unique Scheme and Hash
Algorithm tuple. Algorithm tuple.
It is recommended that the TTL of the ZONEMD record match the TTL of It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of
the SOA. the SOA.
In the placeholder record, the Serial field is set to the current SOA In the placeholder record, the Serial field is set to the current SOA
Serial. The Scheme field is set to the value for the chosen Serial. The Scheme field is set to the value for the chosen
collation scheme. The Hash Algorithm field is set to the value for collation scheme. The Hash Algorithm field is set to the value for
the chosen hash algorithm. Since ZONEMD records are excluded from the chosen hash algorithm. Since ZONEMD records are excluded from
digest calculation, the value of the Digest field does not matter at digest calculation, the value of the Digest field does not matter at
this point in the process. this point in the process.
3.2. Optionally Sign the Zone 3.2. Optionally Sign the Zone
Following addition of placeholder records, the zone may be signed Following addition of placeholder records, the zone may be signed
with DNSSEC. Note that when the digest calculation is complete, and with DNSSEC. When the digest calculation is complete, and the ZONEMD
the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet record is updated, the signature(s) for the ZONEMD RRSet MUST be
MUST be recalculated and updated as well. Therefore, the signer is recalculated and updated as well. Therefore, the signer is not
not required to calculate a signature over the placeholder record at required to calculate a signature over the placeholder record at this
this step in the process, but it is harmless to do so. step in the process, but it is harmless to do so.
3.3. Scheme-Specific Processing 3.3. Scheme-Specific Processing
At this time, only the SIMPLE collation scheme is defined. Herein, only the SIMPLE collation scheme is defined. Additional
Additional schemes may be defined in future updates to this document. schemes may be defined in future updates to this document.
3.3.1. The SIMPLE Scheme 3.3.1. The SIMPLE Scheme
For the SIMPLE scheme, the digest is calculated over the zone as a For the SIMPLE scheme, the digest is calculated over the zone as a
whole. This means that a change to a single RR in the zone requires whole. This means that a change to a single RR in the zone requires
iterating over all RRs in the zone to recalculate the digest. SIMPLE iterating over all RRs in the zone to recalculate the digest. SIMPLE
is a good choice for zones that are small and/or stable, but probably is a good choice for zones that are small and/or stable, but probably
not good for zones that are large and/or dynamic. not good for zones that are large and/or dynamic.
Calculation of a zone digest REQUIRES RRs to be processed in a Calculation of a zone digest REQUIRES RRs to be processed in a
consistent format and ordering. Correct ordering depends on (1) consistent format and ordering. This specification uses DNSSEC's
ordering of owner names, (2) ordering of RRSets with the same owner canonical on-the-wire RR format (without name compression) and
name, and (3) ordering of RRs within an RRSet. ordering as specified in Sections 6.1, 6.2, and 6.3 of [RFC4034] with
the additional provision that RRSets having the same owner name MUST
3.3.1.1. SIMPLE Scheme RR Format be numerically ordered, in ascending order, by their numeric RR TYPE.
This specification adopts DNSSEC's canonical on-the-wire RR format
(without name compression) as specified in [RFC4034]:
RR(i) = owner | type | class | TTL | RDATA length | RDATA
where "|" denotes concatenation.
3.3.1.2. SIMPLE Scheme RR Ordering
This specification adopts DNSSEC's canonical ordering for names
(Section 6.1 of [RFC4034]), and canonical ordering for RRs within an
RRSet (Section 6.3 of [RFC4034]). It also adopts DNSSEC's canonical
RR form (Section 6.2 of [RFC4034]).
However, since DNSSEC does not define a canonical ordering for RRSets
having the same owner name, that ordering is defined here. For the
purposes of calculating the zone digest, RRSets having the same owner
name MUST be numerically ordered, in ascending order, by their
numeric RR TYPE.
3.3.1.3. SIMPLE Scheme Inclusion/Exclusion Rules 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules
When iterating over records in the zone, the following inclusion/ When iterating over records in the zone, the following inclusion/
exclusion rules apply: exclusion rules apply:
o All records in the zone, including glue records, MUST be included. o All records in the zone, including glue records, MUST be included.
o Occluded data ([RFC5936] Section 3.5) MUST be included. o Occluded data ([RFC5936] Section 3.5) MUST be included.
o If there are duplicate RRs with equal owner, class, type, and o If there are duplicate RRs with equal owner, class, type, and
RDATA, only one instance is included ([RFC4034] Section 6.3), and RDATA, only one instance is included ([RFC4034] Section 6.3), and
the duplicates MUST be omitted. the duplicates MUST be omitted.
o The placeholder ZONEMD RR(s) MUST NOT be included. o The placeholder ZONEMD RR(s) MUST NOT be included.
o If the zone is signed, DNSSEC RRs MUST be included, except: o If the zone is signed, DNSSEC RRs MUST be included, except:
o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG
will be updated after all digests have been calculated. will be updated after all digests have been calculated.
3.3.1.4. SIMPLE Scheme Digest Calculation 3.3.1.2. SIMPLE Scheme Digest Calculation
A zone digest using the SIMPLE scheme is calculated by concatenating A zone digest using the SIMPLE scheme is calculated by concatenating
all RRs in the zone, in the format described in Section 3.3.1.1, in all RRs in the zone, in the format and order described in
the order described in Section 3.3.1.2, subject to the inclusion/ Section 3.3.1 subject to the inclusion/exclusion rules described in
exclusion rules described in Section 3.3.1.3, and then applying the Section 3.3.1.1, and then applying the chosen hash algorithm:
SHA-384 algorithm:
digest = SHA384( RR(1) | RR(2) | RR(3) | ... ) digest = hash( RR(1) | RR(2) | RR(3) | ... )
where "|" denotes concatenation. where "|" denotes concatenation.
3.4. Update ZONEMD RR 3.4. Update ZONEMD RR
Once a zone digest has been calculated, the published ZONEMD record The calculated zone digest is inserted into the placeholder ZONEMD
is finalised by inserting the digest into the placeholder ZONEMD. RR. Repeat for each digest if multiple digests are to be published.
Repeat for each digest if multiple digests are to be published.
If the zone is signed with DNSSEC, the RRSIG record(s) covering the If the zone is signed with DNSSEC, the RRSIG record(s) covering the
ZONEMD RRSet MUST then be added or updated. Because the ZONEMD ZONEMD RRSet MUST then be added or updated. Because the ZONEMD
placeholder was added prior to signing, the zone will already have placeholder was added prior to signing, the zone will already have
the appropriate denial-of-existence (NSEC, NSEC3) records. the appropriate denial-of-existence (NSEC, NSEC3) records.
Some DNSSEC implementations (especially "online signing") might be Some DNSSEC implementations (especially "online signing") might
designed such that the SOA serial number is updated whenever a new update the SOA serial number whenever a new signature is made. To
signature is made. To preserve the calculated digest, generation of preserve the calculated digest, generation of a ZONEMD signature MUST
an ZONEMD signature must not also result in a change to the SOA NOT also result in a change to the SOA serial number. The ZONEMD RR
serial number. The ZONEMD RR and the matching SOA MUST be published and the matching SOA MUST be published at the same time.
at the same time.
4. Verifying Zone Digest 4. Verifying Zone Digest
The recipient of a zone that has a ZONEMD RR can verify the zone by The recipient of a zone that has a ZONEMD RR verifies the zone by
calculating the digest as follows. If multiple ZONEMD RRs are calculating the digest as follows. If multiple ZONEMD RRs are
present in the zone, e.g., during an algorithm rollover, a match present in the zone, e.g., during an algorithm rollover, a match
using any one of the recipient's supported Schemes and Hash using any one of the recipient's supported Schemes and Hash
Algorithms is sufficient to verify the zone. Algorithms is sufficient to verify the zone. The verifier MAY ignore
a ZONEMD RR if its Scheme and Hash Algorithm violates local policy.
1. The verifier MUST first determine whether or not to expect DNSSEC 1. The verifier MUST first determine whether or not to expect DNSSEC
records in the zone. This can be done by examining locally records in the zone. This is done by examining locally
configured trust anchors, or querying for (and validating) DS RRs configured trust anchors, or querying for (and validating) DS RRs
in the parent zone. For zones that are provably insecure, or if in the parent zone. For zones that are provably insecure, or if
DNSSEC validation can not be performed, digest validation DNSSEC validation is not performed, digest verification continues
continues at step 4 below. at step 4 below.
2. For zones that are provably secure, the existence of the apex 2. For zones that are provably secure, the existence of the apex
ZONEMD record MUST be verified. If the ZONEMD record provably ZONEMD record MUST be verified. If the ZONEMD record provably
does not exist, digest verification cannot be done. If the does not exist, digest verification cannot occur. If the ZONEMD
ZONEMD record does provably exist, but is not found in the zone, record does provably exist, but is not found in the zone, digest
digest verification MUST NOT be considered successful. verification MUST NOT be considered successful.
3. For zones that are provably secure, the SOA and ZONEMD RRSets 3. For zones that are provably secure, the SOA and ZONEMD RRSets
MUST have valid signatures, chaining up to a trust anchor. If MUST have valid signatures, chaining up to a trust anchor. If
DNSSEC validation of the SOA or ZONEMD records fails, digest DNSSEC validation of the SOA or ZONEMD records fails, digest
verification MUST NOT be considered successful. verification MUST NOT be considered successful.
4. When multiple ZONEMD RRs are present, each must specify a unique 4. When multiple ZONEMD RRs are present, each MUST specify a unique
Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains
more than one RR with the same Scheme and Hash Algorithm, digest more than one RR with the same Scheme and Hash Algorithm, digest
verification MUST NOT be considered successful. verification for those ZONEMD RRs MUST NOT be considered
successful.
5. Loop over all apex ZONEMD RRs and perform the following steps: 5. Loop over all apex ZONEMD RRs and perform the following steps:
A. The SOA Serial field MUST exactly match the ZONEMD Serial A. The SOA Serial field MUST exactly match the ZONEMD Serial
field. If the fields do not match, digest verification MUST field. If the fields do not match, digest verification MUST
NOT be considered successful with this ZONEMD RR. NOT be considered successful with this ZONEMD RR.
B. The Scheme field MUST be checked. If the verifier does not B. The Scheme field MUST be checked. If the verifier does not
support the given scheme, it SHOULD report that the RR's support the given scheme, verification MUST NOT be considered
digest could not be verified due to an unsupported scheme. successful with this ZONEMD RR and it SHOULD report that the
RR's digest could not be verified due to an unsupported
scheme.
C. The Hash Algorithm field MUST be checked. If the verifier C. The Hash Algorithm field MUST be checked. If the verifier
does not support the given hash algorithm, it SHOULD report does not support the given hash algorithm, verification MUST
that the RR's digest could not be verified due to an NOT be considered successful with this ZONEMD RR and it
unsupported algorithm. SHOULD report that the RR's digest could not be verified due
to an unsupported algorithm.
D. The zone digest is computed over the zone data as described D. The Digest field size MUST be checked. If the size of the
given Digest field is smaller than 12 octets, or if the size
is not equal to the size expected for the corresponding Hash
Algorithm, verification MUST NOT be considered successful
with this ZONEMD RR and the verifier SHOULD report that the
RR's digest could not be verified to to an incorrect digest
length.
E. The zone digest is computed over the zone data as described
in Section 3.3, using the Scheme and Hash Algorithm for the in Section 3.3, using the Scheme and Hash Algorithm for the
current ZONEMD RR. current ZONEMD RR.
E. The computed digest is compared to the received digest. If F. The computed digest is compared to the received digest. If
the two digest values match, verification is considered the two digest values match, verification is considered
successful. Otherwise, verification MUST NOT be considered successful. Otherwise, verification MUST NOT be considered
successful for this ZONEMD RR. successful for this ZONEMD RR.
5. IANA Considerations 5. IANA Considerations
5.1. ZONEMD RRtype 5.1. ZONEMD RRtype
This document defines a new DNS RR type, ZONEMD, whose value 63 has This document defines a new DNS RR type, ZONEMD, whose value 63 has
been allocated by IANA from the "Resource Record (RR) TYPEs" been allocated by IANA from the "Resource Record (RR) TYPEs"
subregistry of the "Domain Name System (DNS) Parameters" registry: subregistry of the "Domain Name System (DNS) Parameters" registry:
Type: ZONEMD Type: ZONEMD
Value: 63 Value: 63
Meaning: Message Digest Over Zone Data Meaning: Message Digest Over Zone Data
Reference: This document Reference: [this document]
5.2. ZONEMD Scheme 5.2. ZONEMD Scheme
This document asks IANA to create a new "ZONEMD Scheme" registry with IANA is requested to create a new registry on the "Domain Name System
initial contents as follows: (DNS) Parameters" web page as follows:
+---------+--------------------+----------+-----------+-------------+ Registry Name: ZONEMD Schemes
| Value | Description | Mnemonic | Status | Reference |
+---------+--------------------+----------+-----------+-------------+
| 0 | Reserved | RESERVED | N/A | N/A |
| 1 | Simple ZONEMD | SIMPLE | Mandatory | This |
| | collation | | | document |
| 240-254 | Private Use | N/A | N/A | [RFC8126] |
+---------+--------------------+----------+-----------+-------------+
Table 1: ZONEMD Scheme Registry Registration Procedure: Specification Required
The IANA policy for assigning new values to the ZONEMD Scheme Reference: [this document]
registry shall be Specification Required, as described in [RFC8126].
+---------+---------------+----------+------------------+-----------+
| Value | Description | Mnemonic | Implementation | Reference |
| | | | Requirement | |
+---------+---------------+----------+------------------+-----------+
| 0 | Reserved | | | |
| 1 | Simple ZONEMD | SIMPLE | MUST | [this |
| | collation | | | document] |
| 2-239 | Unassigned | | | |
| 240-254 | Private Use | N/A | N/A | [this |
| | | | | document] |
| 255 | Reserved | | | |
+---------+---------------+----------+------------------+-----------+
Table 1: ZONEMD Scheme Registry
5.3. ZONEMD Hash Algorithm 5.3. ZONEMD Hash Algorithm
This document asks IANA to create a new "ZONEMD Hash Algorithm" IANA is requested to create a new registry on the "Domain Name System
registry with initial contents as follows: (DNS) Parameters" web page as follows:
+---------+----------------------+----------+-----------+-----------+ Registry Name: ZONEMD Hash Algorithms
| Value | Description | Mnemonic | Status | Reference | Registration Procedure: Specification Required
+---------+----------------------+----------+-----------+-----------+
| 0 | Reserved | RESERVED | N/A | N/A | Reference: [this document]
| 1 | The SHA-384 hash | SHA384 | Mandatory | [RFC6234] |
| | algorithm | | | | +---------+-------------+----------+-------------------+------------+
| 240-254 | Private Use | N/A | N/A | [RFC8126] | | Value | Description | Mnemonic | Implementation | Reference |
+---------+----------------------+----------+-----------+-----------+ | | | | Requirement | |
+---------+-------------+----------+-------------------+------------+
| 0 | Reserved | | | |
| 1 | SHA-384 | SHA384 | MUST | [this |
| | | | | document] |
| 2 | SHA-512 | SHA512 | SHOULD | [this |
| | | | | document] |
| 3-239 | Unassigned | | | |
| 240-254 | Private Use | N/A | N/A | [his |
| | | | | document] |
| 255 | Reserved | | | |
+---------+-------------+----------+-------------------+------------+
Table 2: ZONEMD Hash Algorithm Registry Table 2: ZONEMD Hash Algorithm Registry
The IANA policy for assigning new values to the ZONEMD Hash Algorithm The IANA policy for assigning new values to the ZONEMD Hash Algorithm
registry shall be Specification Required, as described in [RFC8126]. registry shall be Specification Required.
6. Security Considerations 6. Security Considerations
6.1. Attacks Against the Zone Digest 6.1. Attacks Against the Zone Digest
The zone digest allows the receiver to verify that the zone contents The zone digest allows the recipient of a zone to verify its
haven't been modified since the zone was generated/published. integrity. In conjunction with DNSSEC, the recipient can
Verification is strongest when the zone is also signed with DNSSEC. authenticate that it is as published by the zone originator.
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.
The attacker might perform a downgrade attack to an unsigned zone. The attacker might perform a downgrade attack to an unsigned zone.
This is why Section 4 talks about determining whether or not to This is why Section 4 talks about determining whether or not to
expect DNSSEC signatures for the zone in step 1. expect DNSSEC signatures for the zone in step 1.
The attacker might perform a downgrade attack by removing one or more The attacker might perform a downgrade attack by removing one or more
ZONEMD records. Such a removal is detectable only with DNSSEC ZONEMD records. Such a removal is detectable only with DNSSEC
validation and is why Section 4 talks about checking denial-of- validation and is why Section 4 talks about checking denial-of-
existence proofs in step 2 and signature validation in step 3. existence proofs in step 2 and signature validation in step 3.
The attacker might alter the Scheme, Hash Algorithm, or Digest fields The attacker might alter the Scheme, Hash Algorithm, or Digest fields
of the ZONEMD record. Such modifications are detectable only with of the ZONEMD record. Such modifications are detectable only with
DNSSEC validation. DNSSEC validation.
6.2. Attacks Utilizing ZONEMD Queries 6.2. DNSSESC Timing Considerations
As with all DNSSEC signatures, the ability to perform signature
validation of a ZONEMD record is limited in time. If the DS
record(s) or trust anchors for the zone to be verified are no longer
available, the recipient cannot validate the ZONEMD RRSet. This
could happen even if the ZONEMD signature is still current (not
expired), since the zone's DS record(s) may have been withdrawn
following a KSK rollover.
For zones where it may be important to validate a ZONEMD RRSet
through its entire signature validity period, the zone operator
should ensure that KSK rollover timing takes this into consideration.
6.3. Attacks Utilizing ZONEMD Queries
Nothing in this specification prevents clients from making, and Nothing in this specification prevents clients from making, and
servers from responding to, ZONEMD queries. Servers SHOULD NOT servers from responding to, ZONEMD queries. Servers SHOULD NOT
calculate zone digests dynamically (for each query) as this can be calculate zone digests dynamically (for each query) as this can be
used as a CPU resource exhaustion attack. used as a CPU resource exhaustion attack.
One might consider how well ZONEMD responses could be used in a ZONEMD responses could be used in a distributed denial-of-service
distributed denial-of-service amplification attack. The ZONEMD RR is amplification attack. The ZONEMD RR is moderately sized, much like
moderately sized, much like the DS RR. A single ZONEMD RR the DS RR. A single ZONEMD RR contributes approximately 40 to 65
contributes approximately 40 to 65 octets to a DNS response, for octets to a DNS response, for digest types defined herein. Other RR
currently defined digest types. Certainly other RR types, such as types, such as DNSKEY, can result in larger amplification effects.
DNSKEY, can result in larger amplification effects.
6.3. Resilience and Fragility 6.4. Resilience and Fragility
ZONEMD can be used to detect incomplete or corrupted zone data prior ZONEMD is used to detect incomplete or corrupted zone data prior to
to its use, thereby increasing resilience, but also introducing some its use, thereby increasing resilience by not using corrupt data, but
fragility. Publishers and consumers of zones containing ZONEMD also introduces some denial-of-service fragility by making good data
records should be aware of these tradeoffs. While the intention is in a zone unavailable if some other data is missing or corrupt.
to secure the zone data, misconfigurations or implementation bugs are Publishers and consumers of zones containing ZONEMD records should be
generally indistinguishable from intentional tampering, and could aware of these tradeoffs. While the intention is to secure the zone
lead to service failures when verification is performed data, misconfigurations or implementation bugs are generally
automatically. indistinguishable from intentional tampering, and could lead to
service failures when verification is performed automatically.
Zone publishers may want to deploy ZONEMD gradually, perhaps by Zone publishers may want to deploy ZONEMD gradually, perhaps by
utilizing one of the private use hash algorithms listed in utilizing one of the private use hash algorithms listed in
Section 5.3. Similarly, recipients may want to initially configure Section 5.3. Similarly, recipients may want to initially configure
verification failures only as a warning, and later as an error after verification failures only as a warning, and later as an error after
gaining experience and confidence with the feature. gaining experience and confidence with the feature.
7. Performance Considerations 7. Performance Considerations
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 ZONEMD RRs in performance requirements and implications of including ZONEMD RRs in
a zone. a zone.
7.1. SIMPLE SHA384 7.1. SIMPLE SHA384
As mentioned previously, the SIMPLE scheme may not be appropriate for As mentioned previously, the SIMPLE scheme may be impractical for use
use in zones that are either large or highly dynamic. Zone in zones that are either large or highly dynamic. Zone publishers
publishers should carefully consider the use of ZONEMD in such zones, should carefully consider the use of ZONEMD in such zones, since it
since it might cause consumers of zone data (e.g., secondary name might cause consumers of zone data (e.g., secondary name servers) to
servers) to expend resources on digest calculation. Furthermore, for expend resources on digest calculation. For such use cases, it is
such use cases, it is recommended that ZONEMD only be used when recommended that ZONEMD only be used when digest calculation time is
digest calculation time is significantly less than propagation times significantly less than propagation times and update intervals.
and update intervals.
The authors' implementation (Section 10.1) includes an option to The authors' implementation (Appendix B.1) includes an option to
record and report CPU usage of its operation. The software was used record and report CPU usage of its operation. The software was used
to generate digests for more than 800 TLD zones available from to generate digests for more than 800 TLD zones available from
[CZDS]. The table below summarizes the the results for the SIMPLE [CZDS]. The table below summarizes the results for the SIMPLE scheme
scheme and SHA384 hash algorithm grouped by zone size. The Rate and SHA384 hash algorithm grouped by zone size. The Rate column is
column is the mean amount of time per RR to calculate the digest, the mean amount of time per RR to calculate the digest, running on
running on commodity hardware at the time of this writing. commodity hardware in early 2020.
+---------------------+----------------+ +---------------------+----------------+
| Zone Size (RRs) | Rate (msec/RR) | | Zone Size (RRs) | Rate (msec/RR) |
+---------------------+----------------+ +---------------------+----------------+
| 10 - 99 | 0.00683 | | 10 - 99 | 0.00683 |
| 100 - 999 | 0.00551 | | 100 - 999 | 0.00551 |
| 1000 - 9999 | 0.00505 | | 1000 - 9999 | 0.00505 |
| 10000 - 99999 | 0.00602 | | 10000 - 99999 | 0.00602 |
| 100000 - 999999 | 0.00845 | | 100000 - 999999 | 0.00845 |
| 1000000 - 9999999 | 0.0108 | | 1000000 - 9999999 | 0.0108 |
skipping to change at page 17, line 36 skipping to change at page 18, line 14
8. Privacy Considerations 8. Privacy Considerations
This specification has no impact on user privacy. This specification has no impact on user privacy.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank David Blacka, Scott Hollenbeck, and Rick The authors wish to thank David Blacka, Scott Hollenbeck, and Rick
Wilhelm for providing feedback on early drafts of this document. Wilhelm for providing feedback on early drafts of this document.
Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans, Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan Donald Eastlake, Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul
Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski, Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt
Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed Lewis,
Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer, Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury, Willem
Tim Wicinksi, Wouter Wijngarrds, Paul Wouters, and other members of Toorop, Florian Weimer, Tim Wicinksi, Wouter Wijngarrds, Paul
the dnsop working group for their input. Wouters, and other members of the dnsop working group for their
input.
10. Implementation Status
10.1. Authors' Implementation
The authors have an open source implementation in C, using the ldns
library [ldns-zone-digest]. This implementation is able to perform
the following functions:
o Read an input zone and output a zone with the ZONEMD placeholder.
o Compute zone digest over signed zone and update the ZONEMD record.
o Re-compute DNSSEC signature over the ZONEMD record.
o Verify the zone digest from an input zone.
This implementation does not:
o Perform DNSSEC validation of the ZONEMD record during
verification.
10.2. Shane Kerr's Implementation
Shane Kerr wrote an implementation of this specification during the
IETF 102 hackathon [ZoneDigestHackathon]. This implementation is in
Python and is able to perform the following functions:
o Read an input zone and output a zone with ZONEMD record.
o Verify the zone digest from an input zone.
o Output the ZONEMD record in its defined presentation format.
This implementation does not:
o Re-compute DNSSEC signature over the ZONEMD record.
o Perform DNSSEC validation of the ZONEMD record.
10.3. NIC Chile Labs Implementation
NIC Chile Labs wrote an implementation of this specification as part
of "dns-tools" suite [DnsTools], which besides digesting, can also
sign and verify zones. This implementation is in Go and is able to
perform the following functions:
o Compute zone digest over signed zone and update the ZONEMD record.
o Verify the zone digest from an input zone.
o Perform DNSSEC validation of the ZONEMD record during
verification.
o Re-compute DNSSEC signature over the ZONEMD record.
11. Change Log 10. Change Log
RFC Editor: Please remove this section. RFC Editor: Please remove this section before publication.
This section lists substantial changes to the document as it is being This section lists substantial changes to the document as it is being
worked on. worked on.
From -00 to -01: From -00 to -01:
o Removed requirement to sort by RR CLASS. o Removed requirement to sort by RR CLASS.
o Added Kumari and Hardaker as coauthors. o Added Kumari and Hardaker as coauthors.
skipping to change at page 23, line 18 skipping to change at page 22, line 33
hash values. hash values.
From -04 to -05: From -04 to -05:
o Clarifications about non-apex and multiple ZONEMD RRs. o Clarifications about non-apex and multiple ZONEMD RRs.
o Clarifications about benchmark results. o Clarifications about benchmark results.
o Don't compute ZONEMD on-the-fly. o Don't compute ZONEMD on-the-fly.
o Specifciation Required for updates to ZONEMD protocol registries. o Specification Required for updates to ZONEMD protocol registries.
o Other rewording based on WGLC feedback. o Other rewording based on WGLC feedback.
o Updated RFC numbers for some references. o Updated RFC numbers for some references.
o Use documentation IP addresses instead of loopback. o Use documentation IP addresses instead of loopback.
o Updated examples in the appendix. o Updated examples in the appendix.
From -05 to -06: From -05 to -06:
skipping to change at page 24, line 10 skipping to change at page 23, line 26
o Moved subsection ("Order of RRSets Having the Same Owner Name") o Moved subsection ("Order of RRSets Having the Same Owner Name")
with single sentence paragraph up into parent section. with single sentence paragraph up into parent section.
From -08 to -09: From -08 to -09:
o Moved format, ordering, inclusion/exclusion into a sub section o Moved format, ordering, inclusion/exclusion into a sub section
specific to the SIMPLE scheme. specific to the SIMPLE scheme.
o Further clarified rules about multiple ZONEMD RRs (AD comments). o Further clarified rules about multiple ZONEMD RRs (AD comments).
o Reworeded rules about processing of duplicate zone RRs (AD o Reworded rules about processing of duplicate zone RRs (AD
comments). comments).
o Removed sentence about optional zeroing of digest prior to o Removed sentence about optional zeroing of digest prior to
calculation (AD comments). calculation (AD comments).
o Other minor changes (AD comments). o Other minor changes (AD comments).
12. References From -09 to -10:
12.1. Normative References o Add clarification and reference to on-disk modification /
corruption of zone files.
o Added concerns that timing of KSK rollovers could affect
validation of ZONEMD record.
o Addressed SECDIR review and accepted most proposed edits.
o From SECDIR review, require minimum digest length of 12 octets.
o From SECDIR review, add SHA512 has hash algorithm 2.
o From SECDIR review, say that ZONEMD RRs MAY be ignored by local
policy.
o Moved Implementation Status to an appendix with the intention to
retain it in RFC.
o In registry tables, changed Status column to Implementation
Requirement.
11. References
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 25, line 5 skipping to change at page 24, line 39
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 11.2. Informative References
[CZDS] Internet Corporation for Assigned Names and Numbers, [CZDS] Internet Corporation for Assigned Names and Numbers,
"Centralized Zone Data Service", October 2018, "Centralized Zone Data Service", October 2018,
<https://czds.icann.org/>. <https://czds.icann.org/>.
[disk-full-failure]
DENIC, "Background of the Partial Failure of the Name
Service for .de Domains", May 2010,
<https://web.archive.org/web/20100618032705/
https://www.denic.de/en/denic-in-dialogue/news/2733.html>.
[DnsTools] [DnsTools]
NIC Chile Labs, "DNS tools for zone signature (file, NIC Chile Labs, "DNS tools for zone signature (file,
pkcs11-hsm) and validation, and zone digest (ZONEMD)", pkcs11-hsm) and validation, and zone digest (ZONEMD)",
April 2020, <https://github.com/niclabs/dns-tools>. April 2020, <https://github.com/niclabs/dns-tools>.
[InterNIC] [InterNIC]
ICANN, "InterNIC FTP site", May 2018, ICANN, "InterNIC FTP site", May 2018,
<ftp://ftp.internic.net/domain/>. <ftp://ftp.internic.net/domain/>.
[ldns-zone-digest] [ldns-zone-digest]
skipping to change at page 28, line 33 skipping to change at page 28, line 33
non-apex 900 IN ZONEMD 2018031900 1 1 ( non-apex 900 IN ZONEMD 2018031900 1 1 (
616c6c6f77656420 616c6c6f77656420
6275742069676e6f 6275742069676e6f
7265642e20616c6c 7265642e20616c6c
6f77656420627574 6f77656420627574
2069676e6f726564 2069676e6f726564
2e20616c6c6f7765 ) 2e20616c6c6f7765 )
A.3. EXAMPLE Zone with multiple digests A.3. EXAMPLE Zone with multiple digests
Here, the EXAMPLE zone contains multiple ZONEMD records. Since only Here, the EXAMPLE zone contains multiple ZONEMD records. It has both
one Scheme (SIMPLE) and one Hash Algorithm (SHA384) is defined at SHA384 and SHA512 digests using the SIMPLE scheme. It also includes
this time, this example utilizes additional ZONEMD records with ZONEMD records with Scheme and Hash Algorithm values in the private
Scheme and Hash Algorithm values in the private range (240-254). range (240-254). These additional private-range digests are not
These additional private-range digests are not verifiable. verifiable.
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 (
08cfa1115c7b948c
4163a901270395ea
226a930cd2cbcf2f
a9a5e6eb85f37c8a
4e114d884e66f176
eab121cb02db7d65
2e0cc4827e7a3204
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
skipping to change at page 32, line 27 skipping to change at page 32, line 36
;; Query time: 66 msec ;; Query time: 66 msec
;; SERVER: 192.0.32.132#53(192.0.32.132) ;; SERVER: 192.0.32.132#53(192.0.32.132)
;; WHEN: Sun Oct 21 20:39:28 UTC 2018 ;; WHEN: Sun Oct 21 20:39:28 UTC 2018
;; XFR size: 34 records (messages 1, bytes 3941) ;; XFR size: 34 records (messages 1, bytes 3941)
uri.arpa. 3600 IN ZONEMD 2018100702 1 1 ( uri.arpa. 3600 IN ZONEMD 2018100702 1 1 (
1291b78ddf7669b1a39d014d87626b709b55774c5d7d58fa 1291b78ddf7669b1a39d014d87626b709b55774c5d7d58fa
dc556439889a10eaf6f11d615900a4f996bd46279514e473 ) dc556439889a10eaf6f11d615900a4f996bd46279514e473 )
A.5. The ROOT-SERVERS.NET Zone A.5. The ROOT-SERVERS.NET Zone
The ROOT-SERVERS.NET zone retreived 2018-10-21. The ROOT-SERVERS.NET zone retrieved 2018-10-21.
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.
skipping to change at page 34, line 5 skipping to change at page 34, line 5
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 )
Appendix B. Implementation Status
RFC Editor: Please retain this section upon publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
B.1. Authors' Implementation
The authors have an open source implementation in C, using the ldns
library [ldns-zone-digest]. This implementation is able to perform
the following functions:
o Read an input zone and output a zone with the ZONEMD placeholder.
o Compute zone digest over signed zone and update the ZONEMD record.
o Re-compute DNSSEC signature over the ZONEMD record.
o Verify the zone digest from an input zone.
This implementation does not:
o Perform DNSSEC validation of the ZONEMD record during
verification.
B.2. Shane Kerr's Implementation
Shane Kerr wrote an implementation of this specification during the
IETF 102 hackathon [ZoneDigestHackathon]. This implementation is in
Python and is able to perform the following functions:
o Read an input zone and output a zone with ZONEMD record.
o Verify the zone digest from an input zone.
o Output the ZONEMD record in its defined presentation format.
This implementation does not:
o Re-compute DNSSEC signature over the ZONEMD record.
o Perform DNSSEC validation of the ZONEMD record.
B.3. NIC Chile Labs Implementation
NIC Chile Labs wrote an implementation of this specification as part
of "dns-tools" suite [DnsTools], which besides digesting, can also
sign and verify zones. This implementation is in Go and is able to
perform the following functions:
o Compute zone digest over signed zone and update the ZONEMD record.
o Verify the zone digest from an input zone.
o Perform DNSSEC validation of the ZONEMD record during
verification.
o Re-compute DNSSEC signature over the ZONEMD record.
Authors' Addresses Authors' Addresses
Duane Wessels Duane Wessels
Verisign Verisign
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: dwessels@verisign.com Email: dwessels@verisign.com
URI: http://verisign.com URI: https://verisign.com
Piet Barber Piet Barber
Verisign Verisign
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: pbarber@verisign.com Email: pbarber@verisign.com
URI: http://verisign.com URI: https://verisign.com
Matt Weinberg Matt Weinberg
Amazon Amazon
Email: matweinb@amazon.com Email: matweinb@amazon.com
URI: http://amazon.com URI: https://amazon.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
Email: warren@kumari.net Email: warren@kumari.net
Wes Hardaker Wes Hardaker
USC/ISI USC/ISI
 End of changes. 107 change blocks. 
391 lines changed or deleted 471 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/