draft-ietf-dnsop-dns-zone-digest-03.txt   draft-ietf-dnsop-dns-zone-digest-04.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 M. Weinberg Intended status: Standards Track M. Weinberg
Expires: June 5, 2020 Verisign Expires: August 24, 2020 Verisign
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
December 3, 2019 February 21, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-03 draft-ietf-dnsop-dns-zone-digest-04
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 can be used to provide a cryptographic message digest over DNS zone
data. The ZONEMD Resource Record conveys the digest data in the zone data. The ZONEMD Resource Record conveys the digest data in the zone
itself. When a zone publisher includes an ZONEMD record, recipients itself. When a zone publisher includes an ZONEMD record, recipients
can verify the zone contents for accuracy and completeness. This can verify the zone contents for accuracy and completeness. This
provides assurance that received zone data matches published data, provides assurance that received zone data matches published data,
regardless of how the zone data has been transmitted and received. regardless of how the zone data has been transmitted and received.
ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects
individual RRSets (DNS data with fine granularity), ZONEMD protects individual RRSets (DNS data with fine granularity), ZONEMD protects a
protects a zone's data as a whole, whether consumed by authoritative zone's data as a whole, whether consumed by authoritative name
name servers, recursive name servers, or any other applications. servers, recursive name servers, or any other applications.
As specified at this time, ZONEMD is not designed for use in large, As specified at this time, ZONEMD is not designed for use in large,
dynamic zones due to the time and resources required for digest dynamic zones due to the time and resources required for digest
calculation. The ZONEMD record described in this document includes a calculation. The ZONEMD record described in this document is
field intended to enable future work to support large, dynamic zones. designed so that new digest schemes may be developed in the future to
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 June 5, 2020.
This Internet-Draft will expire on August 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 5 1.2. Design Overview . . . . . . . . . . . . . . . . . . . . . 6
1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Providers, Secondaries, and Anycast . . . . . . . . . 6 1.3.2. Providers, Secondaries, and Anycast . . . . . . . . . 6
1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 6 1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 7
1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7
1.3.5. General Purpose Comparison Check . . . . . . . . . . 7 1.3.5. General Purpose Comparison Check . . . . . . . . . . 7
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7
2.1. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8
2.1.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
2.1.2. The Digest Type Field . . . . . . . . . . . . . . . . 8 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
2.1.3. The Parameter Field . . . . . . . . . . . . . . . . . 8 2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9
2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9
2.2. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
2.3. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 9 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9
3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 9 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10
3.1. Canonical Format and Ordering . . . . . . . . . . . . . . 9 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10
3.1.1. Order of RRSets Having the Same Owner Name . . . . . 10 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
3.1.2. Duplicate RRs . . . . . . . . . . . . . . . . . . . . 10 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10
3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.3. Canonical Format and Ordering . . . . . . . . . . . . . . 11
3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.3.1. Order of RRSets Having the Same Owner Name . . . . . 11
3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11 3.4. Inclusion/Exclusion Rules . . . . . . . . . . . . . . . . 11
3.4.1. SHA384-SIMPLE Calculation . . . . . . . . . . . . . . 11 3.5. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
3.4.2. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 3.5.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12
3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 3.6. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13 4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 13 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
5.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14
6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 14 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 6.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 16
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 7. Performance Considerations . . . . . . . . . . . . . . . . . 16
9.1. Authors' Implementation . . . . . . . . . . . . . . . . . 15 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 15 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 18
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 22 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 23
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 25
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 27 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 26
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 27
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 ([RFC7719]). Zones are often records (RRs) sharing a common origin ([RFC7719]). Zones are often
stored as files on disk in the so-called master file format stored as files on disk in the so-called master file format
[RFC1034]. Zones are generally distributed among name servers using [RFC1034]. Zones are generally distributed among name servers using
the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can
also be distributed outside of the DNS, with such protocols as FTP, also be distributed outside of the DNS, with such protocols as FTP,
HTTP, rsync, and even via email. Currently there is no standard way HTTP, rsync, and even via email. Currently there is no standard way
skipping to change at page 6, line 9 skipping to change at page 6, line 19
calculated at the time of zone publication. Ideally the zone is calculated at the time of zone publication. Ideally the zone is
signed with DNSSEC to guarantee that any modifications of the digest signed with DNSSEC to guarantee that any modifications of the digest
can be detected. The procedures for digest calculation and DNSSEC can be detected. The procedures for digest calculation and DNSSEC
signing are similar (i.e., both require the same ordering of RRs) and signing are similar (i.e., both require the same ordering of RRs) and
can be done in parallel. can be done in 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 are relatively
stable and have infrequent updates. As currently specified, the stable and have infrequent updates. As currently specified, the
digest is re-calculated over the entire zone content each time. This digest is re-calculated over the entire zone content each time. This
specification does not provide an efficient mechanism for incremental specification does not provide an efficient mechanism for incremental
updates of zone data. It does, however, include a field in the updates of zone data. It is, however, extensible so that future
ZONEMD record intended for future work to support incremental zone schemes to support incremental zone digest algorithms (e.g. using
digest algorithms (e.g. using Merkle trees). Merkle trees) can be accommodated.
It is expected that verification of a zone digest would be It is expected that verification of a zone digest would be
implemented in name server software. That is, a name server can implemented in name server software. That is, a name server can
verify the zone data it was given and refuse to serve a zone which verify the zone data it was given and refuse to serve a zone which
fails verification. For signed zones, the name server needs a trust fails verification. For signed zones, the name server needs a trust
anchor to perform DNSSEC validation. For signed non-root zones, the anchor to perform DNSSEC validation. For signed non-root zones, the
name server may need to send queries to validate a chain-of-trust. name server may need to send queries to validate a chain-of-trust.
Digest verification could also be performed externally. Digest verification could also be performed externally.
1.3. Use Cases 1.3. Use Cases
1.3.1. Root Zone 1.3.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 930 separate instances [RootServers] zone on the Internet, served by more than 1000 separate instances
at the time of this writing. Additionally, many organizations [RootServers] at the time of this writing. Additionally, many
configure their own name servers to serve the root zone locally. organizations configure their own name servers to serve the root zone
Reasons for doing so include privacy and reduced access time. locally. Reasons for doing so include privacy and reduced access
[RFC7706] describes one, but not the only, way to do this. As the time. [RFC7706] describes one, but not the only, way to do this. As
root zone spreads beyond its traditional deployment boundaries, the the root zone spreads beyond its traditional deployment boundaries,
need for verification of the completeness of the zone contents the need for verification of the completeness of the zone contents
becomes increasingly important. becomes increasingly important.
1.3.2. Providers, Secondaries, and Anycast 1.3.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 they may not have anticipated the complexity of modern DNS service
provisioning which can include multiple third-party providers and provisioning which can include multiple third-party providers and
hundreds of anycast instances. Instead of a simple primary-to- hundreds of anycast instances. Instead of a simple primary-to-
secondary zone distribution system, today it is possible to have secondary zone distribution system, today it is possible to have
skipping to change at page 7, line 38 skipping to change at page 7, line 48
"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.
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, Digest Type, the resource record consists of four fields: Serial, Scheme, Hash
Parameter, and Digest. Algorithm, and Digest.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility
[RFC7696] and rollovers. Each ZONEMD RR must specify a unique Scheme
and Hash Algorithm tuple. It is 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 Algorithm.
2.1. Non-apex ZONEMD Records
This specification utilizes ZONEMD RRs located at the zone apex. This specification utilizes ZONEMD RRs located at the zone apex.
Non-apex ZONEMD RRs are not forbidden, but have no meaning in this Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
specification. specification. Non-apex ZONEMD RRs MUST NOT be used for
verification. Non-apex ZONEMD RRSets are treated like any other
RRSet (which is to say they are included) during digest calculation.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility Unless explicitly stated otherwise, "ZONEMD" always refers to apex
[RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest records throughout this document.
Type and Parameter tuple. It is RECOMMENDED that a zone include only
one ZONEMD RR, unless the zone publisher is in the process of
transitioning to a new Digest Type.
2.1. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial | | Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Parameter | | | Scheme |Hash Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Digest | | Digest |
/ / / /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.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 order. It
is equal to the serial number from the zone's SOA record ([RFC1035] is equal to the serial number from the zone's SOA record ([RFC1035]
section 3.3.13) for which the zone digest was generated. section 3.3.13) for which the zone digest was generated.
The zone's serial number is included here in order to make DNS The zone's serial number is included here in order to make DNS
response messages of type ZONEMD meaningful. Without the serial response messages of type ZONEMD meaningful. Without the serial
number, a stand-alone ZONEMD digest has no association to any number, a stand-alone ZONEMD digest has no association to any
particular instance of a zone. particular instance of a zone.
2.1.2. The Digest Type Field 2.2.2. The Scheme Field
The Digest Type field is an 8-bit unsigned integer that identifies The Scheme field is an 8-bit unsigned integer that identifies the
the algorithm used to construct the digest. methods by which data is collated and presented as input to the
hashing function.
At the time of this writing, SHA384-SIMPLE, with value 1, is the only At the time of this writing, SIMPLE, with value 1, is the only
standardized Digest Type defined for ZONEMD records. The Digest Type standardized Scheme defined for ZONEMD records. The Scheme registry
registry is further described in Section 5. is further described in Section 5.
Digest Type values 240-254 are allocated for Private Use as described Scheme values 240-254 are allocated for Private Use as described in
in [RFC8126]. [RFC8126].
2.1.3. The Parameter Field 2.2.3. The Hash Algorithm Field
The Parameter field is an 8-bit unsigned integer whose meaning The Hash Algorithm field is an 8-bit unsigned integer that identifies
depends on the Digest Type in use. For SHA384-SIMPLE, the Parameter the cryptographic hash algorithm used to construct the digest.
field plays no role in digest calculation or verification.
2.1.4. The Digest Field At the time of this writing, SHA384, with value 1, is the only
standardized Hash Algorithm defined for ZONEMD records. The Hash
Algorithm registry is further described in Section 5.
Hash Algorithm values 240-254 are allocated for Private Use as
described in [RFC8126].
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 message digest. The Digest field MUST NOT be empty. Section 3 the output of the hash algorithm. The Digest field must not be
describes how to calculate the digest for a zone. Section 4 empty. Section 3 describes how to calculate the digest for a zone.
describes how to use the digest to verify the contents of a zone. Section 4 describes how to use the digest to verify the contents of a
zone.
2.2. 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 MUST be represented as an unsigned decimal integer. The Serial field is represented as an unsigned decimal integer.
The Digest Type field MUST be represented as an unsigned decimal The Scheme field is represented as an unsigned decimal integer.
integer.
The Parameter field MUST be represented as an unsigned decimal The Hash Algorithm field is represented as an unsigned decimal
integer. integer.
The Digest MUST be 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.3. ZONEMD Example 2.4. ZONEMD Example
The following example shows a ZONEMD RR. The following example shows a ZONEMD RR.
example.com. 86400 IN ZONEMD 2018031500 1 0 ( example.com. 86400 IN ZONEMD 2018031500 1 1 (
FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
3. Calculating the Digest 3. Calculating the Digest
3.1. Canonical Format and Ordering 3.1. Add ZONEMD Placeholder
Calculation of the zone digest REQUIRES RRs to be processed in a
consistent format and ordering. Correct ordering depends on (1)
ordering of owner names, (2) ordering of RRSets with the same owner
name, and (3) ordering of RRs within an RRSet.
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.
3.1.1. Order of RRSets Having the Same Owner Name
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.1.2. Duplicate RRs
As stated in Section 5 of [RFC2181], it is meaningless for a zone to
have multiple RRs with equal owner name, class, type, and RDATA. In
the interest of consistency and interoperability, such duplicate RRs
MUST NOT be included in the calculation of a zone digest.
3.2. Add ZONEMD Placeholder
In preparation for calculating the zone digest, any existing ZONEMD In preparation for calculating the zone digest, any existing ZONEMD
records at the zone apex MUST first be deleted. records 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,
a placeholder ZONEMD record MUST be added to the zone apex. This a placeholder ZONEMD record is added to the zone apex. This serves
serves two purposes: (1) it allows the digest to cover the Serial, two purposes: (1) it allows the digest to cover the Serial, Scheme,
Digest Type, and Parameter field values, and (2) ensures that and Hash Algorithm fields, and (2) ensures that appropriate denial-
appropriate denial-of-existence (NSEC, NSEC3) records are created if of-existence (NSEC, NSEC3) records are created if the zone is signed
the zone is signed with DNSSEC. with DNSSEC.
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 MUST be set to the In the placeholder record, the Serial field is set to the current SOA
current SOA Serial. The Digest Type field MUST be set to the value Serial. The Scheme field is set to the value for the chosen
for the chosen digest algorithm. The Parameter field is set to a collation scheme. The Hash Algorithm field is set to the value for
value whose meaning depends on the Digest Type. The Digest field the chosen hash algorithm. The Digest field is set to all zeroes and
MUST be set to all zeroes and of length appropriate for the chosen of length appropriate for the chosen hash algorithm.
digest algorithm.
If multiple digests are to be published in the zone, e.g., during an If multiple digests are to be published in the zone, e.g., during an
algorithm rollover, there MUST be one placeholder record for each algorithm rollover, a placeholder record is added for each Scheme and
Digest Type. Hash Algorithm.
3.3. 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. Note that when the digest calculation is complete, and
the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet
MUST be recalculated and updated as well. Therefore, the signer is MUST be recalculated and updated as well. Therefore, the signer is
not required to calculate a signature over the placeholder record at not required to calculate a signature over the placeholder record at
this step in the process, but it is harmless to do so. this step in the process, but it is harmless to do so.
3.4. Calculate the Digest 3.3. Canonical Format and Ordering
The digest calculation details vary depending upon the Digest Type.
This document describes digest calculation for SHA384-SIMPLE only.
Digest calculation for additional types may be defined in future
updates to this document.
3.4.1. SHA384-SIMPLE Calculation
For SHA384-SIMPLE, the digest is calculated over the zone as a whole.
This means that a change to a single RR in the zone requires
iterating over all RRs in the zone to recalculate the digest.
SHA384-SIMPLE is good for zones that are small and/or stable, but
probably not good for zones that are large and/or dynamic.
The Parameter field is not used in the calculation of SHA384-SIMPLE
zone digests. The Parameter field SHOULD be set to zero in
SHA384-SIMPLE placeholder records.
The zone digest is calculated by concatenating the canonical on-the- Calculation of a zone digest REQUIRES RRs to be processed in a
wire form (without name compression) of all RRs in the zone, in the consistent format and ordering. Correct ordering depends on (1)
order described above, subject to the inclusion/exclusion rules ordering of owner names, (2) ordering of RRSets with the same owner
described below, and then applying the SHA384 digest algorithm name, and (3) ordering of RRs within an RRSet.
[RFC6605]:
digest = SHA384( RR(1) | RR(2) | RR(3) | ... ) 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.
where "|" denotes concatenation, and 3.3.1. Order of RRSets Having the Same Owner Name
RR(i) = owner | type | class | TTL | RDATA length | RDATA 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.4.2. Inclusion/Exclusion Rules 3.4. Inclusion/Exclusion Rules
When calculating the digest, the following inclusion/exclusion rules When iterating over records in the zone, the following inclusion/
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 Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be o Only one instance of duplicate RRs with equal owner, class, type
included. and RDATA SHALL be included ([RFC4034] Section 6.3).
o The placeholder ZONEMD RR(s) MUST be included. o The placeholder ZONEMD RR(s) MUST 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.5. Update ZONEMD RR 3.5. Scheme-Specific Processing
At this time, only the SIMPLE collation scheme is defined.
Additional schemes may be defined in future updates to this document.
3.5.1. The SIMPLE Scheme
For the SIMPLE scheme, the digest is calculated over the zone as a
whole. This means that a change to a single RR in the zone requires
iterating over all RRs in the zone to recalculate the digest. SIMPLE
is a good choice for zones that are small and/or stable, but probably
not good for zones that are large and/or dynamic.
A zone digest using the SIMPLE scheme is calculated by concatenating
the canonical on-the-wire form (without name compression) of all RRs
in the zone, in the order described in Section 3.3, subject to the
inclusion/exclusion rules described in Section 3.4, and then applying
the SHA-384 algorithm:
digest = hash( RR(1) | RR(2) | RR(3) | ... )
where "|" denotes concatenation, and
RR(i) = owner | type | class | TTL | RDATA length | RDATA
3.6. Update ZONEMD RR
Once a zone digest has been calculated, its value is then copied to Once a zone digest has been calculated, its value is then copied to
the Digest field of the placeholder ZONEMD record. Repeat for each the Digest field of the placeholder ZONEMD record. Repeat for each
digest if multiple digests are to be published. digest if multiple digests are to be published.
If the zone is signed with DNSSEC, the appropriate RRSIG records If the zone is signed with DNSSEC, the appropriate RRSIG records
covering the ZONEMD RRSet MUST then be added or updated. Because the covering the ZONEMD RRSet MUST then be added or updated. Because the
ZONEMD placeholder was added prior to signing, the zone will already ZONEMD placeholder was added prior to signing, the zone will already
have the appropriate denial-of-existence (NSEC, NSEC3) records. have the appropriate denial-of-existence (NSEC, NSEC3) records.
Some implementations of incremental DNSSEC signing might update the Some DNSSEC implementations (especially "online signing") might be
zone's serial number for each resigning. However, to preserve the designed such that the SOA serial number is updated whenever a new
calculated digest, generation of the ZONEMD signature at this time signature is made. To preserve the calculated digest, generation of
MUST NOT also result in a change of the SOA serial number. an ZONEMD signature must not also result in a change to the SOA
serial number. The ZONEMD RR and the matching SOA MUST be published
at the same time.
4. Verifying Zone Digest 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 can verify the zone by
calculating the digest as follows: calculating the digest as follows:
1. The verifier SHOULD first determine whether or not to expect 1. The verifier MUST first determine whether or not to expect
DNSSEC records in the zone. This can be done by examining DNSSEC records in the zone. This can be done by examining
locally configured trust anchors, or querying for (and locally configured trust anchors, or querying for (and
validating) DS RRs in the parent zone. For zones that are validating) DS RRs in the parent zone. For zones that are
provably insecure, digest validation continues at step 4 below. provably insecure, or if DNSSEC validation can not be performed,
digest validation continues 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 be done. If the
ZONEMD record does provably exist, but is not found in the zone, ZONEMD record does provably exist, but is not found in the zone,
digest verification MUST NOT be considered successful. digest 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. If the ZONEMD RRSet contains more than one RR with the same 4. If the ZONEMD RRSet contains more than one RR with the same
Digest Type and Parameter, digest verification MUST NOT be Scheme and Hash Algorithm, digest verification MUST NOT be
considered successful. considered successful.
5. The SOA Serial field MUST exactly match the ZONEMD Serial field. 5. The SOA Serial field MUST exactly match the ZONEMD Serial field.
If the fields to not match, digest verification MUST NOT be If the fields to not match, digest verification MUST NOT be
considered successful. considered successful.
6. The ZONEMD Digest Type field MUST be checked. If the verifier 6. The ZONEMD Hash Algorithm field MUST be checked. If the
does not support the given digest type, it SHOULD report that verifier does not support the given Hash Algorithm, it SHOULD
the zone digest could not be verified due to an unsupported report that the zone digest could not be verified due to an
algorithm. unsupported algorithm.
7. The received Digest Type and Digest values are copied to a 7. The received Digest value is copied to a temporary location.
temporary location. Repeat for each ZONEMD RR present.
8. The ZONEMD RR's RDATA is reset to the placeholder values 8. The ZONEMD RR's Digest field MUST be set to all zeroes. Repeat
described in Section 3.2. for each RR present in the apex ZONEMD RRSet, even for
unsupported Scheme and Hash Algorithm values.
9. The zone digest is computed over the zone data as described in 9. The zone digest is computed over the zone data as described in
Section 3.4. Section 3.5.
10. The calculated digest is compared to the received digest stored 10. The calculated digest is compared to the received digest stored
in the temporary location. If the two digest values match, in the temporary location. If the two digest values match,
verification is considered successful. Otherwise, verification verification is considered successful. Otherwise, verification
MUST NOT be considered successful. MUST NOT be considered successful.
11. The ZONEMD RR's RDATA is reset to the received Digest Type and 11. The ZONEMD RR's RDATA is reset to the received Digest stored in
Digest stored in the temporary location. Thus, any downstream the temporary location. Thus, any downstream clients can
clients can similarly verify the zone. similarly verify the zone.
4.1. Verifying Multiple Digests 4.1. Verifying Multiple Digests
If multiple digests are present in the zone, e.g., during an If multiple digests are present in the zone, e.g., during an
algorithm rollover, a match using any one of the recipient's algorithm rollover, a match using any one of the recipient's
supported Digest Type algorithms is sufficient to verify the zone. supported Hash Algorithm algorithms is sufficient to verify the zone.
Note that when multiple ZONEMD RRs are present in the zone, the
Digest field of each MUST be zeroed in step 8 above, even for
unsupported Scheme and Hash Algorithm values.
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 Digest Type 5.2. ZONEMD Scheme
This document asks IANA to create a new "ZONEMD Digest Types" This document asks IANA to create a new "ZONEMD Scheme" registry with
initial contents as follows:
+---------+--------------------+----------+-----------+-------------+
| 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
5.3. ZONEMD Hash Algorithm
This document asks IANA to create a new "ZONEMD Hash Algorithm"
registry with initial contents as follows: registry with initial contents as follows:
+---------+-----------------+---------------+-----------+-----------+ +---------+----------------------+----------+-----------+-----------+
| Value | Description | Mnemonic | Status | Reference | | Value | Description | Mnemonic | Status | Reference |
+---------+-----------------+---------------+-----------+-----------+ +---------+----------------------+----------+-----------+-----------+
| 1 | SHA384 simple | SHA384-SIMPLE | Mandatory | This | | 0 | Reserved | RESERVED | N/A | N/A |
| | zone digest | | | document | | 1 | The SHA-384 hash | SHA384 | Mandatory | [RFC6234] |
| 240-254 | Private Use | - | - | [RFC8126] | | | algorithm | | | |
+---------+-----------------+---------------+-----------+-----------+ | 240-254 | Private Use | N/A | N/A | [RFC8126] |
+---------+----------------------+----------+-----------+-----------+
Table 1: ZONEMD Digest Types Table 2: ZONEMD Hash Algorithm Registry
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 receiver to verify that the zone contents
haven't been modified since the zone was generated/published. haven't been modified since the zone was generated/published.
Verification is strongest when the zone is also signed with DNSSEC. Verification is strongest when the zone is also signed with DNSSEC.
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 RECOMMENDS that the verifier determine whether This is why Section 4 talks about determining whether or not to
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 the ZONEMD The attacker might perform a downgrade attack by removing one or more
record. This is why Section 4 REQUIRES that the verifier checks ZONEMD records. Such a removal is detectable only with DNSSEC
DNSSEC denial-of-existence proofs in step 2. validation and is why Section 4 talks about checking denial-of-
existence proofs in step 2 and signature validation in step 3.
The attacker might alter the Digest Type or Digest fields of the The attacker might alter the Scheme, Hash Algorithm, or Digest fields
ZONEMD record. Such modifications are detectable only with DNSSEC of the ZONEMD record. Such modifications are detectable only with
validation. DNSSEC validation.
6.2. Attacks Utilizing the Zone Digest 6.2. Attacks Utilizing the Zone Digest
Nothing in this specification prevents clients from making, and Nothing in this specification prevents clients from making, and
servers from responding to, ZONEMD queries. One might consider how servers from responding to, ZONEMD queries. One might consider how
well ZONEMD responses could be used in a distributed denial-of- well ZONEMD responses could be used in a distributed denial-of-
service amplification attack. service amplification attack.
The ZONEMD RR is moderately sized, much like the DS RR. A single The ZONEMD RR is moderately sized, much like the DS RR. A single
ZONEMD RR contributes approximately 40 to 65 octets to a DNS ZONEMD RR contributes approximately 40 to 65 octets to a DNS
response, for currently defined digest types. Certainly other query response, for currently defined digest types. Certainly other query
types result in larger amplification effects (i.e., DNSKEY). types result in larger amplification effects (i.e., DNSKEY).
7. Privacy Considerations 6.3. Resilience and Fragility
ZONEMD can be used to detect incomplete or corrupted zone data prior
to its use, thereby increasing resilience, but also introducing some
fragility. Publishers and consumers of zones containing ZONEMD
records should be aware of these tradeoffs. While the intention is
to secure the zone data, misconfigurations or implementation bugs are
generally indistinguishable from intentional tampering, and could
lead to service failures when verification is performed
automatically.
Zone publishers may want to deploy ZONEMD gradually, perhaps by
utilizing one of the private use hash algorithms listed in
Section 5.3. Similarly, recipients may want to initially configure
verification failures only as a warning, and later as an error after
gaining experience and confidence with the feature.
7. Performance Considerations
This section is provided to make zone publishers aware of the
performance requirements and implications of including ZONEMD RRs in
a zone.
7.1. SIMPLE SHA384
As mentioned previously, the SIMPLE scheme may not be appropriate for
use in zones that are either large or highly dynamic. Zone
publishers should carefully consider the use of ZONEMD in such zones,
since it might cause consumers of zone data (e.g., secondary name
servers) to expend resources on digest calculation. Furthermore, for
such use cases, it is recommended that ZONEMD only be used when
digest calculation time is significantly less than propagation times
and update intervals.
The authors' implementation (Section 10.1) includes an option to
record and report CPU usage of its operation. The software was used
to generate digests for more than 800 TLD zones available from
[CZDS]. The table below summarizes the the results for the SIMPLE
scheme and SHA384 hash algorithm grouped by zone size. The Rate
column is the mean amount of time per RR to calculate the digest,
running on commodity hardware at the time of this writing.
+---------------------+----------------+
| Zone Size (RRs) | Rate (msec/RR) |
+---------------------+----------------+
| 10 - 99 | 0.00683 |
| 100 - 999 | 0.00551 |
| 1000 - 9999 | 0.00505 |
| 10000 - 99999 | 0.00602 |
| 100000 - 999999 | 0.00845 |
| 1000000 - 9999999 | 0.0108 |
| 10000000 - 99999999 | 0.0148 |
+---------------------+----------------+
For example, based on the above table, it takes approximately 0.13
seconds to calculate a SIMPLE SHA384 digest for a zone with 22,000
RRs, and about 2.5 seconds for a zone with 300,000 RRs.
8. Privacy Considerations
This specification has no impacts on user privacy. This specification has no impacts on user privacy.
8. 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, Paul Hoffman, Evan Hunt, Shumon Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan
Huque, Tatuya Jinmei, Burt Kaliski, Shane Kerr, Matt Larson, John Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski,
Levine, Ed Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek, Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund
Ondrej Sury, Willem Toorop, Florian Weimer, Tim Wicinksi, Wouter Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer,
Wijngarrds, Paul Wouters, and other members of the dnsop working Tim Wicinksi, Wouter Wijngarrds, Paul Wouters, and other members of
group for their input. the dnsop working group for their input.
9. Implementation Status 10. Implementation Status
9.1. Authors' Implementation 10.1. Authors' Implementation
The authors have an open source implementation in C, using the ldns The authors have an open source implementation in C, using the ldns
library [ldns-zone-digest]. This implementation is able to perform library [ldns-zone-digest]. This implementation is able to perform
the following functions: the following functions:
o Read an input zone and output a zone with the ZONEMD placeholder. 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 Compute zone digest over signed zone and update the ZONEMD record.
o Re-compute DNSSEC signature over the ZONEMD record. o Re-compute DNSSEC signature over the ZONEMD record.
o Verify the zone digest from an input zone. o Verify the zone digest from an input zone.
This implementation does not: This implementation does not:
o Perform DNSSEC validation of the ZONEMD record during o Perform DNSSEC validation of the ZONEMD record during
verification. verification.
9.2. Shane Kerr's Implementation 10.2. Shane Kerr's Implementation
Shane Kerr wrote an implementation of this specification during the Shane Kerr wrote an implementation of this specification during the
IETF 102 hackathon [ZoneDigestHackathon]. This implementation is in IETF 102 hackathon [ZoneDigestHackathon]. This implementation is in
Python and is able to perform the following functions: Python and is able to perform the following functions:
o Read an input zone and a output zone with ZONEMD record. o Read an input zone and output a zone with ZONEMD record.
o Verify the zone digest from an input zone. o Verify the zone digest from an input zone.
o Output the ZONEMD record in its defined presentation format. o Output the ZONEMD record in its defined presentation format.
This implementation does not: This implementation does not:
o Re-compute DNSSEC signature over the ZONEMD record. o Re-compute DNSSEC signature over the ZONEMD record.
o Perform DNSSEC validation of the ZONEMD record. o Perform DNSSEC validation of the ZONEMD record.
10. Change Log 11. Change Log
RFC Editor: Please remove this section. RFC Editor: Please remove this section.
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.
skipping to change at page 19, line 23 skipping to change at page 21, line 41
From -02 to -03: From -02 to -03:
o Changed the name of Digest Type 1 from SHA384-STABLE to o Changed the name of Digest Type 1 from SHA384-STABLE to
SHA384-SIMPLE. SHA384-SIMPLE.
o Changed document status from Experimental to Standards Track. o Changed document status from Experimental to Standards Track.
o Removed Scope of Experimentation section. o Removed Scope of Experimentation section.
11. References From -03 to -04:
11.1. Normative References o Addressing WGLC feedback.
o Changed from "Digest Type + Paramter" to "Scheme + Hash
Algorithm". This should make it more obvious how ZONEMD 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.
o Note: old RDATA fields: Serial, Digest Type, Parameter, Digest.
o Note: new RDATA fields: Serial, Scheme, Hash Algorithm, Digest.
o Add new IANA requirement for a Scheme registry.
o Rearranged some sections and separated scheme-specific aspects
from general aspects of digest calculation.
o When discussing multiple ZONEMD RRs, allow for Scheme, as well as
Hash Algorithm, transition.
o Added Performance Considerations section with some benchmarks.
o Further clarifications about non-apex ZONEMD RRs.
o Clarified inclusion rule for duplicate RRs.
o Removed or lowercased some inappropriately used RFC 2119 key
words.
o Clarified that all ZONEMD RRs, even for unsupported hash
algorithms, must be zeroized during digest calculation.
o Added Resilience and Fragility to security considerations.
o Updated examples since changes in this version result in different
hash values.
12. References
12.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 19, line 49 skipping to change at page 23, line 10
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
Signature Algorithm (DSA) for DNSSEC", RFC 6605, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6605, April 2012, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6605>. <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>.
11.2. Informative References 12.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/>.
[dns-over-https] [dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-12 (work in (DoH)", draft-ietf-doh-dns-over-https-12 (work in
progress), June 2018, <https://tools.ietf.org/html/draft- progress), June 2018, <https://tools.ietf.org/html/draft-
ietf-doh-dns-over-https-12>. ietf-doh-dns-over-https-12>.
skipping to change at page 22, line 30 skipping to change at page 25, line 39
A.1. Simple EXAMPLE Zone A.1. Simple EXAMPLE Zone
Here, the EXAMPLE zone contains an SOA record, NS and glue records, Here, the EXAMPLE zone contains an SOA record, NS and glue records,
and a ZONEMD record. and a ZONEMD record.
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 0 ( 86400 IN ZONEMD 2018031900 1 1 (
379ec2587d4fff35 b3437dca3d6c9047
0062b9385a641476 9f43d4bf0c1a805e
6f9c028e8cf09d8a fbfca88635df014f
7965537a68a2f149 04a1049368a23a77
4e1c151f8cf6be05 577d896f0c58c5c7
5bef4f27e6a87b13 ) 338aabc7aa4314b5 )
ns1 3600 IN A 127.0.0.1 ns1 3600 IN A 127.0.0.1
ns2 3600 IN AAAA ::1 ns2 3600 IN AAAA ::1
A.2. Complex EXAMPLE Zone A.2. Complex EXAMPLE Zone
Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR, Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR,
and one out-of-zone RR. and one out-of-zone 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 0 ( 86400 IN ZONEMD 2018031900 1 1 (
c36e77eafdb7f3f6 9c31e37bd2d97ad4
dcfac8bca1121e17 9ead67b3a44f267e
2a7b57db2c88409a a223cc70c1a0988d
5c3d9247ba72b759 49ac98da1b7ca1ed
6c735c1a76fc817a ede57661b6cefc52
ad5c834f5a4bce16 ) 80d10d6b4b0b6cb1 )
ns1 3600 IN A 127.0.0.1 ns1 3600 IN A 127.0.0.1
ns2 3600 IN AAAA ::1 ns2 3600 IN AAAA ::1
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 0 ( 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. Since only
one Digest Type is defined at this time (SHA384-SIMPLE), this example one Hash Algorithm is defined at this time (SHA384), this example
utilizes additional ZONEMD records with Digest Type values in the utilizes additional ZONEMD records with Hash Algorithm values in the
private range (240-254). These additional private-range digests are private range (240-254). These additional private-range digests are
not verifiable, but note that their other fields (Serial, Parameter, not verifiable, but note that their other fields (Serial, Scheme,
Digest Type) are included in the calculation of all ZONEMD digests. Hash Algorithm) are included in the calculation of all ZONEMD
digests.
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 0 ( example. 86400 IN ZONEMD 2018031900 1 1 (
c0218e8eeb4f0275 6a126e222407923d
d54c0e5ce7791f4d f70e7aa44d5e813b
23742b4756708d50 0b18b469b78d3d50
d7121a11d434baa8 84cd3cbf24152eea
f869ebbb071a4bbb a68c00b6536bba2a
0457c87870bc8cdd ) 1f2cab0fd03a8162 )
example. 86400 IN ZONEMD 2018031900 240 0 ( example. 86400 IN ZONEMD 2018031900 1 240 (
e2d523f654b9422a e2d523f654b9422a
96c5a8f44607bbee ) 96c5a8f44607bbee )
example. 86400 IN ZONEMD 2018031900 241 0 ( example. 86400 IN ZONEMD 2018031900 1 241 (
5732dd91240611f8 5732dd91240611f8
314adb6b4769bdd2 ) 314adb6b4769bdd2 )
example. 86400 IN ZONEMD 2018031900 242 0 ( example. 86400 IN ZONEMD 2018031900 1 242 (
7c32e06779315c7d 7c32e06779315c7d
81ba8c72f5cf9116 81ba8c72f5cf9116
496b6395 ) 496b6395 )
example. 86400 IN ZONEMD 2018031900 243 0 ( example. 86400 IN ZONEMD 2018031900 1 243 (
183770af4a629f80 183770af4a629f80
2e674e305b8d0d11 2e674e305b8d0d11
3dfe0837 ) 3dfe0837 )
example. 86400 IN ZONEMD 2018031900 244 0 ( example. 86400 IN ZONEMD 2018031900 1 244 (
e1846540e33a9e41
89792d18d5d131f6
05fc283e )
example. 86400 IN ZONEMD 2018031900 240 1 (
e1846540e33a9e41 e1846540e33a9e41
89792d18d5d131f6 89792d18d5d131f6
05fc283e ) 05fc283e )
ns1.example. 3600 IN A 127.0.0.1 ns1.example. 3600 IN A 127.0.0.1
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 ::1 ns2.example. 3600 IN AAAA ::1
A.4. The URI.ARPA Zone A.4. The URI.ARPA Zone
The URI.ARPA zone retrieved 2018-10-21. The URI.ARPA zone retrieved 2018-10-21. Note this sample zone has
(expired) signatures, but no signature for the ZONEMD RR.
; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr ; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr
; (2 servers found) ; (2 servers found)
;; global options: +cmd ;; global options: +cmd
uri.arpa. 3600 IN SOA sns.dns.icann.org. ( uri.arpa. 3600 IN SOA sns.dns.icann.org. (
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 ( uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 (
20181028142623 20181007205525 47155 uri.arpa. 20181028142623 20181007205525 47155 uri.arpa.
eEC4w/oXLR1Epwgv4MBiDtSBsXhqrJVvJWUpbX8XpetAvD35bxwNCUTi eEC4w/oXLR1Epwgv4MBiDtSBsXhqrJVvJWUpbX8XpetAvD35bxwNCUTi
/pAJVUXefegWeiriD2rkTgCBCMmn7YQIm3gdR+HjY/+o3BXNQnz97f+e /pAJVUXefegWeiriD2rkTgCBCMmn7YQIm3gdR+HjY/+o3BXNQnz97f+e
skipping to change at page 27, line 32 skipping to change at page 30, line 37
urn.uri.arpa. 3600 IN NSEC uri.arpa. NAPTR RRSIG ( urn.uri.arpa. 3600 IN NSEC uri.arpa. NAPTR RRSIG (
NSEC ) NSEC )
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. ( uri.arpa. 3600 IN SOA sns.dns.icann.org. (
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
;; 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 0 ( uri.arpa. 3600 IN ZONEMD 2018100702 1 1 (
e4de6ed36e5d95706756932fae3ecbc6aeb76e16ce486a5553c7e4 cc4a0b6556272fc739b8ff74b80b4a43ac9575d91445ecc0dc22f5
c9974d03323e7cd39ccc5e70e797179633f4007bad ) 09fa27c62448a7100660bbdb4c90667424b734956b )
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 retreived 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.
skipping to change at page 28, line 50 skipping to change at page 31, line 50
j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30
j.root-servers.net. 3600000 IN A 192.58.128.30 j.root-servers.net. 3600000 IN A 192.58.128.30
k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1
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 0 ( root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 (
0c1839d86088062868c1ed79aed6a301dc7b08b02ba2f67cbc62edd4a0 4fb752b314e4dccb845832b611590b669a80daebb736d4bd22aa76ec06
291f4132b8840da47ddab4401cc9088d04a14a ) 6737c79185c1f7dfd49ec91d9523e6240ea2c4 )
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
 End of changes. 93 change blocks. 
270 lines changed or deleted 405 lines changed or added

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