Inline with [MB]
________________________________
From: Peter Thomassen <[email protected]>
Sent: Wednesday, November 19, 2025 5:44 PM
To: Mike Bishop <[email protected]>; The IESG <[email protected]>
Cc: [email protected] <[email protected]>; [email protected]
<[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>
Subject: Re: [DNSOP] Mike Bishop's Discuss on
draft-ietf-dnsop-cds-consistency-09: (with DISCUSS and COMMENT)
Hi Mike,
Thank you for your review!
On 11/19/25 21:22, Mike Bishop via Datatracker wrote:
> Mike Bishop has entered the following ballot position for
> draft-ietf-dnsop-cds-consistency-09: Discuss
[...]> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 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"?
No. I noticed that the (even vague) requirement was missing for CSYNC
processing (as Paul pointed out), but there is a non-breakage requirement
defined for CDS/CDNSKEY processing in RFC 7344 Section 4.1. It simply reads:
o Continuity: MUST NOT break the current delegation if applied to DS
RRset.
My thinking was that it's reasonable to hold CSYNC to the same standard.
[MB] That's frustrating. I agree that the same standard of not breaking things
should apply here, but I'd like to see the process spelled out in a little more
detail.
> 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?
Not that I'm aware of, but something like that probably is reasonable. In
practice, I guess one would want to require that a compliant resolver does not
SERVFAIL, but either can validate stuff from the child, or considers it
insecure (when the DS record only advertises signing algorithms that are not
expected to be supported). Perhaps we should add something like that?
[MB] I was thinking more about a consistency check to ensure that pointing to
the new servers wouldn't then immediately cause you to point elsewhere the next
time you sync or start failing due to inconsistencies; checking that signing
also works correctly gets thorny, as Paul notes. But ideally, yes, that too
would be preferable.
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> One nit in the Abstract: "parent-side entities has to" => "parent-side
> entities are required to" or "the parent-side entity is required to"
The singular/plural problem had already been fixed in response to an earlier
review. Would you like me to change "have" to "are required to"?
[MB] Non-blocking comment; up to you. I'm fine either way.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
