draft-ietf-dnsop-dns-zone-digest-04.txt   draft-ietf-dnsop-dns-zone-digest-05.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: August 24, 2020 Verisign Expires: September 10, 2020 Verisign
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
February 21, 2020 March 9, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-04 draft-ietf-dnsop-dns-zone-digest-05
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 August 24, 2020. This Internet-Draft will expire on September 10, 2020.
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. Canonical Format and Ordering . . . . . . . . . . . . . . 10
3.3.1. Order of RRSets Having the Same Owner Name . . . . . 11 3.3.1. Order of RRSets Having the Same Owner Name . . . . . 11
3.4. Inclusion/Exclusion Rules . . . . . . . . . . . . . . . . 11 3.4. Inclusion/Exclusion Rules . . . . . . . . . . . . . . . . 11
3.5. Scheme-Specific Processing . . . . . . . . . . . . . . . 11 3.5. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
3.5.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12 3.5.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12
3.6. 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 . . . . . . . . . . . . . . . 14
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 the Zone Digest . . . . . . . . . . . . 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
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 25 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 25
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 25 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 26
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 26 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 27
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 27 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 28
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 30 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 ([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, 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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
zone data upon restart cannot guarantee that the on-disk data has not zone data upon restart cannot guarantee that the on-disk data has not
been modified. For these reasons, it is preferable to secure the been modified. For these reasons, it is preferable to secure the
data itself. data itself.
Why not simply rely on DNSSEC, which provides certain data security Why not simply rely on DNSSEC, which provides certain data security
guarantees? Certainly for zones that are signed, a recipient could guarantees? Certainly for zones that are signed, a recipient could
validate all of the signed RRSets. Additionally, denial-of-existence validate all of the signed RRSets. Additionally, denial-of-existence
records can prove that RRSets have not been added or removed. records can prove that RRSets have not been added or removed.
However, not all RRSets in a zone are signed. The design of DNSSEC However, not all RRSets in a zone are signed. The design of DNSSEC
stipulates that delegations (non-apex NS records) are not signed, and stipulates that delegations (non-apex NS records) are not signed, and
neither are any glue records. Thus, changes to delegation and glue neither are any glue records. ZONEMD protects the integrity of
records cannot be detected by DNSSEC alone. Furthermore, zones that delegation, glue, and other records that are not otherwise covered by
employ NSEC3 with opt-out are susceptible to the removal or addition DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are
of names between the signed nodes. Whereas DNSSEC is primarily susceptible to the removal or addition of names between the signed
designed to protect consumers of DNS response messages, this protocol nodes. Whereas DNSSEC is primarily designed to protect consumers of
is designed to protect consumers of zones. DNS response messages, this protocol is designed to protect consumers
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 [RFC3851]. 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 along side 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.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
[RFC2535], omits the AXFR SIG, while at the same time introducing an [RFC2535], omits the AXFR SIG, while at the same time introducing an
IXFR SIG. IXFR SIG.
1.2. Design Overview 1.2. Design Overview
This document introduces a new Resource Record type designed to This document introduces a new Resource Record type designed to
convey a message digest of the content of a zone. The digest is convey a message digest of the content of a zone. The digest is
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. Both require data to be processed in a well-
can be done in parallel. defined order and format. In some cases it may be possible to
perform DNSSEC signing and digest calculation 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 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
skipping to change at page 7, line 31 skipping to change at page 7, line 32
ICANN operates the Centralized Zone Data Service [CZDS], which is a ICANN operates the Centralized Zone Data Service [CZDS], which is a
repository of top-level domain zone files. Users request access to repository of top-level domain zone files. Users request access to
the system, and to individual zones, and are then able to download the system, and to individual zones, and are then able to download
zone data for certain uses. Adding a zone digest to these would zone data for certain uses. Adding a zone digest to these would
provide CZDS users with assurances that the data has not been provide CZDS users with assurances that the data has not been
modified. Note that ZONEMD could be added to CZDS zone data modified. Note that ZONEMD could be added to CZDS zone data
independently of the zone served by production name servers. independently of the zone served by production name servers.
1.3.5. General Purpose Comparison Check 1.3.5. General Purpose Comparison Check
Since the zone digest does not depend on presentation format, it Since the zone digest calculation does not depend on presentation
could be used to compare multiple copies of a zone received from format, it could be used to compare multiple copies of a zone
different sources, or copies generated by different processes. received from different sources, or copies generated by different
processes.
1.4. Requirements Language 1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. The ZONEMD Resource Record 2. The ZONEMD Resource Record
skipping to change at page 8, line 16 skipping to change at page 8, line 16
[RFC7696] and rollovers. Each ZONEMD RR must specify a unique Scheme [RFC7696] and rollovers. Each ZONEMD RR must specify a unique Scheme
and Hash Algorithm tuple. It is recommended that a zone include only and Hash Algorithm tuple. It is recommended that a zone include only
one ZONEMD RR, unless the zone publisher is in the process of one ZONEMD RR, unless the zone publisher is in the process of
transitioning to a new Scheme or Hash Algorithm. 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. Non-apex ZONEMD RRSets are treated like any other verification.
RRSet (which is to say they are included) during digest calculation.
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
placeholder RR.
Unless explicitly stated otherwise, "ZONEMD" always refers to apex Unless explicitly stated otherwise, "ZONEMD" always refers to apex
records throughout this document. records throughout this document.
2.2. ZONEMD RDATA Wire Format 2.2. ZONEMD RDATA Wire Format
The ZONEMD RDATA wire format is encoded as follows: The ZONEMD RDATA wire format is encoded as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 10, line 18 skipping to change at page 10, line 18
example.com. 86400 IN ZONEMD 2018031500 1 1 ( example.com. 86400 IN ZONEMD 2018031500 1 1 (
FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
3. Calculating the Digest 3. Calculating the Digest
3.1. Add ZONEMD Placeholder 3.1. Add ZONEMD Placeholder
In preparation for calculating the zone digest, any existing ZONEMD In preparation for calculating the zone digest, any existing ZONEMD
records at the zone apex are first deleted. records (and covering RRSIGs) at the zone apex are first deleted.
Prior to calculation of the digest, and prior to signing with DNSSEC, Prior to calculation of the digest, and prior to signing with DNSSEC,
a placeholder ZONEMD record is added to the zone apex. This serves one or more placeholder ZONEMD records are added to the zone apex.
two purposes: (1) it allows the digest to cover the Serial, Scheme, This serves two purposes: (1) it allows the digest to cover the
and Hash Algorithm fields, and (2) ensures that appropriate denial- Serial, Scheme, and Hash Algorithm fields, and (2) ensures that
of-existence (NSEC, NSEC3) records are created if the zone is signed appropriate denial-of-existence (NSEC, NSEC3) records are created if
with DNSSEC. the zone is signed with DNSSEC. When multiple ZONEMD RRs are
published in the zone, e.g., during an algorithm rollover, each must
specify a unique Scheme and Hash 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. The Digest field is set to all zeroes and the chosen hash algorithm. The Digest field is set to all zeroes and
of length appropriate for the chosen hash algorithm. of length appropriate for the chosen hash algorithm.
If multiple digests are to be published in the zone, e.g., during an
algorithm rollover, a placeholder record is added for each Scheme and
Hash Algorithm.
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. Canonical Format and Ordering
skipping to change at page 11, line 19 skipping to change at page 11, line 12
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.
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]). However, since DNSSEC does not RR form (Section 6.2 of [RFC4034]). However, since DNSSEC does not
define a canonical ordering for RRSets having the same owner name, define a canonical ordering for RRSets having the same owner name,
that ordering is defined here. that ordering is defined here.
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. Order of RRSets Having the Same Owner Name 3.3.1. Order of RRSets Having the Same Owner Name
For the purposes of calculating the zone digest, RRSets having the For the purposes of calculating the zone digest, RRSets having the
same owner name MUST be numerically ordered, in ascending order, by same owner name MUST be numerically ordered, in ascending order, by
their numeric RR TYPE. their numeric RR TYPE.
3.4. Inclusion/Exclusion Rules 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:
skipping to change at page 12, line 14 skipping to change at page 12, line 14
3.5.1. The SIMPLE Scheme 3.5.1. The SIMPLE Scheme
For the SIMPLE scheme, the digest is calculated over the zone as a For the SIMPLE scheme, the digest is calculated over the zone as a
whole. This means that a change to a single RR in the zone requires whole. This means that a change to a single RR in the zone requires
iterating over all RRs in the zone to recalculate the digest. SIMPLE iterating over all RRs in the zone to recalculate the digest. SIMPLE
is a good choice for zones that are small and/or stable, but probably is a good choice for zones that are small and/or stable, but probably
not good for zones that are large and/or dynamic. not good for zones that are large and/or dynamic.
A zone digest using the SIMPLE scheme is calculated by concatenating A zone digest using the SIMPLE scheme is calculated by concatenating
the canonical on-the-wire form (without name compression) of all RRs the canonical form of all RRs in the zone, in the order described in
in the zone, in the order described in Section 3.3, subject to the Section 3.3, subject to the inclusion/exclusion rules described in
inclusion/exclusion rules described in Section 3.4, and then applying Section 3.4, and then applying the SHA-384 algorithm:
the SHA-384 algorithm:
digest = hash( RR(1) | RR(2) | RR(3) | ... ) digest = hash( RR(1) | RR(2) | RR(3) | ... )
where "|" denotes concatenation, and where "|" denotes concatenation.
RR(i) = owner | type | class | TTL | RDATA length | RDATA
3.6. Update ZONEMD RR 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, the published ZONEMD record
the Digest field of the placeholder ZONEMD record. Repeat for each is finalised by inserting the digest into the placeholder ZONEMD.
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 appropriate RRSIG records If the zone is signed with DNSSEC, the RRSIG record(s) covering the
covering the ZONEMD RRSet MUST then be added or updated. Because the ZONEMD RRSet MUST then be added or updated. Because the ZONEMD
ZONEMD placeholder was added prior to signing, the zone will already placeholder was added prior to signing, the zone will already have
have the appropriate denial-of-existence (NSEC, NSEC3) records. the appropriate denial-of-existence (NSEC, NSEC3) records.
Some DNSSEC implementations (especially "online signing") might be Some DNSSEC implementations (especially "online signing") might be
designed such that the SOA serial number is updated whenever a new designed such that the SOA serial number is updated whenever a new
signature is made. To preserve the calculated digest, generation of signature is made. To preserve the calculated digest, generation of
an ZONEMD signature must not also result in a change to the SOA 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 serial number. The ZONEMD RR and the matching SOA MUST be published
at the same time. at the same time.
4. Verifying Zone Digest 4. Verifying Zone Digest
The recipient of a zone that has a ZONEMD RR can verify the zone by The recipient of a zone that has a ZONEMD RR can verify the zone by
calculating the digest as follows: calculating the digest as follows. If multiple ZONEMD RRs are
present in the zone, e.g., during an algorithm rollover, a match
using any one of the recipient's supported Schemes and Hash
Algorithms is sufficient to verify the zone.
1. The verifier MUST 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, or if DNSSEC validation can not be performed, provably insecure, or if DNSSEC validation can not be performed,
digest validation continues at step 4 below. 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
skipping to change at page 14, line 5 skipping to change at page 14, line 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 stored in 11. The ZONEMD RR's RDATA is reset to the received Digest stored in
the temporary location. Thus, any downstream clients can the temporary location. Thus, any downstream clients can
similarly verify the zone. similarly verify the zone.
4.1. Verifying Multiple Digests
If multiple digests are present in the zone, e.g., during an
algorithm rollover, a match using any one of the recipient's
supported Hash Algorithm algorithms is sufficient to verify the zone.
Note that when multiple ZONEMD RRs are present in the zone, the 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 Digest field of each MUST be zeroed in step 8 above, even for
unsupported Scheme and Hash Algorithm values. 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"
skipping to change at page 14, line 47 skipping to change at page 14, line 41
| Value | Description | Mnemonic | Status | Reference | | Value | Description | Mnemonic | Status | Reference |
+---------+--------------------+----------+-----------+-------------+ +---------+--------------------+----------+-----------+-------------+
| 0 | Reserved | RESERVED | N/A | N/A | | 0 | Reserved | RESERVED | N/A | N/A |
| 1 | Simple ZONEMD | SIMPLE | Mandatory | This | | 1 | Simple ZONEMD | SIMPLE | Mandatory | This |
| | collation | | | document | | | collation | | | document |
| 240-254 | Private Use | N/A | N/A | [RFC8126] | | 240-254 | Private Use | N/A | N/A | [RFC8126] |
+---------+--------------------+----------+-----------+-------------+ +---------+--------------------+----------+-----------+-------------+
Table 1: ZONEMD Scheme Registry Table 1: ZONEMD Scheme Registry
The IANA policy for assigning new values to the ZONEMD Scheme
registry shall be Specification Required, as described in [RFC8126].
5.3. ZONEMD Hash Algorithm 5.3. ZONEMD Hash Algorithm
This document asks IANA to create a new "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 |
+---------+----------------------+----------+-----------+-----------+ +---------+----------------------+----------+-----------+-----------+
| 0 | Reserved | RESERVED | N/A | N/A | | 0 | Reserved | RESERVED | N/A | N/A |
| 1 | The SHA-384 hash | SHA384 | Mandatory | [RFC6234] | | 1 | The SHA-384 hash | SHA384 | Mandatory | [RFC6234] |
| | algorithm | | | | | | algorithm | | | |
| 240-254 | Private Use | N/A | N/A | [RFC8126] | | 240-254 | Private Use | N/A | N/A | [RFC8126] |
+---------+----------------------+----------+-----------+-----------+ +---------+----------------------+----------+-----------+-----------+
Table 2: ZONEMD Hash Algorithm Registry Table 2: ZONEMD Hash Algorithm Registry
The IANA policy for assigning new values to the ZONEMD Hash Algorithm
registry shall be Specification Required, as described in [RFC8126].
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.
skipping to change at page 15, line 39 skipping to change at page 15, line 42
The attacker might perform a downgrade attack by removing one or more The attacker might perform a downgrade attack by removing one or more
ZONEMD records. Such a removal is detectable only with DNSSEC ZONEMD records. Such a removal is detectable only with DNSSEC
validation and is why Section 4 talks about checking denial-of- validation and is why Section 4 talks about checking denial-of-
existence proofs in step 2 and signature validation in step 3. existence proofs in step 2 and signature validation in step 3.
The attacker might alter the Scheme, Hash Algorithm, or Digest fields The attacker might alter the Scheme, Hash Algorithm, or Digest fields
of the ZONEMD record. Such modifications are detectable only with of the ZONEMD record. Such modifications are detectable only with
DNSSEC validation. DNSSEC validation.
6.2. Attacks Utilizing the Zone Digest 6.2. Attacks Utilizing ZONEMD Queries
Nothing in this specification prevents clients from making, and Nothing in this specification prevents clients from making, and
servers from responding to, ZONEMD queries. One might consider how servers from responding to, ZONEMD queries. Servers SHOULD NOT
well ZONEMD responses could be used in a distributed denial-of- calculate zone digests dynamically (for each query) as this can be
service amplification attack. used as a CPU resource exhaustion attack.
The ZONEMD RR is moderately sized, much like the DS RR. A single One might consider how well ZONEMD responses could be used in a
ZONEMD RR contributes approximately 40 to 65 octets to a DNS distributed denial-of-service amplification attack. The ZONEMD RR is
response, for currently defined digest types. Certainly other query moderately sized, much like the DS RR. A single ZONEMD RR
types result in larger amplification effects (i.e., DNSKEY). contributes approximately 40 to 65 octets to a DNS response, for
currently defined digest types. Certainly other RR types result in
larger amplification effects (i.e., DNSKEY).
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 17, line 21 skipping to change at page 17, line 21
| 10000 - 99999 | 0.00602 | | 10000 - 99999 | 0.00602 |
| 100000 - 999999 | 0.00845 | | 100000 - 999999 | 0.00845 |
| 1000000 - 9999999 | 0.0108 | | 1000000 - 9999999 | 0.0108 |
| 10000000 - 99999999 | 0.0148 | | 10000000 - 99999999 | 0.0148 |
+---------------------+----------------+ +---------------------+----------------+
For example, based on the above table, it takes approximately 0.13 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 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. RRs, and about 2.5 seconds for a zone with 300,000 RRs.
These benchmarks attempt to emulate a worst-case scenario and take
into account the time required to canonicalize the zone for
processing. Each of the 800+ zones were measured three times, and
then averaged, with a different random sorting of the input data
prior to each measurement.
8. Privacy Considerations 8. Privacy Considerations
This specification has no impacts on user privacy. This specification has no impact on user privacy.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank David Blacka, Scott Hollenbeck, and Rick The authors wish to thank David Blacka, Scott Hollenbeck, and Rick
Wilhelm for providing feedback on early drafts of this document. Wilhelm for providing feedback on early drafts of this document.
Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans, Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan
Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski, Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski,
Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund
Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer, Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer,
skipping to change at page 22, line 32 skipping to change at page 22, line 37
words. words.
o Clarified that all ZONEMD RRs, even for unsupported hash o Clarified that all ZONEMD RRs, even for unsupported hash
algorithms, must be zeroized during digest calculation. algorithms, must be zeroized during digest calculation.
o Added Resilience and Fragility to security considerations. o Added Resilience and Fragility to security considerations.
o Updated examples since changes in this version result in different o Updated examples since changes in this version result in different
hash values. hash values.
From -04 to -05:
o Clarifications about non-apex and multiple ZONEMD RRs.
o Clarifications about benchmark results.
o Don't compute ZONEMD on-the-fly.
o Specifciation Required for updates to ZONEMD protocol registries.
o Other rewording based on WGLC feedback.
o Updated RFC numbers for some references.
o Use documentation IP addresses instead of loopback.
o Updated examples in the appendix.
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,
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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<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>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
skipping to change at page 24, line 18 skipping to change at page 24, line 36
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>. <https://www.rfc-editor.org/info/rfc2845>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>. 2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004,
<https://www.rfc-editor.org/info/rfc3851>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007, DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>. <https://www.rfc-editor.org/info/rfc4880>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>.
[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 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706, Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, DOI 10.17487/RFC7706, November 2015,
<https://www.rfc-editor.org/info/rfc7706>. <https://www.rfc-editor.org/info/rfc7706>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <https://www.rfc-editor.org/info/rfc7719>.
[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>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[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]
skipping to change at page 25, line 40 skipping to change at page 26, line 15
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 1 ( 86400 IN ZONEMD 2018031900 1 1 (
b3437dca3d6c9047 e12a0dd55a1dd1b8
9f43d4bf0c1a805e e29ec9b1d42d71ec
fbfca88635df014f 09329da5f162f327
04a1049368a23a77 e1eb4803947995ec
577d896f0c58c5c7 f7c65aa566cf6cfd
338aabc7aa4314b5 ) 36a0caf8bdb03ac4 )
ns1 3600 IN A 127.0.0.1 ns1 3600 IN A 203.0.113.63
ns2 3600 IN AAAA ::1 ns2 3600 IN AAAA 2001:db8::63
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 1 ( 86400 IN ZONEMD 2018031900 1 1 (
9c31e37bd2d97ad4 626637812169d7ab
9ead67b3a44f267e fcb24f13cb704f13
a223cc70c1a0988d b8a131fee1c3bc73
49ac98da1b7ca1ed 29144fa5ec2608a4
ede57661b6cefc52 1b596d41ff8c8310
80d10d6b4b0b6cb1 ) b2897e73f6e521fc )
ns1 3600 IN A 127.0.0.1 ns1 3600 IN A 203.0.113.63
ns2 3600 IN AAAA ::1 ns2 3600 IN AAAA 2001:db8::63
occluded.sub 7200 IN TXT "I'm occluded but must be digested" occluded.sub 7200 IN TXT "I'm occluded but must be digested"
sub 7200 IN NS ns1 sub 7200 IN NS ns1
duplicate 300 IN TXT "I must be digested just once" duplicate 300 IN TXT "I must be digested just once"
duplicate 300 IN TXT "I must be digested just once" duplicate 300 IN TXT "I must be digested just once"
foo.test. 555 IN TXT "out-of-zone data must be excluded" foo.test. 555 IN TXT "out-of-zone data must be excluded"
non-apex 900 IN ZONEMD 2018031900 1 1 ( non-apex 900 IN ZONEMD 2018031900 1 1 (
616c6c6f77656420 616c6c6f77656420
6275742069676e6f 6275742069676e6f
7265642e20616c6c 7265642e20616c6c
6f77656420627574 6f77656420627574
skipping to change at page 27, line 10 skipping to change at page 28, line 10
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, Scheme, not verifiable, but note that their other fields (Serial, Scheme,
Hash Algorithm) are included in the calculation of all ZONEMD Hash Algorithm) are included in the calculation of all ZONEMD
digests. 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 1 ( example. 86400 IN ZONEMD 2018031900 1 1 (
6a126e222407923d 366d22ea3bd8df44
f70e7aa44d5e813b 0fa44b6213359d9b
0b18b469b78d3d50 1f73bb9d8dd67a1b
84cd3cbf24152eea 4c0bdf6f0b3657c5
a68c00b6536bba2a 0316f770fbb03057
1f2cab0fd03a8162 ) 0c06adb87c121431 )
example. 86400 IN ZONEMD 2018031900 1 240 ( example. 86400 IN ZONEMD 2018031900 1 240 (
e2d523f654b9422a e2d523f654b9422a
96c5a8f44607bbee ) 96c5a8f44607bbee )
example. 86400 IN ZONEMD 2018031900 1 241 ( example. 86400 IN ZONEMD 2018031900 1 241 (
5732dd91240611f8 5732dd91240611f8
314adb6b4769bdd2 ) 314adb6b4769bdd2 )
example. 86400 IN ZONEMD 2018031900 1 242 ( example. 86400 IN ZONEMD 2018031900 1 242 (
7c32e06779315c7d 7c32e06779315c7d
81ba8c72f5cf9116 81ba8c72f5cf9116
496b6395 ) 496b6395 )
skipping to change at page 27, line 38 skipping to change at page 28, line 38
2e674e305b8d0d11 2e674e305b8d0d11
3dfe0837 ) 3dfe0837 )
example. 86400 IN ZONEMD 2018031900 1 244 ( example. 86400 IN ZONEMD 2018031900 1 244 (
e1846540e33a9e41 e1846540e33a9e41
89792d18d5d131f6 89792d18d5d131f6
05fc283e ) 05fc283e )
example. 86400 IN ZONEMD 2018031900 240 1 ( 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 203.0.113.63
ns2.example. 86400 IN TXT "This example has multiple digests" ns2.example. 86400 IN TXT "This example has multiple digests"
ns2.example. 3600 IN AAAA ::1 ns2.example. 3600 IN AAAA 2001:db8::63
A.4. The URI.ARPA Zone A.4. The URI.ARPA Zone
The URI.ARPA zone retrieved 2018-10-21. Note this sample zone has The URI.ARPA zone retrieved 2018-10-21. Note this sample zone has
(expired) signatures, but no signature for the ZONEMD RR. (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. (
 End of changes. 44 change blocks. 
106 lines changed or deleted 138 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/