Hi Mike, On 12/3/25 20:36, Mike Bishop wrote:
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).
Thanks! See below.
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.
In the case of CDS/CDNSKEY, no nameservers are being proposed (that's CSYNC). But indeed, with trust chain updates signaled via CDS/CDNSKEY, continued validatability should be ensured. That's already mandatory today, but no details are specified. I'll make sure this point gets considered via draft-ietf-dnsop-ds-automation.
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."
That sounds reasonable to me.
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.)
When take that into account when I submit the updated revision.
> 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.
I see. CSYNC indicates that a change is desired, and the new nameservers would not immediately desire a change. Requiring them to publish a CSYNC RRset would be a semantics change, which is not in scope for this draft. Best, Peter _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
