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.

Best regards,

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 
> directories.
> 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
> Abstract:
>    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
>    point.
>    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:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-04
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-04
> 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

DNSOP mailing list

Reply via email to