[DNSOP] Re: Fwd: New Version Notification for draft-shetho-dnsop-ds-automation-00.txt

[Peter Thomassen <[e-mail]>]

Hi Oli,

On 6/25/25 09:09, Oli Schacher wrote:
> I agree with Matthew’s point that these may not always be 'best practices', but rather design decisions that depend on operational context.

Fair point, at least at this stage. I've changed the draft status to Informational.

> For example, the recommendation to send email notifications (Sections 2.2 and 3.2) did not prove practical for us at the .ch/li. registry. Based on on feedback from CZ.NIC and our own experience we concluded that this creates more confusion than benefit:
> 
> - The DNS operator is often not the registrant; registrants don’t understand these mails.
> - Bulk DNSSEC rollouts by large operators would generate massive amounts of email — effectively spam.
> - DNSSEC failure can prevent mail delivery to the registrant’s own domain.
> - Registries generally don’t have reliable contact info for DNS operators (SOA RNAME is not reliable).
> - The error reporting logic (thresholds, cooldowns) requires significant state tracking.
> - Many DNS errors (lame delegations, APEX CNAMEs, ...) are not directly related to DS automation but could still trigger mail in this context.
> 
> We instead opted for a pull-based status portal, which avoids these issues.

Those are good observations, and indeed those things might make email-based reporting impractical. Pull-based, OTOH, does not address situations where there is an "active need" to know.

Perhaps, if this gets agenda time in Madrid and/or if the draft is adopted, we can see if we can think a little harder about this problem. Maybe there are ways nobody is thinking of.

> Sections 2.5 and 3.5 suggest that registries scan and compare both CDS and CDNSKEY. While I agree that DNS operators should publish both and ensure they match, I don’t think registries should be required to query both. This increases the query load and processing without providing meaningful additional validation. Or is there a scenario where a CDS/CDNSKEY mismatch could break anything that is not handled by the existing validation requirements?

Of course, one can imagine all kinds of bugs. For example, in a multi-provider setup, child-side signers have to co-publish each other's CDS/CDNSKEY records (or KSKs, and then derive the C* stuff). Depending on how that's done and who publishes what, one can end up with inconsistencies across the two types of RRsets. It's then certainly clear that neither the CDS nor the CDNSKEY "half of it" represents the domain holder's intent.

But I admit this is somewhat constructed, and only caters to the most conservative perspective on DS updates. But, DNSSEC reputation suffers a lot from outages caused by misconfigurations, so there's some justification for being in the conservative camp. But not sure myself.

That said, the query / processing load is expected to change only insignificantly. Although in a way it "doubles", that's *only* when there is a change. This is the same as with cross-auth consistency checking: if the first query confirms the status quo, no further queries need to be made. That is, only in the "tail of rare changes" is the load increased.

Thought experiment: If for 98% of the zones, the first query confirms "no change", then the other 2% percent might get 2 CDS queries (on per NS), and -- with this recommendation -- two more CDNSKEY queries. That increases the overall load of the system by less than 2%.

Best,
Peter

-- 
https://desec.io/