Dear DNSOP, Following working group feedback on the -01 version, the draft has been updated to reflect the following changes:
1) Whereas previously the Digest Type field conveyed only the hashing algorithm to be used, now the Digest Type also conveys how the hash value is constructed from the zone data. The one defined hash algorithm SHA384 has been renamed to SHA384-STABLE to reflect that it designed for use on stable (or small) zones where it is not burdensome to recalculate the digest over the entire zone data each time. A future Digest Type might also use SHA384 for hashing, but further describe the use of hash trees or similar for efficient digests of large/dynamic zones. 2) What used to be known as the Reserved field is now known as the Parameter field. 3) The meaning of the Parameter field now depends on Digest Type. For SHA384-STABLE the Parameter field is not used and SHOULD always be zero, but for future digest types it will not necessarily be zero. 4) Fixed a leftover bug stating that multiple ZONEMD RRs were not allowed. Feedback welcome as always. DW > On Oct 28, 2019, at 2:17 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Message Digest for DNS Zones > Authors : Duane Wessels > Piet Barber > Matt Weinberg > Warren Kumari > Wes Hardaker > Filename : draft-ietf-dnsop-dns-zone-digest-02.txt > Pages : 29 > Date : 2019-10-28 > > Abstract: > This document describes an experimental protocol and new DNS Resource > Record that can be used to provide a message digest over DNS zone > data. The ZONEMD Resource Record conveys the message digest data in > the zone itself. When a zone publisher includes an ZONEMD record, > recipients can verify the zone contents for accuracy and > completeness. This provides assurance that received zone data > matches published data, regardless of how the zone data has been > transmitted and received. > > ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects > individual RRSets (DNS data with fine granularity), ZONEMD protects > protects a zone's data as a whole, whether consumed by authoritative > name servers, recursive name servers, or any other applications. > > As specified at this time, ZONEMD is not designed for use in large, > dynamic zones due to the time and resources required for digest > calculation. The ZONEMD record described in this document includes > fields reserved for future work to support large, dynamic zones. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
