Hi Ondřej,
On 7/10/25 16:03, Ondřej Caletka wrote:
I would just like to reiterate one more comment I have regarding this draft:
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.
In practice, however, tracking via RRSIG inception time is difficult. For
example, PowerDNS's inception times jump weekly, and within one week are all
the same. (In fact, inception is always 7-14 days in the past, and expiration
7-14 days in the future, so that the actual time is in the middle week of a
3-week validity period.)
Requiring "inception time > last DS update" in this case introduces 7-14 days
of additional waiting time for each rollover step. Of course, that's due to the way PowerDNS
handles things, but nevertheless it is a deployment reality. -- In addition, tracking of the
SOA serial is needed to disambiguate the inception time, which comes with its own set of
edge cases etc.
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?
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
