Thanks for this work — it’s very helpful to have the operational
considerations for DS automation written down in one place.
I agree with Matthew’s point that these may not always be 'best
practices', but rather design decisions that depend on operational context.
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.
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?
Best regards,
Oli
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
