Hi Patrick, Thanks for your review! :)
On 4/9/25 06:03, Patrick Mevzek via Datatracker wrote:
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.
This logic was added in draft-thomassen-dnsop-cds-consistency-01 after Viktor Dukhovni pointed out [1] during the DNSOP session at IETF 114 that the mechanism needs to accommodate unreachable servers to prevent getting stuck. At the time, everyone in the room seemed OK with this. [1]: https://datatracker.ietf.org/meeting/114/materials/minutes-114-dnsop-00 I'm cc'ing Viktor in case you'd like to reconsider this aspect (but w/o a discussion will assume you're OK).
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.
No; the mechanism is not for updating DNSKEY records sets. However, when a desire for updating DS records is expressed, this can be done via both CDS and CDNSKEY records, which is why *those* are always mentioned together.
- §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.
This was intended to encourage use of TCP, in the spirit of RFC 7477 Section 3.1 which says: [...] DNS over TCP SHOULD be used to avoid conversing with multiple nodes at an anycast address However, this is not an important requirement, as we're checking for consistency, and talking to different nodes may actually help identifying inconsistencies and prevent premature application of an update. I don't think it would be reasonable to require checking all anycast nodes (and there's also no way to do that), but conversely I'm now convinced there's no point in trying to attach to a particular one. As a result, I've removed the words you quoted.
- "As a consequence, the delegation's records can only be modified when zonefiles are synchronized": zones instead of zonefiles?
Good point! I've fixed that, and also two other occurrences of the same in the Appendix.
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?
That's an interesting consideration. It would require the parent to receive responses annotated with the corresponding EDNS0 option and agent domain, but the child auth has no way of knowing that it should be adding that stuff (and it probably shouldn't be added for all apex CDS/CDNSKEY/CSYNC/NS/SOA/A/AAAA responses). So, additional signaling in the parent's query would be needed, which would add quite some complexity. Luckily, the same thing is achieved when the child informs the parent about desired C* updates via generalized DNS notifications (draft-ietf-dnsop-generalized-notify, now with the RFC editor): Section 4.2.1 of that document leverages RFC 9567 to provide the parent with a report channel in case the update process fails. In my view, introducing an error reporting capability at that level is sufficient. The above changes have been incorporated in -06 which I've just submitted. Best, Peter _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
