draft-ietf-dnsop-dns-zone-digest-11.txt   draft-ietf-dnsop-dns-zone-digest-12.txt 
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft P. Barber Internet-Draft P. Barber
Intended status: Standards Track Verisign Intended status: Standards Track Verisign
Expires: March 29, 2021 M. Weinberg Expires: April 2, 2021 M. Weinberg
Amazon Amazon
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
September 25, 2020 September 29, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-11 draft-ietf-dnsop-dns-zone-digest-12
Abstract Abstract
This document describes a protocol and new DNS Resource Record that This document describes a protocol and new DNS Resource Record that
provides a cryptographic message digest over DNS zone data. The provides a cryptographic message digest over DNS zone data. The
ZONEMD Resource Record conveys the digest data in the zone itself. ZONEMD Resource Record conveys the digest data in the zone itself.
When a zone publisher includes a ZONEMD record, recipients can verify When a zone publisher includes a ZONEMD record, recipients can verify
the zone contents for accuracy and completeness. This provides the zone contents for accuracy and completeness. This provides
assurance that received zone data matches published data, regardless assurance that received zone data matches published data, regardless
of how the zone data has been transmitted and received. 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 March 29, 2021. This Internet-Draft will expire on April 2, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11 3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11
3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11
3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12 3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12
3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14
5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 16 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 16
6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16 6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16
6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16 6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16
6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 17 6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 17
7. Performance Considerations . . . . . . . . . . . . . . . . . 17 7. Performance Considerations . . . . . . . . . . . . . . . . . 17
7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 28
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 28
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 28 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 28
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 29 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 29
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 30
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 33
Appendix B. Implementation Status . . . . . . . . . . . . . . . 34 Appendix B. Implementation Status . . . . . . . . . . . . . . . 35
B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34 B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 35
B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34 B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 35
B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35 B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
In the DNS, a zone is the collection of authoritative resource In the DNS, a zone is the collection of authoritative resource
records (RRs) sharing a common origin ([RFC8499]). Zones are often records (RRs) sharing a common origin ([RFC8499]). Zones are often
stored as files in the so-called master file format [RFC1034]. Zones stored as files in the so-called master file format [RFC1034]. Zones
are generally distributed among name servers using the AXFR (zone are generally distributed among name servers using the AXFR (zone
transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995]) transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995])
protocols. They can also be distributed outside of the DNS, with any protocols. They can also be distributed outside of the DNS, with any
file transfer protocol such as FTP, HTTP, and rsync, or even as email file transfer protocol such as FTP, HTTP, and rsync, or even as email
skipping to change at page 8, line 10 skipping to change at page 8, line 10
This section describes the ZONEMD Resource Record, including its This section describes the ZONEMD Resource Record, including its
fields, wire format, and presentation format. The Type value for the fields, wire format, and presentation format. The Type value for the
ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
the resource record consists of four fields: Serial, Scheme, Hash the resource record consists of four fields: Serial, Scheme, Hash
Algorithm, and Digest. Algorithm, and Digest.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility A zone MAY contain multiple ZONEMD RRs to support algorithm agility
[RFC7696] and rollovers. When multiple ZONEMD RRs are present, each [RFC7696] and rollovers. When multiple ZONEMD RRs are present, each
must specify a unique Scheme and Hash Algorithm tuple. It is must specify a unique Scheme and Hash Algorithm tuple. It is
recommended that a zone include only one ZONEMD RR, unless the zone RECOMMENDED that a zone include only one ZONEMD RR, unless the zone
publisher is in the process of transitioning to a new Scheme or Hash publisher is in the process of transitioning to a new Scheme or Hash
Algorithm. Algorithm.
2.1. Non-apex ZONEMD Records 2.1. Non-apex ZONEMD Records
This document specifies ZONEMD RRs located at the zone apex. Non- This document specifies ZONEMD RRs located at the zone apex. Non-
apex ZONEMD RRs are not forbidden, but have no meaning in this apex ZONEMD RRs are not forbidden, but have no meaning in this
specification. Non-apex ZONEMD RRs MUST NOT be used for specification. Non-apex ZONEMD RRs MUST NOT be used for
verification. verification.
skipping to change at page 9, line 5 skipping to change at page 8, line 50
/ / / /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.1. The Serial Field 2.2.1. The Serial Field
The Serial field is a 32-bit unsigned integer in network byte order. The Serial field is a 32-bit unsigned integer in network byte order.
It is the serial number from the zone's SOA record ([RFC1035] section It is the serial number from the zone's SOA record ([RFC1035] section
3.3.13) for which the zone digest was generated. 3.3.13) for which the zone digest was generated.
It is included here in order to make DNS response messages of type It is included here to clearly bind the ZONEMD RR to a particular
ZONEMD meaningful. Without the serial number, a stand-alone ZONEMD version of the zone's content. Without the serial number, a stand-
digest has no association to any particular instance of a zone. alone ZONEMD digest has no obvious association to any particular
instance of a zone.
2.2.2. The Scheme Field 2.2.2. The Scheme Field
The Scheme field is an 8-bit unsigned integer that identifies the The Scheme field is an 8-bit unsigned integer that identifies the
methods by which data is collated and presented as input to the methods by which data is collated and presented as input to the
hashing function. hashing function.
Herein, SIMPLE, with value 1, is the only standardized Scheme defined Herein, SIMPLE, with value 1, is the only standardized Scheme defined
for ZONEMD records and it MUST be implemented. The Scheme registry for ZONEMD records and it MUST be implemented. The Scheme registry
is further described in Section 5. is further described in Section 5.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
algorithm rollover, each MUST specify a unique Scheme and Hash algorithm rollover, each MUST specify a unique Scheme and Hash
Algorithm tuple. Algorithm tuple.
It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of
the SOA. However, the TTL of the ZONEMD record may be safely ignored the SOA. However, the TTL of the ZONEMD record may be safely ignored
during verification in all cases. during verification in all cases.
In the placeholder record, the Serial field is set to the current SOA In the placeholder record, the Serial field is set to the current SOA
Serial. The Scheme field is set to the value for the chosen Serial. The Scheme field is set to the value for the chosen
collation scheme. The Hash Algorithm field is set to the value for collation scheme. The Hash Algorithm field is set to the value for
the chosen hash algorithm. Since ZONEMD records are excluded from the chosen hash algorithm. Since apex ZONEMD records are excluded
digest calculation, the value of the Digest field does not matter at from digest calculation, the value of the Digest field does not
this point in the process. matter at this point in the process.
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. When the digest calculation is complete, and the ZONEMD with DNSSEC. When the digest calculation is complete, and the ZONEMD
record is updated, the signature(s) for the ZONEMD RRSet MUST be record is updated, the signature(s) for the ZONEMD RRSet MUST be
recalculated and updated as well. Therefore, the signer is not recalculated and updated as well. Therefore, the signer is not
required to calculate a signature over the placeholder record at this required to calculate a signature over the placeholder record at this
step in the process, but it is harmless to do so. step in the process, but it is harmless to do so.
skipping to change at page 12, line 9 skipping to change at page 12, line 9
exclusion rules apply: exclusion rules apply:
o All records in the zone, including glue records, MUST be included. o All records in the zone, including glue records, MUST be included.
o Occluded data ([RFC5936] Section 3.5) MUST be included. o Occluded data ([RFC5936] Section 3.5) MUST be included.
o If there are duplicate RRs with equal owner, class, type, and o If there are duplicate RRs with equal owner, class, type, and
RDATA, only one instance is included ([RFC4034] Section 6.3), and RDATA, only one instance is included ([RFC4034] Section 6.3), and
the duplicates MUST be omitted. the duplicates MUST be omitted.
o The placeholder ZONEMD RR(s) MUST NOT be included. o The placeholder apex ZONEMD RR(s) MUST NOT be included.
o If the zone is signed, DNSSEC RRs MUST be included, except: o If the zone is signed, DNSSEC RRs MUST be included, except:
o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG o The RRSIG covering the apex ZONEMD RRSet MUST NOT be included
will be updated after all digests have been calculated. because the RRSIG will be updated after all digests have been
calculated.
3.3.1.2. SIMPLE Scheme Digest Calculation 3.3.1.2. SIMPLE Scheme Digest Calculation
A zone digest using the SIMPLE scheme is calculated by concatenating A zone digest using the SIMPLE scheme is calculated by concatenating
all RRs in the zone, in the format and order described in all RRs in the zone, in the format and order described in
Section 3.3.1 subject to the inclusion/exclusion rules described in Section 3.3.1 subject to the inclusion/exclusion rules described in
Section 3.3.1.1, and then applying the chosen hash algorithm: Section 3.3.1.1, and then applying the chosen hash algorithm:
digest = hash( RR(1) | RR(2) | RR(3) | ... ) digest = hash( RR(1) | RR(2) | RR(3) | ... )
skipping to change at page 14, line 4 skipping to change at page 14, line 4
does not support the given hash algorithm, verification MUST does not support the given hash algorithm, verification MUST
NOT be considered successful with this ZONEMD RR and it NOT be considered successful with this ZONEMD RR and it
SHOULD report that the RR's digest could not be verified due SHOULD report that the RR's digest could not be verified due
to an unsupported algorithm. to an unsupported algorithm.
D. The Digest field size MUST be checked. If the size of the D. The Digest field size MUST be checked. If the size of the
given Digest field is smaller than 12 octets, or if the size given Digest field is smaller than 12 octets, or if the size
is not equal to the size expected for the corresponding Hash is not equal to the size expected for the corresponding Hash
Algorithm, verification MUST NOT be considered successful Algorithm, verification MUST NOT be considered successful
with this ZONEMD RR and the verifier SHOULD report that the with this ZONEMD RR and the verifier SHOULD report that the
RR's digest could not be verified to to an incorrect digest RR's digest could not be verified due to an incorrect digest
length. length.
E. The zone digest is computed over the zone data as described E. The zone digest is computed over the zone data as described
in Section 3.3, using the Scheme and Hash Algorithm for the in Section 3.3, using the Scheme and Hash Algorithm for the
current ZONEMD RR. current ZONEMD RR.
F. The computed digest is compared to the received digest. If F. The computed digest is compared to the received digest. If
the two digest values match, verification is considered the two digest values match, verification is considered
successful. Otherwise, verification MUST NOT be considered successful. Otherwise, verification MUST NOT be considered
successful for this ZONEMD RR. successful for this ZONEMD RR.
skipping to change at page 15, line 47 skipping to change at page 15, line 47
| 2 | SHA-512 | SHA512 | SHOULD | [this | | 2 | SHA-512 | SHA512 | SHOULD | [this |
| | | | | document] | | | | | | document] |
| 3-239 | Unassigned | | | | | 3-239 | Unassigned | | | |
| 240-254 | Private Use | N/A | N/A | [his | | 240-254 | Private Use | N/A | N/A | [his |
| | | | | document] | | | | | | document] |
| 255 | Reserved | | | | | 255 | Reserved | | | |
+---------+-------------+----------+-------------------+------------+ +---------+-------------+----------+-------------------+------------+
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.
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 recipient of a zone to verify its The zone digest allows the recipient of a zone to verify its
integrity. In conjunction with DNSSEC, the recipient can integrity. In conjunction with DNSSEC, the recipient can
authenticate that it is as published by the zone originator. authenticate that it is as published by the zone originator.
An attacker, whose goal is to modify zone content before it is used An attacker, whose goal is to modify zone content before it is used
by the victim, may consider a number of different approaches. by the victim, may consider a number of different approaches.
The attacker might perform a downgrade attack to an unsigned zone. The attacker might perform a downgrade attack to an unsigned zone.
skipping to change at page 16, line 37 skipping to change at page 16, line 34
DNSSEC validation. DNSSEC validation.
6.2. DNSSESC Timing Considerations 6.2. DNSSESC Timing Considerations
As with all DNSSEC signatures, the ability to perform signature As with all DNSSEC signatures, the ability to perform signature
validation of a ZONEMD record is limited in time. If the DS validation of a ZONEMD record is limited in time. If the DS
record(s) or trust anchors for the zone to be verified are no longer record(s) or trust anchors for the zone to be verified are no longer
available, the recipient cannot validate the ZONEMD RRSet. This available, the recipient cannot validate the ZONEMD RRSet. This
could happen even if the ZONEMD signature is still current (not could happen even if the ZONEMD signature is still current (not
expired), since the zone's DS record(s) may have been withdrawn expired), since the zone's DS record(s) may have been withdrawn
following a KSK rollover. following a Key Signing Key (KSK) rollover.
For zones where it may be important to validate a ZONEMD RRSet For zones where it may be important to validate a ZONEMD RRSet
through its entire signature validity period, the zone operator through its entire signature validity period, the zone operator
should ensure that KSK rollover timing takes this into consideration. should ensure that KSK rollover timing takes this into consideration.
6.3. Attacks Utilizing ZONEMD Queries 6.3. 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. Servers SHOULD NOT servers from responding to, ZONEMD queries. Servers SHOULD NOT
calculate zone digests dynamically (for each query) as this can be calculate zone digests dynamically (for each query) as this can be
used as a CPU resource exhaustion attack. used as a CPU resource exhaustion attack.
ZONEMD responses could be used in a distributed denial-of-service ZONEMD responses could be used in a distributed denial-of-service
amplification attack. The ZONEMD RR is moderately sized, much like amplification attack. The ZONEMD RR is moderately sized, much like
the DS RR. A single ZONEMD RR contributes approximately 40 to 65 the DS RR. A single ZONEMD RR contributes approximately 65 to 95
octets to a DNS response, for digest types defined herein. Other RR octets to a DNS response, for digest types defined herein. Other RR
types, such as DNSKEY, can result in larger amplification effects. types, such as DNSKEY, can result in larger amplification effects.
6.4. Resilience and Fragility 6.4. Resilience and Fragility
ZONEMD is used to detect incomplete or corrupted zone data prior to ZONEMD is used to detect incomplete or corrupted zone data prior to
its use, thereby increasing resilience by not using corrupt data, but its use, thereby increasing resilience by not using corrupt data, but
also introduces some denial-of-service fragility by making good data also introduces some denial-of-service fragility by making good data
in a zone unavailable if some other data is missing or corrupt. in a zone unavailable if some other data is missing or corrupt.
Publishers and consumers of zones containing ZONEMD records should be Publishers and consumers of zones containing ZONEMD records should be
aware of these tradeoffs. While the intention is to secure the zone aware of these tradeoffs. While the intention is to secure the zone
data, misconfigurations or implementation bugs are generally data, misconfigurations or implementation bugs are generally
indistinguishable from intentional tampering, and could lead to indistinguishable from intentional tampering, and could lead to
service failures when verification is performed automatically. service failures when verification is performed automatically.
Zone publishers may want to deploy ZONEMD gradually, perhaps by Zone publishers may want to deploy ZONEMD gradually, perhaps by
utilizing one of the private use hash algorithms listed in utilizing one of the private use hash algorithm code points listed in
Section 5.3. Similarly, recipients may want to initially configure Section 5.3. Similarly, recipients may want to initially configure
verification failures only as a warning, and later as an error after verification failures only as a warning, and later as an error after
gaining experience and confidence with the feature. gaining experience and confidence with the feature.
7. Performance Considerations 7. Performance Considerations
This section is provided to make zone publishers aware of the This section is provided to make zone publishers aware of the
performance requirements and implications of including ZONEMD RRs in performance requirements and implications of including ZONEMD RRs in
a zone. a zone.
skipping to change at page 24, line 40 skipping to change at page 24, line 40
o Fixed people's names in the acknowledgments section (blush) o Fixed people's names in the acknowledgments section (blush)
o Say "has not been modified between origination and retrieval." o Say "has not been modified between origination and retrieval."
o Say that ZONEMD TTL doesn't matter during verification. o Say that ZONEMD TTL doesn't matter during verification.
o Further clarification that the SHA-384 and SHA-512 hashes are not o Further clarification that the SHA-384 and SHA-512 hashes are not
truncated. Future algs might be truncated, but never below 96 truncated. Future algs might be truncated, but never below 96
bits. bits.
From -11 to -12:
o SECDIR review: make "recommended" all caps.
o SECDIR review: tweak explanation of why ZONEMD RR has copy of SOA
serial.
o SECDIR review: be even more clear about apex ZONEMD RRs vs non-
apex.
o SECDIR review: Forgot to delete sentence about IANA policy for
adding new hash algorithms.
o SECDIR review: Spell out Key Signing Key first time.
o SECDIR review: say "private use hash algorithm code points."
o SECDIR review: Update estimates of ZONEMD RR size.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
 End of changes. 20 change blocks. 
34 lines changed or deleted 51 lines changed or added

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