Clarifications on CDS/CDNSKEY and CSYNC Consistency
draft-ietf-dnsop-cds-consistency-11

TL;DR: this ballot as no comment, only thank you messages

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-cds-consistency-09
CC @evyncke

Thank you for the work put into this document.

Special thanks to Ondřej Surý for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to David Blacka, the DNS directorate reviewer, and I have seen the author's reply:
https://datatracker.ietf.org/doc/review-ietf-dnsop-cds-consistency-09-dnsdir-lc-blacka-2025-10-23/

I hope that this review helps to improve the document,

Regards,

-éric

Please note that although RFC7344 was initially published as Informational, the status was changed since then to Standards Track (see https://datatracker.ietf.org/doc/status-change-rfc7344-from-informational-to-standards-track/)

I did not raise my comments to the level of DISCUSS, but it would be good to have a discussion
on these items. I do believe it is always better to insist on consistencies, hence not raising
these to discuss level.




      Readers are expected to be familiar with DNSSEC, including [RFC4033], [RFC4034], [RFC4035], [RFC7344], and [RFC7477], 

Note the canonical reference for DNSSEC these days is RFC9364. As that draft states:

   One purpose is to introduce all of the RFCs in one place so that the reader can understand
   the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose
   is to state that using DNSSEC for origin authentication of DNS data is the best current practice.
   A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.

So that seems to exactly match the use here.


   During initial DS provisioning (DNSSEC bootstrapping), conventional DNSSEC validation for
   CDS/CDNSKEY responses is not (yet) available; in this case, authenticated bootstrapping ([RFC9615])
   should be used.

Or a regular EPP method can be used instead of trying to bootstrap through DNS.



   who may then inadvertently break the chain of trust by prematurely removing a DNSKEY still referenced
   by a (stale) CDS/CDNSKEY RRset.

I am confused here. How can one "prematurely" remove a DNSKEY that is referenced by a (stale)
CDS/CDNSKEY ?? I think you mean "accidentally" remove a newly introduced DNSKEY that is not
referenced by a (stale) CDS/CDNSKEY?


   In particular, the rogue nameserver can publish CDS/CDNSKEY records. If those are processed
   by the parent without ensuring consistency with other authoritative nameservers, the
   delegation will, with some patience, get secured with the attacker's DNSSEC keys.

Note as per RFC7344 this cannot happen. CDS/CDNSKEY records MUST validate before being processed,
or covered via an alternative method:

   The following acceptance rules are placed on the CDS and CDNSKEY
      resource records as follows:

   o  Location: MUST be at the Child zone apex.

   o  Signer: MUST be signed with a key that is represented in both the
      current DNSKEY and DS RRsets, unless the Parent uses the CDS or
      CDNSKEY RRset for initial enrollment; in that case, the Parent
      validates the CDS/CDNSKEY through some other means (see
      Section 6.1 and the Security Considerations).

RFC9516 updates this but also requires another signal in that case:
https://datatracker.ietf.org/doc/html/rfc9615#signaling