draft-dns-zone-digest-06.txt   draft-ietf-dnsop-dns-zone-digest-00.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: Experimental M. Weinberg
Expires: August 17, 2019 Verisign Expires: December 20, 2019 Verisign
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
February 13, 2019 June 18, 2019
Message Digest for DNS Zones Message Digest for DNS Zones
draft-wessels-dns-zone-digest-06 draft-ietf-dnsop-dns-zone-digest-00
Abstract Abstract
This document describes an experimental protocol and new DNS Resource This document describes an experimental protocol and new DNS Resource
Record that can be used to provide a message digest over DNS zone Record that can be used to provide a message digest over DNS zone
data. The ZONEMD Resource Record conveys the message digest data in data. The ZONEMD Resource Record conveys the message digest data in
the zone itself. When a zone publisher includes an ZONEMD record, the zone itself. When a zone publisher includes an ZONEMD record,
recipients can verify the zone contents for accuracy and recipients can verify the zone contents for accuracy and
completeness. This provides assurance that received zone data completeness. This provides assurance that received zone data
matches published data, regardless of how the zone data has been matches published data, regardless of how the zone data has been
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 17, 2019. This Internet-Draft will expire on December 20, 2019.
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 41 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . . . 7
1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7
1.3.5. General Purpose Comparison Check . . . . . . . . . . 7 1.3.5. General Purpose Comparison Check . . . . . . . . . . 7
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7
2.1. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.1. 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 Reserved Field . . . . . . . . . . . . . . . . . 8 2.1.3. The Reserved Field . . . . . . . . . . . . . . . . . 8
2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 8 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 . . . . . 9 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 . . . . . . . . . . . . . . . . . . 10 3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11
3.4.1. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 3.4.1. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11
3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 11 3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 11
4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 11 4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 12
4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13
5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13 5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 13 6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14 6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14 7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14
7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 14 7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 15
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
10.1. Authors' Implementation . . . . . . . . . . . . . . . . 15 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 15
10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 15 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 16
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 21 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 22
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 21 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 21 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 22
A.3. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 22 A.3. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 23
A.4. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 25 A.4. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
In the DNS, a zone is the collection of authoritative resource In the DNS, a zone is the collection of authoritative resource
records (RRs) sharing a common origin ([RFC7719]). Zones are often records (RRs) sharing a common origin ([RFC7719]). Zones are often
stored as files on disk in the so-called master file format stored as files on disk in the so-called master file format
[RFC1034]. Zones are generally distributed among name servers using [RFC1034]. Zones are generally distributed among name servers using
the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can
also be distributed outside of the DNS, with such protocols as FTP, also be distributed outside of the DNS, with such protocols as FTP,
HTTP, rsync, and even via email. Currently there is no standard way HTTP, rsync, and even via email. Currently there is no standard way
skipping to change at page 7, line 47 skipping to change at page 7, line 47
capitals, as shown here. capitals, as shown here.
2. The ZONEMD Resource Record 2. The ZONEMD Resource Record
This section describes the ZONEMD Resource Record, including its This section describes the ZONEMD Resource Record, including its
fields, wire format, and presentation format. The Type value for the fields, wire format, and presentation format. The Type value for the
ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
the resource record consists of four fields: Serial, Digest Type, the resource record consists of four fields: Serial, Digest Type,
Reserved, and Digest. Reserved, and Digest.
FOR DISCUSSION: This document is currently written as though a zone This specification utilizes ZONEMD RRs located at the zone apex.
MUST NOT contain more than one ZONEMD RR. Having exactly one ZONEMD Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
record per zone simplifies this protocol and eliminates confusion specification.
around downgrade attacks, at the expense of algorithm agility.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility
[RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest
Type. It is RECOMMENDED that a zone include only one ZONEMD RR,
unless the zone publisher is in the process of transitioning to a new
Digest Type.
2.1. ZONEMD RDATA Wire Format 2.1. ZONEMD RDATA Wire Format
The ZONEMD RDATA wire format is encoded as follows: The ZONEMD RDATA wire format is encoded as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial | | Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 37 skipping to change at page 8, line 40
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, with value 1, is the only Digest At the time of this writing, SHA384, with value 1, is the only
Type defined for ZONEMD records. The Digest Type registry is further standardized Digest Type defined for ZONEMD records. The Digest Type
described in Section 6. registry is further described in Section 6.
Digest Type values 240-254 are allocated for Private Use as described
in [RFC8126].
2.1.3. The Reserved Field 2.1.3. The Reserved Field
The Reserved field is an 8-bit unsigned integer, which is always set The Reserved field is an 8-bit unsigned integer, which is always set
to zero. This field is reserved for future work to support efficient to zero. This field is reserved for future work to support efficient
incremental updates. incremental updates.
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. Section 3 describes how to calculate the digest the message digest. The Digest field MUST NOT be empty. Section 3
for a zone. Section 4 describes how to use the digest to verify the describes how to calculate the digest for a zone. Section 4
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
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Serial field MUST be represented as an unsigned decimal integer. The Serial field MUST be represented as an unsigned decimal integer.
The Digest Type field MUST be represented as an unsigned decimal The Digest Type field MUST be represented as an unsigned decimal
integer. integer.
skipping to change at page 9, line 25 skipping to change at page 9, line 32
set to zero. set to zero.
The Digest MUST be represented as a sequence of case-insensitive The Digest MUST be represented as a sequence of case-insensitive
hexadecimal digits. Whitespace is allowed within the hexadecimal hexadecimal digits. Whitespace is allowed within the hexadecimal
text. text.
2.3. ZONEMD Example 2.3. ZONEMD Example
The following example shows a ZONEMD RR. The following example shows a ZONEMD RR.
example.com. 86400 IN ZONEMD 2018031500 4 0 ( example.com. 86400 IN ZONEMD 2018031500 1 0 (
FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
3. Calculating the Digest 3. Calculating the Digest
3.1. Canonical Format and Ordering 3.1. Canonical Format and Ordering
Calculation of the zone digest REQUIRES the RRs in a zone to be Calculation of the zone digest REQUIRES the RRs in a zone to be
processed in a consistent format and ordering. Correct ordering of processed in a consistent format and ordering. Correct ordering of
the zone depends on (1) ordering of owner names in the zone, (2) the zone depends on (1) ordering of owner names in the zone, (2)
skipping to change at page 10, line 15 skipping to change at page 10, line 21
3.1.2. Duplicate RRs 3.1.2. Duplicate RRs
As stated in Section 5 of [RFC2181], it is meaningless for a zone to As stated in Section 5 of [RFC2181], it is meaningless for a zone to
have multiple RRs with equal owner name, class, type, and RDATA. In have multiple RRs with equal owner name, class, type, and RDATA. In
the interest of consistency and interoperability, such duplicate RRs the interest of consistency and interoperability, such duplicate RRs
MUST NOT be included in the calculation of a zone digest. MUST NOT be included in the calculation of a zone digest.
3.2. Add ZONEMD Placeholder 3.2. Add ZONEMD Placeholder
In preparation for calculating the zone digest, any existing ZONEMD In preparation for calculating the zone digest, any existing ZONEMD
record at the zone apex MUST first be deleted. records at the zone apex MUST first be deleted.
FOR DISCUSSION: Should non-apex ZONEMD records be allowed in a zone?
Or forbidden?
Prior to calculation of the digest, and prior to signing with DNSSEC, Prior to calculation of the digest, and prior to signing with DNSSEC,
a placeholder ZONEMD record MUST be added to the zone apex. This a placeholder ZONEMD record MUST be added to the zone apex. This
serves two purposes: (1) it allows the digest to cover the Serial, serves two purposes: (1) it allows the digest to cover the Serial,
Digest Type, and Reserved field values, and (2) ensures that Digest Type, and Reserved field values, and (2) ensures that
appropriate denial-of-existence (NSEC, NSEC3) records are created if appropriate denial-of-existence (NSEC, NSEC3) records are created if
the zone is signed with DNSSEC. the zone is signed with DNSSEC.
It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of
the SOA. the SOA.
In the placeholder record, the Serial field MUST be set to the In the placeholder record, the Serial field MUST be set to the
current SOA Serial. The Digest Type field MUST be set to the value current SOA Serial. The Digest Type field MUST be set to the value
for the chosen digest algorithm. The Reserved field MUST be set to for the chosen digest algorithm. The Reserved field MUST be set to
zero. The Digest field MUST be set to all zeroes and of length zero. The Digest field MUST be set to all zeroes and of length
appropriate for the chosen digest algorithm. appropriate for the chosen digest algorithm.
If multiple digests are to be published in the zone, e.g., during an
algorithm rollover, there MUST be one placeholder record for each
Digest Type.
3.3. Optionally Sign the Zone 3.3. Optionally Sign the Zone
Following addition of the placeholder record, 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 that record MUST the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet
be recalculated and updated as well. Therefore, the signer is not MUST be recalculated and updated as well. Therefore, the signer is
required to calculate a signature over the placeholder record at this not required to calculate a signature over the placeholder record at
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 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 digest algorithm: described below, and then applying the digest algorithm:
digest = digest_algorithm( RR(1) | RR(2) | RR(3) | ... ) digest = digest_algorithm( RR(1) | RR(2) | RR(3) | ... )
skipping to change at page 11, line 23 skipping to change at page 11, line 30
When calculating the digest, the following inclusion/exclusion rules When calculating the digest, the following inclusion/exclusion rules
apply: apply:
o All records in the zone, including glue records, MUST be included. o All records in the zone, including glue records, MUST be included.
o Occluded data ([RFC5936] Section 3.5) MUST be included. o Occluded data ([RFC5936] Section 3.5) MUST be included.
o Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be o Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be
included. included.
o The placeholder ZONEMD RR MUST be included. o The placeholder ZONEMD RR(s) MUST be included.
o If the zone is signed, DNSSEC RRs MUST be included, except: o If the zone is signed, DNSSEC RRs MUST be included, except:
o The RRSIG covering ZONEMD MUST NOT be included. o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG
will be updated after all digests have been calculated.
3.5. Update ZONEMD RR 3.5. Update ZONEMD RR
Once the zone digest has been calculated, its value is then copied to Once the zone digest has been calculated, its value is then copied to
the Digest field of the ZONEMD record. the Digest field of the ZONEMD record.
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 record MUST then be added or updated. Because covering the ZONEMD RRSet MUST then be added or updated. Because the
the ZONEMD placeholder was added prior to signing, the zone will ZONEMD placeholder was added prior to signing, the zone will already
already have the appropriate denial-of-existence (NSEC, NSEC3) have the appropriate denial-of-existence (NSEC, NSEC3) records.
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 Message Digest
The recipient of a zone that has a message digest record can verify The recipient of a zone that has a message digest record can verify
the zone by calculating the digest as follows: the zone by 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 unsigned, digest validation continues at step 4 below. provably insecure, digest validation continues at step 4 below.
2. For zones that are provably signed, 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 signed, the SOA RR and ZONEMD RR 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 zone contains more than one apex ZONEMD RR, digest 4. If the zone contains more than one apex ZONEMD RR, digest
verification MUST NOT be considered successful. verification MUST NOT be 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.
skipping to change at page 13, line 5 skipping to change at page 13, line 11
11. The calculated digest is compared to the received digest stored 11. 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.
12. The ZONEMD RR's RDATA is reset to the received Digest Type and 12. 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
If multiple digests are present in the zone, e.g., during an
algorithm rollover, at least one of the recipient's supported Digest
Type algorithms MUST verify the zone.
It is RECOMMENDED that implementations maintain a (possibly
configurable) list of supported Digest Type algorithms ranked from
most to least preferred. It is further RECOMMENDED that recipients
use only their most preferred algorithm that is present in the zone
for digest verification.
As a matter of local policy, the recipient MAY require that all
supported and present Digest Type algorithms verify the zone.
5. Scope of Experimentation 5. Scope of Experimentation
This memo is published as an Experimental RFC. The purpose of the This memo is published as an Experimental RFC. The purpose of the
experimental period is to provide the community time to analyze and experimental period is to provide the community time to analyze and
evaluate to the methods defined in this document, particularly with evaluate the methods defined in this document, particularly with
regard to the wide variety of DNS zones in use on the Internet. regard to the wide variety of DNS zones in use on the Internet.
Additionally, the ZONEMD record defined in this document includes a Additionally, the ZONEMD record defined in this document includes a
Reserved field in the form of an 8-bit integer. The authors have a Reserved field in the form of an 8-bit integer. The authors have a
particular future use in mind for this field, namely to support particular future use in mind for this field, namely to support
efficient digests in large, dynamic zones. We intend to conduct efficient digests in large, dynamic zones. We intend to conduct
future experiments using Merkle trees of varying depth. The choice future experiments using Merkle trees of varying depth. The choice
of tree depth can be encoded in this reserved field. We expect 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 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 bits of this field. This leaves another four bits available for
other future uses, if absolutely necessary. other future uses, if absolutely necessary.
FOR DISCUSSION: The authors are willing to remove the Reserved field
from this specification if the working group would prefer it. It
would mean, however, that a future version of this protocol designed
to efficiently support large, dynamic zones would most likely require
a new RR type.
The duration of the experiment is expected to be no less than two The duration of the experiment is expected to be no less than two
years from the publication of this document. If the experiment is years from the publication of this document. If the experiment is
successful, it is expected that the findings of the experiment will successful, it is expected that the findings of the experiment will
result in an updated document for Standards Track approval. result in an updated document for Standards Track approval.
6. IANA Considerations 6. IANA Considerations
6.1. ZONEMD RRtype 6.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
skipping to change at page 14, line 10 skipping to change at page 14, line 26
Meaning: Message Digest Over Zone Data Meaning: Message Digest Over Zone Data
Reference: This document Reference: This document
6.2. ZONEMD Digest Type 6.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 | Status | Reference | | Value | Description | Status | Reference |
+-------+-------------+-----------+-----------+ +---------+-------------+-----------+-----------+
| 1 | SHA384 | Mandatory | [RFC6605] | | 1 | SHA384 | Mandatory | [RFC6605] |
+-------+-------------+-----------+-----------+ | 240-254 | Private Use | | [RFC8126] |
+---------+-------------+-----------+-----------+
Table 1: ZONEMD Digest Types Table 1: ZONEMD Digest Types
7. Security Considerations 7. Security Considerations
7.1. Attacks Against the Zone Digest 7.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.
skipping to change at page 15, line 15 skipping to change at page 15, line 31
8. Privacy Considerations 8. Privacy Considerations
This specification has no impacts on user privacy. This specification has no impacts 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, Olafur Gudmundsson, Additionally, they thank Joe Abley, Mark Andrews, Olafur Gudmundsson,
Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Burt Kaliski, Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Burt Kaliski,
Shane Kerr, Matt Larson, John Levine, Ed Lewis, Mukund Sivaraman, Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund
Petr Spacek, Ondrej Sury, Florian Weimer, Tim Wicinksi, Paul Wouters, Sivaraman, Petr Spacek, Ondrej Sury, Florian Weimer, Tim Wicinksi,
and other members of the dnsop working group for their input. Paul Wouters, and other members of the dnsop working group for their
input.
10. Implementation Status 10. Implementation Status
10.1. Authors' Implementation 10.1. Authors' Implementation
The authors have an open source implementation in C, using the ldns The authors have an open source implementation in C, using the ldns
library [ldns-zone-digest]. This implementation is able to perform library [ldns-zone-digest]. This implementation is able to perform
the following functions: the following functions:
o Read an input zone and output a zone with the ZONEMD placeholder. o Read an input zone and output a zone with the ZONEMD placeholder.
skipping to change at page 18, line 25 skipping to change at page 18, line 39
o IANA Considerations section now more specific. o IANA Considerations section now more specific.
o Added complex zone to examples. o Added complex zone to examples.
o o
From -05 to -06: From -05 to -06:
o RR type code 63 was assigned to ZONEMD by IANA. o RR type code 63 was assigned to ZONEMD by IANA.
From -06 to -07:
o Fixed mistakes in ZONEMD examples.
o Added private use Digest Type values 240-254.
o Clarified that Digest field must not be empty.
From -07 to draft-ietf-dnsop-dns-zone-digest-00:
o Adopted by dnsop.
o Clarified further that non-apex ZONEMD RRs have no meaning.
o Changed "provably [un]signed" to "provably [in]secure".
o Allow multiple ZONEMD RRs to support algorithm agility/rollovers.
o Describe verification when there are multiple ZONEMD RRs.
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 20, line 28 skipping to change at page 21, line 14
[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>.
[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
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<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 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <https://www.rfc-editor.org/info/rfc7719>. 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
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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/ June 2018, <https://tools.ietf.org/html/
draft-vixie-dnsop-dns-rpz-00>. draft-vixie-dnsop-dns-rpz-00>.
[ZoneDigestHackathon] [ZoneDigestHackathon]
Kerr, S., "Prototype implementation of ZONEMD for the IETF Kerr, S., "Prototype implementation of ZONEMD for the IETF
102 hackathon in Python", July 2018, 102 hackathon in Python", July 2018,
<https://github.com/shane-kerr/ZoneDigestHackathon>. <https://github.com/shane-kerr/ZoneDigestHackathon>.
Appendix A. Example Zones With Digests Appendix A. Example Zones With Digests
This appendex contains example zones with accurate ZONEMD records. This appendix contains example zones with accurate ZONEMD records.
These can be used to verify an implementation of the zone digest These can be used to verify an implementation of the zone digest
protocol. protocol.
A.1. Simple EXAMPLE Zone A.1. Simple EXAMPLE Zone
Here, the EXAMPLE zone contains an SOA record, NS and glue records, Here, the EXAMPLE zone contains an SOA record, NS and glue records,
and a ZONEMD record. and a ZONEMD record.
example. 86400 IN SOA ns1 admin 2018031900 ( example. 86400 IN SOA ns1 admin 2018031900 (
1800 900 604800 86400 ) 1800 900 604800 86400 )
86400 IN NS ns1 86400 IN NS ns1
86400 IN NS ns2 86400 IN NS ns2
86400 IN ZONEMD 2018031900 1 0 ( 86400 IN ZONEMD 2018031900 1 0 (
f32765ce15c50477 379ec2587d4fff35
42a08be15d9a0efb 0062b9385a641476
749417eaadcfa28b 6f9c028e8cf09d8a
1bf751b6bc49f9be 7965537a68a2f149
a615c4a386cfd6a5 4e1c151f8cf6be05
d85e2d2182691249 ) 5bef4f27e6a87b13 )
ns1 3600 IN A 127.0.0.1 ns1 3600 IN A 127.0.0.1
ns2 3600 IN AAAA ::1 ns2 3600 IN AAAA ::1
A.2. Complex EXAMPLE Zone A.2. Complex EXAMPLE Zone
Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR, Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR,
and one out-of-zone RR. and one out-of-zone RR.
example. 86400 IN SOA ns1 admin 2018031900 ( example. 86400 IN SOA ns1 admin 2018031900 (
1800 900 604800 86400 ) 1800 900 604800 86400 )
86400 IN NS ns1 86400 IN NS ns1
86400 IN NS ns2 86400 IN NS ns2
86400 IN ZONEMD 2018031900 1 0 ( 86400 IN ZONEMD 2018031900 1 0 (
686a6d74d5638612 c36e77eafdb7f3f6
64ea4e6cc12c22d1 dcfac8bca1121e17
7ebc529791d393bd 2a7b57db2c88409a
e164a45390f714e9 5c3d9247ba72b759
9ede0d05a5644573 6c735c1a76fc817a
da4bbcc83744acf2 ) ad5c834f5a4bce16 )
ns1 3600 IN A 127.0.0.1 ns1 3600 IN A 127.0.0.1
ns2 3600 IN AAAA ::1 ns2 3600 IN AAAA ::1
occluded.sub 7200 IN TXT "I'm occluded but must be digested" occluded.sub 7200 IN TXT "I'm occluded but must be digested"
sub 7200 IN NS ns1 sub 7200 IN NS ns1
duplicate 300 IN TXT "I must be digested just once" duplicate 300 IN TXT "I must be digested just once"
duplicate 300 IN TXT "I must be digested just once" duplicate 300 IN TXT "I must be digested just once"
foo.test. 555 IN TXT "out-of-zone data must be excluded" foo.test. 555 IN TXT "out-of-zone data must be excluded"
non-apex 900 IN ZONEMD 2018031900 1 0 (
616c6c6f77656420
6275742069676e6f
7265642e20616c6c
6f77656420627574
2069676e6f726564
2e20616c6c6f7765 )
A.3. The URI.ARPA Zone A.3. The URI.ARPA Zone
The URI.ARPA zone retreived 2018-10-21. The URI.ARPA zone retrieved 2018-10-21.
; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr ; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr
; (2 servers found) ; (2 servers found)
;; global options: +cmd ;; global options: +cmd
uri.arpa. 3600 IN SOA sns.dns.icann.org. ( uri.arpa. 3600 IN SOA sns.dns.icann.org. (
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 ( uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 (
20181028142623 20181007205525 47155 uri.arpa. 20181028142623 20181007205525 47155 uri.arpa.
eEC4w/oXLR1Epwgv4MBiDtSBsXhqrJVvJWUpbX8XpetAvD35bxwNCUTi eEC4w/oXLR1Epwgv4MBiDtSBsXhqrJVvJWUpbX8XpetAvD35bxwNCUTi
/pAJVUXefegWeiriD2rkTgCBCMmn7YQIm3gdR+HjY/+o3BXNQnz97f+e /pAJVUXefegWeiriD2rkTgCBCMmn7YQIm3gdR+HjY/+o3BXNQnz97f+e
skipping to change at page 25, line 19 skipping to change at page 26, line 26
NSEC ) NSEC )
urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
"/urn:([^:]+)/\\1/i" . ) "/urn:([^:]+)/\\1/i" . )
uri.arpa. 3600 IN SOA sns.dns.icann.org. ( uri.arpa. 3600 IN SOA sns.dns.icann.org. (
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
;; Query time: 66 msec ;; Query time: 66 msec
;; SERVER: 192.0.32.132#53(192.0.32.132) ;; SERVER: 192.0.32.132#53(192.0.32.132)
;; WHEN: Sun Oct 21 20:39:28 UTC 2018 ;; WHEN: Sun Oct 21 20:39:28 UTC 2018
;; XFR size: 34 records (messages 1, bytes 3941) ;; XFR size: 34 records (messages 1, bytes 3941)
uri.arpa. 3600 IN ZONEMD 2018100702 1 0 ( uri.arpa. 3600 IN ZONEMD 2018100702 1 0 (
80af7afd9540ff2c4c559f0d2b83393386304e093e0e66787378b2 e4de6ed36e5d95706756932fae3ecbc6aeb76e16ce486a5553c7e4
a578297b49b4dccb422bce2c300bb92b354575283a ) c9974d03323e7cd39ccc5e70e797179633f4007bad )
A.4. The ROOT-SERVERS.NET Zone A.4. The ROOT-SERVERS.NET Zone
The ROOT-SERVERS.NET zone retreived 2018-10-21. The ROOT-SERVERS.NET zone retreived 2018-10-21.
root-servers.net. 3600000 IN SOA a.root-servers.net. ( root-servers.net. 3600000 IN SOA a.root-servers.net. (
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
root-servers.net. 3600000 IN NS a.root-servers.net. root-servers.net. 3600000 IN NS a.root-servers.net.
root-servers.net. 3600000 IN NS b.root-servers.net. root-servers.net. 3600000 IN NS b.root-servers.net.
root-servers.net. 3600000 IN NS c.root-servers.net. root-servers.net. 3600000 IN NS c.root-servers.net.
skipping to change at page 26, line 51 skipping to change at page 27, line 51
j.root-servers.net. 3600000 IN A 192.58.128.30 j.root-servers.net. 3600000 IN A 192.58.128.30
k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1
k.root-servers.net. 3600000 IN A 193.0.14.129 k.root-servers.net. 3600000 IN A 193.0.14.129
l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42
l.root-servers.net. 3600000 IN A 199.7.83.42 l.root-servers.net. 3600000 IN A 199.7.83.42
m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35
m.root-servers.net. 3600000 IN A 202.12.27.33 m.root-servers.net. 3600000 IN A 202.12.27.33
root-servers.net. 3600000 IN SOA a.root-servers.net. ( root-servers.net. 3600000 IN SOA a.root-servers.net. (
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
root-servers.net. 3600000 IN ZONEMD 2018091100 1 0 ( root-servers.net. 3600000 IN ZONEMD 2018091100 1 0 (
aadf7a017bccd8cefe6040494800249fd5edc3d49e2e8ce8db7522f47f 0c1839d86088062868c1ed79aed6a301dc7b08b02ba2f67cbc62edd4a0
97f168db794bf5f679fbe0c8433fb66f7a0c26 ) 291f4132b8840da47ddab4401cc9088d04a14a )
Authors' Addresses Authors' Addresses
Duane Wessels Duane Wessels
Verisign Verisign
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: dwessels@verisign.com Email: dwessels@verisign.com
 End of changes. 42 change blocks. 
82 lines changed or deleted 140 lines changed or added

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