Early Review of draft-ietf-dnsop-cds-consistency-05
review-ietf-dnsop-cds-consistency-05-dnsdir-early-mevzek-2025-04-08-00

I agree with previous dnsdir review of version 03 at
https://mailarchive.ietf.org/arch/msg/dnsdir/fylDZkZJo58eRV_eL7UqxI2fccE
including that the document clearly lays out the motivation of the change and
what specific change is needed.

The issue raised by previous review about CSYNC processing changes, specially
regarding glues, seems to me to have been fixed in version 04 (with an extra
paragraph in now §3.2) and hence in this review of version 05.

I would add one concern/question though:

- §3
My reading is that, after some retries, unreachable nameserver can be removed
from consideration, and then all processing continues with the results of the
reachable nameservers. If this is correct understanding of document, it allows
someone to hijack the change as soon as it controls one nameserver (or queries
towards it) and can make the other ones unreachable. Shouldn't instead the
processing require all nameservers to be reachable? A mix of
reachable/unreachable should be considered an inconsistent state.

I agree that this situation could happen such as the use of CSYNC is attempted
to solve it. But I believe in this case that operator/owner should go back to
the usual path of pushing nameserver changes through the registrar, to at least
remove the unreachable nameserver from the set, and then attempt CSYNC back if
desired.

Sorry if that point was already discussed in the past.

Nitpicks:

- care was taken to always mention DS and DNSKEY together, except in this
sentence: "each nameserver can unilaterally trigger an update of the
delegation's DS or NS record set."; another solution would be, as some other
documents do, to specify at the beginning that "DS" means "DS or DNSKEY"
throughout the whole document, and then there is no need to repeat it.

- §3.2
"(preferably in the same connection)." What does connection mean in a DNS
context? RFC7477 also don't mention that. RFC8499 on DNS terminology doesn't
define this concept.

- "As a consequence, the delegation's records can only be modified when
zonefiles are synchronized": zones instead of zonefiles?

PS: any thoughts about mentioning RFC9567 and using that mechanism for the
operator to signal back to nameservers that some inconsistent state was
discovered that prevented the processing of some CDS/CDNSKEY/CSYNC records
found?