draft-ietf-dnsop-dns-zone-digest-08.txt   draft-ietf-dnsop-dns-zone-digest-09.txt 
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft P. Barber Internet-Draft P. Barber
Intended status: Standards Track Verisign Intended status: Standards Track Verisign
Expires: December 14, 2020 M. Weinberg Expires: March 1, 2021 M. Weinberg
Amazon Amazon
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
June 12, 2020 August 28, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-08 draft-ietf-dnsop-dns-zone-digest-09
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.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 December 14, 2020. This Internet-Draft will expire on March 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9 2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9
2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9 2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9
2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9
2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10
3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10
3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10
3.3. Canonical Format and Ordering . . . . . . . . . . . . . . 11 3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
3.4. Inclusion/Exclusion Rules . . . . . . . . . . . . . . . . 11 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11
3.5. Scheme-Specific Processing . . . . . . . . . . . . . . . 12 3.3.1.1. SIMPLE Scheme RR Format . . . . . . . . . . . . . 11
3.5.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12 3.3.1.2. SIMPLE Scheme RR Ordering . . . . . . . . . . . . 11
3.3.1.3. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11
3.6. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 3.3.1.4. SIMPLE Scheme Digest Calculation . . . . . . . . 12
3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14
5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15
6.2. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 15 6.2. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 15
6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 16 6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 16
7. Performance Considerations . . . . . . . . . . . . . . . . . 16 7. Performance Considerations . . . . . . . . . . . . . . . . . 16
7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 16 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
10.1. Authors' Implementation . . . . . . . . . . . . . . . . 17 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 17
10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 18 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 18
10.3. NIC Chile Labs Implementation . . . . . . . . . . . . . 18 10.3. NIC Chile Labs Implementation . . . . . . . . . . . . . 18
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 26 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 27 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 27
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 28 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 28
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
In the DNS, a zone is the collection of authoritative resource In the DNS, a zone is the collection of authoritative resource
records (RRs) sharing a common origin ([RFC8499]). Zones are often records (RRs) sharing a common origin ([RFC8499]). Zones are often
stored as files on disk in the so-called master file format stored as files 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, and rsync, and even via email. Currently there is no standard
to verify the authenticity of a stand-alone zone. way 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 digest a part of combination with DNSSEC. This technique makes the digest a part of
the zone itself, allowing verification the zone as a whole, no matter the zone itself, allowing verification the zone as a whole, no matter
how it is transmitted. Furthermore, the digest is based on the wire how it is transmitted. Furthermore, the digest is based on the wire
format of zone data. Thus, it is independent of presentation format, format of zone data. Thus, it is independent of presentation format,
such as changes in whitespace, capitalization, and comments. such as changes in whitespace, capitalization, and comments.
skipping to change at page 5, line 28 skipping to change at page 5, line 29
neither are any glue records. ZONEMD protects the integrity of neither are any glue records. ZONEMD protects the integrity of
delegation, glue, and other records that are not otherwise covered by delegation, glue, and other records that are not otherwise covered by
DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are
susceptible to the removal or addition of names between the signed susceptible to the removal or addition of names between the signed
nodes. Whereas DNSSEC is primarily designed to protect consumers of nodes. Whereas DNSSEC is primarily designed to protect consumers of
DNS response messages, this protocol is designed to protect consumers DNS response messages, this protocol is designed to protect consumers
of zones. of zones.
There are existing tools and protocols that provide data security, There are existing tools and protocols that provide data security,
such as OpenPGP [RFC4880] and S/MIME [RFC5751]. In fact, the such as OpenPGP [RFC4880] and S/MIME [RFC5751]. In fact, the
internic.net site publishes PGP signatures along side the root zone internic.net site publishes PGP signatures alongside the root zone
and other files available there. However, this is a detached and other files available there. However, this is a detached
signature with no strong association to the corresponding zone file signature with no strong association to the corresponding zone file
other than its timestamp. Non-detached signatures are, of course, other than its timestamp. Non-detached signatures are, of course,
possible, but these necessarily change the format of the file being possible, but these necessarily change the format of the file being
distributed. That is, a zone signed with OpenPGP or S/MIME no longer distributed. That is, a zone signed with OpenPGP or S/MIME no longer
looks like a DNS zone and could not directly be loaded into a name looks like a DNS zone and could not directly be loaded into a name
server. Once loaded the signature data is lost, so it does not server. Once loaded the signature data is lost, so it does not
survive further propagation. survive further propagation.
It seems the desire for data security in DNS zones was envisioned as It seems the desire for data security in DNS zones was envisioned as
skipping to change at page 6, line 29 skipping to change at page 6, line 29
specification does not provide an efficient mechanism for incremental specification does not provide an efficient mechanism for incremental
updates of zone data. It is, however, extensible so that future updates of zone data. It is, however, extensible so that future
schemes to support incremental zone digest algorithms (e.g. using schemes to support incremental zone digest algorithms (e.g. using
Merkle trees) can be accommodated. 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 more than 1000 separate instances zone on the Internet, served by more than 1000 separate instances
[RootServers] at the time of this writing. Additionally, many [RootServers] at the time of this writing. Additionally, many
organizations configure their own name servers to serve the root zone organizations configure their own name servers to serve the root zone
locally. Reasons for doing so include privacy and reduced access locally. Reasons for doing so include privacy and reduced access
time. [RFC7706] describes one, but not the only, way to do this. As time. [RFC8806] describes one, but not the only, way to do this. As
the root zone spreads beyond its traditional deployment boundaries, the root zone spreads beyond its traditional deployment boundaries,
the 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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
2. The ZONEMD Resource Record 2. The ZONEMD Resource Record
This section describes the ZONEMD Resource Record, including its This section describes the ZONEMD Resource Record, including its
fields, wire format, and presentation format. The Type value for the fields, wire format, and presentation format. The Type value for the
ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
the resource record consists of four fields: Serial, Scheme, Hash the resource record consists of four fields: Serial, Scheme, Hash
Algorithm, and Digest. Algorithm, and Digest.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility A zone MAY contain multiple ZONEMD RRs to support algorithm agility
[RFC7696] and rollovers. Each ZONEMD RR must specify a unique Scheme [RFC7696] and rollovers. When multiple ZONEMD RRs are present, each
and Hash Algorithm tuple. It is recommended that a zone include only must specify a unique Scheme and Hash Algorithm tuple. It is
one ZONEMD RR, unless the zone publisher is in the process of recommended that a zone include only one ZONEMD RR, unless the zone
transitioning to a new Scheme or Hash Algorithm. publisher is in the process of transitioning to a new Scheme or Hash
Algorithm.
2.1. Non-apex ZONEMD Records 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. Non-apex ZONEMD RRs MUST NOT be used for specification. Non-apex ZONEMD RRs MUST NOT be used for
verification. verification.
During digest calculation, non-apex ZONEMD RRs are treated like any During digest calculation, non-apex ZONEMD RRs are treated like any
other RRs. They are digested as-is and the RR is not replaced by a other RRs. They are digested as-is and the RR is not replaced by a
skipping to change at page 10, line 40 skipping to change at page 10, line 40
Algorithm tuple. Algorithm tuple.
It is recommended that the TTL of the ZONEMD record match the TTL of It is recommended that the TTL of the ZONEMD record match the TTL of
the SOA. the SOA.
In the placeholder record, the Serial field is set to the current SOA In the placeholder record, the Serial field is set to the current SOA
Serial. The Scheme field is set to the value for the chosen Serial. The Scheme field is set to the value for the chosen
collation scheme. The Hash Algorithm field is set to the value for collation scheme. The Hash Algorithm field is set to the value for
the chosen hash algorithm. Since ZONEMD records are excluded from the chosen hash algorithm. Since ZONEMD records are excluded from
digest calculation, the value of the Digest field does not matter at digest calculation, the value of the Digest field does not matter at
this point in the process. Implementations MAY want to set the this point in the process.
Digest field to all zeroes anyway.
3.2. Optionally Sign the Zone 3.2. Optionally Sign the Zone
Following addition of placeholder records, the zone may be signed Following addition of placeholder records, the zone may be signed
with DNSSEC. Note that when the digest calculation is complete, and with DNSSEC. 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.3. Canonical Format and Ordering 3.3. 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.3.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.
Calculation of a zone digest REQUIRES RRs to be processed in a Calculation of a zone digest REQUIRES RRs to be processed in a
consistent format and ordering. Correct ordering depends on (1) consistent format and ordering. Correct ordering depends on (1)
ordering of owner names, (2) ordering of RRSets with the same owner ordering of owner names, (2) ordering of RRSets with the same owner
name, and (3) ordering of RRs within an RRSet. name, and (3) ordering of RRs within an RRSet.
3.3.1.1. SIMPLE Scheme RR Format
This specification adopts DNSSEC's canonical on-the-wire RR format
(without name compression) as specified in [RFC4034]:
RR(i) = owner | type | class | TTL | RDATA length | RDATA
where "|" denotes concatenation.
3.3.1.2. SIMPLE Scheme RR Ordering
This specification adopts DNSSEC's canonical ordering for names This specification adopts DNSSEC's canonical ordering for names
(Section 6.1 of [RFC4034]), and canonical ordering for RRs within an (Section 6.1 of [RFC4034]), and canonical ordering for RRs within an
RRSet (Section 6.3 of [RFC4034]). It also adopts DNSSEC's canonical RRSet (Section 6.3 of [RFC4034]). It also adopts DNSSEC's canonical
RR form (Section 6.2 of [RFC4034]). RR form (Section 6.2 of [RFC4034]).
However, since DNSSEC does not define a canonical ordering for RRSets However, since DNSSEC does not define a canonical ordering for RRSets
having the same owner name, that ordering is defined here. For the having the same owner name, that ordering is defined here. For the
purposes of calculating the zone digest, RRSets having the same owner purposes of calculating the zone digest, RRSets having the same owner
name MUST be numerically ordered, in ascending order, by their name MUST be numerically ordered, in ascending order, by their
numeric RR TYPE. numeric RR TYPE.
This specification adopts DNSSEC's canonical on-the-wire RR format 3.3.1.3. SIMPLE Scheme Inclusion/Exclusion Rules
(without name compression) as specified in [RFC4034]:
RR(i) = owner | type | class | TTL | RDATA length | RDATA
where "|" denotes concatenation.
3.4. Inclusion/Exclusion Rules
When iterating over records in the zone, the following inclusion/ When iterating over records in the zone, the following inclusion/
exclusion rules apply: exclusion rules apply:
o All records in the zone, including glue records, MUST be included. o All records in the zone, including glue records, MUST be included.
o Occluded data ([RFC5936] Section 3.5) MUST be included. o Occluded data ([RFC5936] Section 3.5) MUST be included.
o Only one instance of duplicate RRs with equal owner, class, type o If there are duplicate RRs with equal owner, class, type, and
and RDATA SHALL be included ([RFC4034] Section 6.3). RDATA, only one instance is included ([RFC4034] Section 6.3), and
the duplicates MUST be omitted.
o The placeholder ZONEMD RR(s) MUST NOT be included. o The placeholder ZONEMD RR(s) MUST NOT be included.
o If the zone is signed, DNSSEC RRs MUST be included, except: o If the zone is signed, DNSSEC RRs MUST be included, except:
o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG
will be updated after all digests have been calculated. will be updated after all digests have been calculated.
3.5. Scheme-Specific Processing 3.3.1.4. SIMPLE Scheme Digest Calculation
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 A zone digest using the SIMPLE scheme is calculated by concatenating
the canonical form of all RRs in the zone, in the order described in all RRs in the zone, in the format described in Section 3.3.1.1, in
Section 3.3, subject to the inclusion/exclusion rules described in the order described in Section 3.3.1.2, subject to the inclusion/
Section 3.4, and then applying the SHA-384 algorithm: exclusion rules described in Section 3.3.1.3, and then applying the
SHA-384 algorithm:
digest = hash( RR(1) | RR(2) | RR(3) | ... ) digest = SHA384( RR(1) | RR(2) | RR(3) | ... )
where "|" denotes concatenation. where "|" denotes concatenation.
3.6. Update ZONEMD RR 3.4. Update ZONEMD RR
Once a zone digest has been calculated, the published ZONEMD record Once a zone digest has been calculated, the published ZONEMD record
is finalised by inserting the digest into the placeholder ZONEMD. is finalised by inserting the digest into the placeholder ZONEMD.
Repeat for each digest if multiple digests are to be published. Repeat for each digest if multiple digests are to be published.
If the zone is signed with DNSSEC, the RRSIG record(s) covering the If the zone is signed with DNSSEC, the RRSIG record(s) covering the
ZONEMD RRSet MUST then be added or updated. Because the ZONEMD ZONEMD RRSet MUST then be added or updated. Because the ZONEMD
placeholder was added prior to signing, the zone will already have placeholder was added prior to signing, the zone will already have
the appropriate denial-of-existence (NSEC, NSEC3) records. the appropriate denial-of-existence (NSEC, NSEC3) records.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
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. When multiple ZONEMD RRs are present, each must specify a unique
Scheme and Hash Algorithm, digest verification MUST NOT be Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains
considered successful. more than one RR with the same Scheme and Hash Algorithm, digest
verification MUST NOT be considered successful.
5. Loop over all apex ZONEMD RRs and perform the following steps: 5. Loop over all apex ZONEMD RRs and perform the following steps:
A. The SOA Serial field MUST exactly match the ZONEMD Serial A. The SOA Serial field MUST exactly match the ZONEMD Serial
field. If the fields do not match, digest verification MUST field. If the fields do not match, digest verification MUST
NOT be considered successful with this ZONEMD RR. NOT be considered successful with this ZONEMD RR.
B. The Scheme field MUST be checked. If the verifier does not B. The Scheme field MUST be checked. If the verifier does not
support the given scheme, it SHOULD report that the RR's support the given scheme, it SHOULD report that the RR's
digest could not be verified due to an unsupported scheme. digest could not be verified due to an unsupported scheme.
C. The Hash Algorithm field MUST be checked. If the verifier C. The Hash Algorithm field MUST be checked. If the verifier
does not support the given hash algorithm, it SHOULD report does not support the given hash algorithm, it SHOULD report
that the RR's digest could not be verified due to an that the RR's digest could not be verified due to an
unsupported algorithm. unsupported algorithm.
D. The zone digest is computed over the zone data as described D. The zone digest is computed over the zone data as described
in Section 3.5, using the Scheme and Hash Algorithm for the in Section 3.3, using the Scheme and Hash Algorithm for the
current ZONEMD RR. current ZONEMD RR.
E. The computed digest is compared to the received digest. If E. The computed digest is compared to the received digest. If
the two digest values match, verification is considered the two digest values match, verification is considered
successful. Otherwise, verification MUST NOT be considered successful. Otherwise, verification MUST NOT be considered
successful for this ZONEMD RR. successful for this ZONEMD RR.
5. IANA Considerations 5. IANA Considerations
5.1. ZONEMD RRtype 5.1. ZONEMD RRtype
skipping to change at page 16, line 4 skipping to change at page 16, line 4
Nothing in this specification prevents clients from making, and Nothing in this specification prevents clients from making, and
servers from responding to, ZONEMD queries. Servers SHOULD NOT servers from responding to, ZONEMD queries. Servers SHOULD NOT
calculate zone digests dynamically (for each query) as this can be calculate zone digests dynamically (for each query) as this can be
used as a CPU resource exhaustion attack. used as a CPU resource exhaustion attack.
One might consider how well ZONEMD responses could be used in a One might consider how well ZONEMD responses could be used in a
distributed denial-of-service amplification attack. The ZONEMD RR is distributed denial-of-service amplification attack. The ZONEMD RR is
moderately sized, much like the DS RR. A single ZONEMD RR moderately sized, much like the DS RR. A single ZONEMD RR
contributes approximately 40 to 65 octets to a DNS response, for contributes approximately 40 to 65 octets to a DNS response, for
currently defined digest types. Certainly other RR types result in currently defined digest types. Certainly other RR types, such as
larger amplification effects (i.e., DNSKEY). DNSKEY, can result in larger amplification effects.
6.3. Resilience and Fragility 6.3. Resilience and Fragility
ZONEMD can be used to detect incomplete or corrupted zone data prior ZONEMD can be used to detect incomplete or corrupted zone data prior
to its use, thereby increasing resilience, but also introducing some to its use, thereby increasing resilience, but also introducing some
fragility. Publishers and consumers of zones containing ZONEMD fragility. Publishers and consumers of zones containing ZONEMD
records should be aware of these tradeoffs. While the intention is records should be aware of these tradeoffs. While the intention is
to secure the zone data, misconfigurations or implementation bugs are to secure the zone data, misconfigurations or implementation bugs are
generally indistinguishable from intentional tampering, and could generally indistinguishable from intentional tampering, and could
lead to service failures when verification is performed lead to service failures when verification is performed
skipping to change at page 24, line 5 skipping to change at page 23, line 52
From -07 to -08: From -07 to -08:
o Update an author's affiliation. o Update an author's affiliation.
o Clarified why placeholder RRs are still important (for NSEC/ o Clarified why placeholder RRs are still important (for NSEC/
NSEC3). NSEC3).
o Moved subsection ("Order of RRSets Having the Same Owner Name") o Moved subsection ("Order of RRSets Having the Same Owner Name")
with single sentence paragraph up into parent section. with single sentence paragraph up into parent section.
From -08 to -09:
o Moved format, ordering, inclusion/exclusion into a sub section
specific to the SIMPLE scheme.
o Further clarified rules about multiple ZONEMD RRs (AD comments).
o Reworeded rules about processing of duplicate zone RRs (AD
comments).
o Removed sentence about optional zeroing of digest prior to
calculation (AD comments).
o Other minor changes (AD comments).
12. References 12. References
12.1. Normative 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,
skipping to change at page 26, line 10 skipping to change at page 26, line 24
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>. <https://www.rfc-editor.org/info/rfc5936>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015,
<https://www.rfc-editor.org/info/rfc7706>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>.
[RootServers] [RootServers]
Root Server Operators, "Root Server Technical Operations", Root Server Operators, "Root Server Technical Operations",
July 2018, <https://www.root-servers.org/>. July 2018, <https://www.root-servers.org/>.
[RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones [RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones
(RPZ)", draft-vixie-dnsop-dns-rpz-00 (work in progress), (RPZ)", draft-vixie-dnsop-dns-rpz-00 (work in progress),
June 2018, <https://tools.ietf.org/html/draft-vixie-dnsop- June 2018, <https://tools.ietf.org/html/draft-vixie-dnsop-
dns-rpz-00>. dns-rpz-00>.
[ZoneDigestHackathon] [ZoneDigestHackathon]
 End of changes. 26 change blocks. 
62 lines changed or deleted 84 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/