The registrar step is the manual, forgettable, outage-causing part of a KSK rollover. RFC 7344 removes it: publish what you want the parent to hold, in your own zone, signed — and let the parent read it.
The two records
CDS the DS record you want the parent to publish CDNSKEY the DNSKEY it would be derived from Both live in YOUR zone, at the apex, signed by your current key. The parent polls for them, validates the signature, and updates the delegation itself.
Publishing both is conventional — some parents consume one, some the other — and they must agree.
Why it is safe
- The records are signed by the key already trusted. A parent that validates them knows the request came from whoever holds the current key, which is the same authority that signs the zone.
- It cannot bootstrap. An unsigned zone has nothing to sign a CDS with, so the first
DSstill goes through the registrar. This automates rollovers, not initial signing. - Deletion has a defined form. A CDS with algorithm 0 and specific placeholder values asks the parent to remove the delegation’s
DSentirely — the supported way to go unsigned without a registrar ticket.
Support is the catch
The mechanism requires the parent to implement it. Several TLD registries do, some registrars pass it through and some do not, and the only way to know is to publish the records and watch whether the DS changes.
# publish CDS/CDNSKEY, then watch the parent watch -n 3600 'dig +short DS example.com @1.1.1.1' # if it never changes, the chain does not support it # and the registrar step remains manual
Publish them regardless
They cost two records and are harmless where unsupported. Where supported they remove the single most common cause of a DNSSEC outage — a human forgetting to submit a DS — and they make a provider migration substantially less frightening.