I read this again. I still wonder if in the case of DNSSEC Delete
Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is
0, the Digest/Public Key MUST be ignored.
This way, you don't have to change the CDS/CDNSKEY format defined in RFC
7344, most likely causing less problems with deployed software.
DNSOP mailing list
On 31-10-16 16:35, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> This draft is a work item of the Domain Name System Operations of the IETF.
> Title : Managing DS records from parent via CDS/CDNSKEY
> Authors : Olafur Gudmundsson
> Paul Wouters
> Filename : draft-ietf-dnsop-maintain-ds-04.txt
> Pages : 10
> Date : 2016-10-31
> RFC7344 specifies how DNS trust can be maintained across key
> rollovers in-band between parent and child. This document elevates
> RFC7344 from informational to standards track and adds a standard
> track method for initial trust setup and removal of secure entry
> Changing a domain's DNSSEC status can be a complicated matter
> involving multiple unrelated parties. Some of these parties, such as
> the DNS operator, might not even be known by all the organizations
> involved. The inability to disable DNSSEC via in-band signaling is
> seen as a problem or liability that prevents some DNSSEC adoption at
> large scale. This document adds a method for in-band signaling of
> these DNSSEC status changes.
> This document describes reasonable policies to ease deployment of the
> initial acceptance of new secure entry points (DS records)
> It is preferable that operators collaborate on the transfer or move
> of a domain. The best method is to perform a Key Signing Key ("KSK")
> plus Zone Signing Key ("ZSK") rollover. If that is not possible, the
> method using an unsigned intermediate state described in this
> document can be used to move the domain between two parties. This
> leaves the domain temporarily unsigned and vulnerable to DNS
> spoofing, but that is preferred over the alternative of validation
> failures due to a mismatched DS and DNSKEY record.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> 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:
> DNSOP mailing list
DNSOP mailing list