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.
> 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.
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".)
> ----------------------------------------------------------------------
> 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]
