Sorry for the delay, I've been away over US Thanksgiving. Further comments below, but I think the fact that this is being addressed in another WG draft satisfies the DISCUSS (though I'd recommend some expanded text and/or an informative reference here, even so).
________________________________ From: Peter Thomassen <[email protected]> Sent: Tuesday, November 25, 2025 7:58 AM 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, On 11/21/25 22:03, Mike Bishop wrote: > > 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 agree it's frustrating that this was specified quite vaguely in RFC 7344, and also that it would be good if the process was spelled out in more detail. I'm not sure whether you meant to say that it should be spelled out here, or elsewhere. Note, however, that the focus of this draft is requiring consistency across child authoritative nameservers. While non-breakage checks at the parent are a reasonable thing to do, they have nothing to do with that consistency requirement. Ideally, the non-breakage requirement would, in my view, even apply to manual DS provisioning (but I guess that's debatable.) There's another draft (draft-ietf-dnsop-ds-automation) which deals with DS provisioning aspects much more broadly. Among other things, it references the CDS consistency document as one thing that needs to be taken into account. Another thing is the non-breakage aspect, which is spelled out more explicitly there (Section 2.2.1). I think refining that definition there would be a better place, both scope-wise and for visibility. If you agree, I'd appreciate your feedback that particular section in draft-ietf-dnsop-ds-automation. [MB] I think it is a consistency issue, in that it's requiring consistency between the nameservers being proposed and the nameservers doing the proposing. That is, it's checking that the system would remain consistent if the updates were performed. I'm glad to see that it's already being considered. I've looked at Section 2.2.1 of that draft, and it's a good bit closer. I think what we ultimately want is something like "SHOULD synthesize the new NS, DS, and other records which would be applied if the update were accepted, then verify the existence and valid signature of the DNSKEY record on each nameserver referenced by an NS record in the new set." I'm fine clearing the DISCUSS since it's being handled by another draft in-progress, but an informative reference might be useful. (It can't be normative without blocking this draft, but it's okay to informatively reference a strategy one could use to approach this requirement.) > > 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 I'm not sure what you mean by that or why that would be a problem. If subsequent runs lead to several updates which each satisfy consistency and non-breakage, then that's a valid sequence to apply. [MB] My concern was about loops — suppose the new nameservers had records which consistently told you to update back to the old nameservers, which consistently tell you to update to the new nameservers, which.... It's entirely possible that there's already sufficient protection against that though the mechanisms in Section 6.2 of RFC 7344, though. > or start failing due to inconsistencies; That can't happen, because in case the CSYNC/CDS/CDNSKEY records used in the first sync were inconsistent, the update would not have been applied in the first case. (And if they were consistent, I'm not sure what you mean with "start failing due to inconsistencies".) [MB] Consider a case where two nameservers publish CSYNC records adding a third NS record. However, that third nameserver publishes a conflicting CSYNC record. Once the update occurs, future update passes will find an inconsistent state. It might be nice to require that the target servers also publish CSYNC/CDS/CDNSKEY records which are consistent with the updates that cause them to receive the delegation. However, given that any inconsistency causes no change to occur, that's probably not critical — the system errs on the side of not making any further changes until the (new) nameservers all agree. > > ---------------------------------------------------------------------- > > 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. OK, then I'll leave it as is for simplicity. The RFC editor might apply stylistic changes anyway. Best, Peter
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
