Document: draft-ietf-dnsop-cds-consistency Title: Clarifications on CDS/CDNSKEY and CSYNC Consistency Reviewer: Patrick Mevzek Review result: Ready with Nits
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? _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
