< draft-ietf-dnsop-dns-zone-digest-02.txt   draft-ietf-dnsop-dns-zone-digest-03.txt >
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft P. Barber Internet-Draft P. Barber
Intended status: Experimental M. Weinberg Intended status: Standards Track M. Weinberg
Expires: April 30, 2020 Verisign Expires: June 5, 2020 Verisign
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
October 28, 2019 December 3, 2019
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-02 draft-ietf-dnsop-dns-zone-digest-03
Abstract Abstract
This document describes an experimental protocol and new DNS Resource This document describes a protocol and new DNS Resource Record that
Record that can be used to provide a message digest over DNS zone can be used to provide a cryptographic message digest over DNS zone
data. The ZONEMD Resource Record conveys the message digest data in data. The ZONEMD Resource Record conveys the digest data in the zone
the zone itself. When a zone publisher includes an ZONEMD record, itself. When a zone publisher includes an ZONEMD record, recipients
recipients can verify the zone contents for accuracy and can verify the zone contents for accuracy and completeness. This
completeness. This provides assurance that received zone data provides assurance that received zone data matches published data,
matches published data, regardless of how the zone data has been regardless of how the zone data has been transmitted and received.
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
protects a zone's data as a whole, whether consumed by authoritative protects a zone's data as a whole, whether consumed by authoritative
name servers, recursive name servers, or any other applications. name 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 calculation. The ZONEMD record described in this document includes a
fields reserved for future work to support large, dynamic zones. field intended to enable future work 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 April 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 32 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 7 1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 6
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. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
2.1.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 2.1.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
2.1.2. The Digest Type Field . . . . . . . . . . . . . . . . 8 2.1.2. The Digest Type Field . . . . . . . . . . . . . . . . 8
2.1.3. The Parameter Field . . . . . . . . . . . . . . . . . 8 2.1.3. The Parameter Field . . . . . . . . . . . . . . . . . 8
2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
2.2. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 2.2. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9
2.3. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 9 2.3. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 9
3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 9 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 9
3.1. Canonical Format and Ordering . . . . . . . . . . . . . . 9 3.1. Canonical Format and Ordering . . . . . . . . . . . . . . 9
3.1.1. Order of RRSets Having the Same Owner Name . . . . . 10 3.1.1. Order of RRSets Having the Same Owner Name . . . . . 10
3.1.2. Duplicate RRs . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Duplicate RRs . . . . . . . . . . . . . . . . . . . . 10
3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10
3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11 3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11
3.4.1. SHA384-STABLE Calculation . . . . . . . . . . . . . . 11 3.4.1. SHA384-SIMPLE Calculation . . . . . . . . . . . . . . 11
3.4.2. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 3.4.2. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11
3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 12 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13 4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13
5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 13
6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 5.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14
6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14
7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14 6.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 14
7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 15 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 9.1. Authors' Implementation . . . . . . . . . . . . . . . . . 15
10.1. Authors' Implementation . . . . . . . . . . . . . . . . 15 9.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 15
10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 16 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 22 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 22
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 23 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 22
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 23 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 23
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 24 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 24
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 27 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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
to verify the authenticity of a stand-alone zone. to verify the authenticity of a stand-alone zone.
This document introduces a new RR type that serves as a cryptographic This document introduces a new RR type that serves as 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 authenticity, especially when used in
combination with DNSSEC. This technique makes the message digest a combination with DNSSEC. This technique makes the digest a part of
part of the zone itself, allowing verification the zone as a whole, the zone itself, allowing verification the zone as a whole, no matter
no matter how it is transmitted. Furthermore, the digest is based on how it is transmitted. Furthermore, the digest is based on the wire
the wire format of zone data. Thus, it is independent of format of zone data. Thus, it is independent of presentation format,
presentation format, such as changes in whitespace, capitalization, such as changes in whitespace, capitalization, and comments.
and comments.
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 This specification is OPTIONAL to implement by both publishers and
consumers of zone data. consumers of zone data.
1.1. Motivation 1.1. Motivation
skipping to change at page 6, line 12 skipping to change at page 6, line 9
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, reserve a field in the updates of zone data. It does, however, include a field in the
ZONEMD record for future work to support incremental zone digest ZONEMD record intended for future work to support incremental zone
algorithms (e.g. using Merkle trees). digest algorithms (e.g. using Merkle trees).
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
skipping to change at page 8, line 28 skipping to change at page 8, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Digest | | Digest |
/ / / /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1. The Serial Field 2.1.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 message 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.1.2. The Digest Type Field
The Digest Type field is an 8-bit unsigned integer that identifies The Digest Type field is an 8-bit unsigned integer that identifies
the algorithm used to construct the digest. the algorithm used to construct the digest.
At the time of this writing, SHA384-STABLE, with value 1, is the only At the time of this writing, SHA384-SIMPLE, with value 1, is the only
standardized Digest Type defined for ZONEMD records. The Digest Type standardized Digest Type defined for ZONEMD records. The Digest Type
registry is further described in Section 6. registry is further described in Section 5.
Digest Type values 240-254 are allocated for Private Use as described Digest Type values 240-254 are allocated for Private Use as described
in [RFC8126]. in [RFC8126].
2.1.3. The Parameter Field 2.1.3. The Parameter Field
The Parameter field is an 8-bit unsigned integer whose meaning The Parameter field is an 8-bit unsigned integer whose meaning
depends on the Digest Type in use. For SHA384-STABLE, the Parameter depends on the Digest Type in use. For SHA384-SIMPLE, the Parameter
field plays no role in digest calculation or verification. field plays no role in digest calculation or verification.
2.1.4. The Digest Field 2.1.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 message digest. The Digest field MUST NOT be empty. Section 3
describes how to calculate the digest for a zone. Section 4 describes how to calculate the digest for a zone. Section 4
describes how to use the digest to verify the contents of a zone. describes how to use the digest to verify the contents of a zone.
2.2. ZONEMD Presentation Format 2.2. ZONEMD Presentation Format
skipping to change at page 11, line 8 skipping to change at page 11, line 8
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.4. Calculate the Digest
The digest calculation details vary depending upon the Digest Type. The digest calculation details vary depending upon the Digest Type.
This document describes digest calculation for SHA384-STABLE only. This document describes digest calculation for SHA384-SIMPLE only.
Digest calculation for additional types may be defined in future Digest calculation for additional types may be defined in future
updates to this document. updates to this document.
3.4.1. SHA384-STABLE Calculation 3.4.1. SHA384-SIMPLE Calculation
The Parameter field is not used in the calculation of SHA384-STABLE For SHA384-SIMPLE, the digest is calculated over the zone as a whole.
message digets. The Parameter field SHOULD be set to zero in This means that a change to a single RR in the zone requires
SHA384-STABLE placeholder records. 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- The zone digest is calculated by concatenating the canonical on-the-
wire form (without name compression) of all RRs in the zone, in the wire form (without name compression) of all RRs in the zone, in the
order described above, subject to the inclusion/exclusion rules order described above, subject to the inclusion/exclusion rules
described below, and then applying the SHA384 digest algorithm described below, and then applying the SHA384 digest algorithm
[RFC6605]: [RFC6605]:
digest = SHA384( RR(1) | RR(2) | RR(3) | ... ) digest = SHA384( RR(1) | RR(2) | RR(3) | ... )
where "|" denotes concatenation, and where "|" denotes concatenation, and
skipping to change at page 12, line 21 skipping to change at page 12, line 24
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 implementations of incremental DNSSEC signing might update the
zone's serial number for each resigning. However, to preserve the zone's serial number for each resigning. However, to preserve the
calculated digest, generation of the ZONEMD signature at this time calculated digest, generation of the ZONEMD signature at this time
MUST NOT also result in a change of the SOA serial number. MUST NOT also result in a change of the SOA serial number.
4. Verifying Zone Message Digest 4. Verifying Zone Digest
The recipient of a zone that has a message digest record can verify The recipient of a zone that has a ZONEMD RR can verify the zone by
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 SHOULD 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, 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 Paremter, digest verification MUST NOT be Digest Type and Parameter, 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 Digest Type field MUST be checked. If the verifier
does not support the given digest type, it SHOULD report that does not support the given digest type, it SHOULD report that
the zone digest could not be verified due to an unsupported the zone digest could not be verified due to an unsupported
algorithm. algorithm.
skipping to change at page 13, line 31 skipping to change at page 13, line 34
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 Type and
Digest stored in the temporary location. Thus, any downstream Digest stored in the temporary location. Thus, any downstream
clients can similarly verify the zone. clients can 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 Digest Type algorithms is sufficient to verify the zone.
5. Scope of Experimentation 5. IANA Considerations
This memo is published as an Experimental RFC. The purpose of the
experimental period is to provide the community time to analyze and
evaluate the methods defined in this document, particularly with
regard to the wide variety of DNS zones in use on the Internet.
Additionally, the ZONEMD record defined in this document includes a
Parameter field in the form of an 8-bit integer. The authors have a
particular future use in mind for this field, namely to support
efficient digests in large, dynamic zones. We intend to conduct
future experiments using Merkle trees of varying depth. The choice
of tree depth can be encoded in this reserved field. We expect
values for tree depth to range from 0 to 10, requiring at most four
bits of this field. This leaves another four bits available for
other future uses, if absolutely necessary.
The duration of the experiment is expected to be no less than two
years from the publication of this document. If the experiment is
successful, it is expected that the findings of the experiment will
result in an updated document for Standards Track approval.
6. IANA Considerations
6.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
6.2. ZONEMD Digest Type 5.2. ZONEMD Digest Type
This document asks IANA to create a new "ZONEMD Digest Types" This document asks IANA to create a new "ZONEMD Digest Types"
registry with initial contents as follows: registry with initial contents as follows:
+---------+-----------------+---------------+-----------+-----------+ +---------+-----------------+---------------+-----------+-----------+
| Value | Description | Mnemonic | Status | Reference | | Value | Description | Mnemonic | Status | Reference |
+---------+-----------------+---------------+-----------+-----------+ +---------+-----------------+---------------+-----------+-----------+
| 1 | SHA384 for | SHA384-STABLE | Mandatory | This | | 1 | SHA384 simple | SHA384-SIMPLE | Mandatory | This |
| | stable zones | | | document | | | zone digest | | | document |
| 240-254 | Private Use | - | - | [RFC8126] | | 240-254 | Private Use | - | - | [RFC8126] |
+---------+-----------------+---------------+-----------+-----------+ +---------+-----------------+---------------+-----------+-----------+
Table 1: ZONEMD Digest Types Table 1: ZONEMD Digest Types
7. Security Considerations 6. Security Considerations
7.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 RECOMMENDS that the verifier determine whether
or not to expect DNSSEC signatures for the zone in step 1. or not to 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 the ZONEMD
record. This is why Section 4 REQUIRES that the verifier checks record. This is why Section 4 REQUIRES that the verifier checks
DNSSEC denial-of-existence proofs in step 2. DNSSEC denial-of-existence proofs in step 2.
The attacker might alter the Digest Type or Digest fields of the The attacker might alter the Digest Type or Digest fields of the
ZONEMD record. Such modifications are detectable only with DNSSEC ZONEMD record. Such modifications are detectable only with DNSSEC
validation. validation.
7.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).
8. Privacy Considerations 7. Privacy Considerations
This specification has no impacts on user privacy. This specification has no impacts on user privacy.
9. Acknowledgments 8. 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, Paul Hoffman, Evan Hunt, Shumon
Huque, Tatuya Jinmei, Burt Kaliski, Shane Kerr, Matt Larson, John Huque, Tatuya Jinmei, Burt Kaliski, Shane Kerr, Matt Larson, John
Levine, Ed Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek, Levine, Ed Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek,
Ondrej Sury, Willem Toorop, Florian Weimer, Tim Wicinksi, Wouter Ondrej Sury, Willem Toorop, Florian Weimer, Tim Wicinksi, Wouter
Wijngarrds, Paul Wouters, and other members of the dnsop working Wijngarrds, Paul Wouters, and other members of the dnsop working
group for their input. group for their input.
10. Implementation Status 9. Implementation Status
10.1. Authors' Implementation 9.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.
10.2. Shane Kerr's Implementation 9.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 a output 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.
11. Change Log 10. 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 32 skipping to change at page 19, line 14
o Changed the name of Digest Type 1 from SHA384 to SHA384-STABLE. o Changed the name of Digest Type 1 from SHA384 to SHA384-STABLE.
o The meaning of the Parameter field now depends on Digest Type. o The meaning of the Parameter field now depends on Digest Type.
o No longer require Parameter field to be zero in verification. o No longer require Parameter field to be zero in verification.
o Updated a rule from earlier versions that said multiple ZONEMD RRs o Updated a rule from earlier versions that said multiple ZONEMD RRs
were not allowed. were not allowed.
12. References From -02 to -03:
12.1. Normative References o Changed the name of Digest Type 1 from SHA384-STABLE to
SHA384-SIMPLE.
o Changed document status from Experimental to Standards Track.
o Removed Scope of Experimentation section.
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 20, line 19 skipping to change at page 20, line 9
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605, Signature Algorithm (DSA) for DNSSEC", RFC 6605,
DOI 10.17487/RFC6605, April 2012, DOI 10.17487/RFC6605, April 2012,
<https://www.rfc-editor.org/info/rfc6605>. <https://www.rfc-editor.org/info/rfc6605>.
[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/>.
[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 23, line 39 skipping to change at page 23, line 34
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-STABLE), this example one Digest Type is defined at this time (SHA384-SIMPLE), this example
utilizes additional ZONEMD records with Digest Type values in the utilizes additional ZONEMD records with Digest Type 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, Parameter,
Digest Type) are included in the calculation of all ZONEMD digests. Digest Type) 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 0 (
 End of changes. 41 change blocks. 
99 lines changed or deleted 87 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/