On Wed, 19 Nov 2025, Mike Bishop via Datatracker wrote:

Thanks for the work on this draft. I have one DISCUSS point that I think will
help improve the draft and is (hopefully) easily addressed.

In Section 3.2, we see the following text:

CSYNC-based updates may cause validation or even insecure resolution to break
(e.g., by changing the delegation to a set of nameservers that do not serve
required DNSKEY records or do not know the zone at all). Parental Agents SHOULD
check that CSYNC-based updates, if applied, do not break the delegation.

Is there a definition of how the Parental Agent "check[s] that ... updates ...
do not break the delegation"? I would have expected a more concrete instruction
here, such as repeating the same queries on the proposed delegation targets and
ensuring that they, too, return records consistent with what was found on the
existing nameservers. Perhaps this already exists somewhere and a reference is
sufficient?

No there isn't, and one would have expected one in
https://datatracker.ietf.org/doc/html/rfc7477#section-5

The closest it comes is:

   Additionally, this specification was not
   designed to synchronize DNSSEC security records, such as DS pointers,
   or the CSYNC record itself.  Thus, implementations of this protocol
   MUST NOT use it to synchronize DS records, DNSKEY materials, CDS
   records, CDNSKEY records, or CSYNC records.

But as this document says, one could be changing NS records pointing to
nameservers that dont have data signed with the current DNSKEYs
expected.

A parent would typically check this by pushing the updated NS glue into
a copy of their zone, then load that into a fresh new cache and try to
resolve with DNSSEC enabled. But doing that properly to test each NS
would require repeating this test with only the "NS record under test"
pointed to the new value. It would also need to confirm the NS records
with DNSSEC (and not skip validating these based on unsigned parental NS
records). It is .... complex.

Paul

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to