Hi Ondřej,
On 7/11/25 17:35, Peter Thomassen wrote:
The appendix A.1. describes an impossible failure scenario, considering that
Section 6.2 of RFC 7344 says that:
> The Parental Agent MUST ensure that previous versions of the CDS/
> CDNSKEY RRset do not overwrite more recent versions.
With this MUST in place, the scenario described in A.1. just cannot happen. It
is not a big deal, but seeing it written like this is implying that this risk
was not considered when writing RFC 7344, which is not the case.
You are correct. That failure scenario only occurs when not tracking "previous" vs.
"new" CDS/CDNSKEY RRset. And I've just checked: there's at least one registry that makes
a reasonable attempt at this sort of tracking.
I thus agree with you that Appendix A.1 can then be removed. I'll note that
down for the next update after the submission window opens again.
[...]
The cross-nameserver consistency checks from this can catch such replication
issues (but also things beyond, such as multi-signer misalignment). With
consistency checks in place, I'm thus wondering whether inception/serial state
tracking on the parent side adds much value, or can be relaxed from MUST to
SHOULD or MAY. What do you think?
I thought about this again, and realized that there's nothing to change in RFC
7344, because the consistency checks actually fulfill the MUST of RFC 7344
Section 6.2. It's just another way of doing it, and the particular way of doing
it is not covered by the MUST: the method proposed there is specifically MAY.
I thus retract my proposal update this aspect of RFC 7344.
As for removing Appendix A.1, I think it's worth pointing out that this draft
is one way of handling this problem, with RFC 7344's requirement in mind. I'm
thus proposing to change the language as follows:
OLD
be deployed in an alternating fashion. The zone maintainer, having
detected that the DS deployment was successful, may then confidently
remove the old DNSKEY from the zone, only to find out later that the
DS RRset has been turned back, breaking the delegation's DNSSEC chain
of trust.
Checking for consistency minimizes this risk. In case the parent
reports consistency errors downstream, it can also help detect the
replication issue on the child side.
NEW
be deployed in an alternating fashion and without the awareness of
the zone maintainer, who may then inadvertently break the chain of
trust by prematurely removing a DNSKEY still referenced by a (stale)
CDS/CDNSKEY RRset.
While foreseen in [RFC7344] Section 6.2, the solution suggested there
requires parents to keep state on CDS/CDNSKEY RRsets. This document
achieves the same without this burden, and in case the parent reports
consistency errors downstream, can also help detection of the child-
side replication issue by the operator.
Please let me know in case that doesn't work for you, or if you have any other
thoughts/suggestions.
I'm planning to upload the a revision at the end of the week.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
