Publishing and updating DS records
Publishing your first DS record
Every zone CNX serves is signed automatically — when a new zone deploys,
CNX generates its Key Signing Key (KSK) inside its HSM-backed
key-management system, and the resulting DS (Delegation Signer) record
appears in latest/ds-to-publish.txt in the reports repository (where
your subscription includes it). Submit it at your registrar to complete
the chain of trust.
There's no deadline here — your zone resolves either way. Until the DS is published, it just isn't DNSSEC-validated by resolvers that check for it. This is different from a rollover (below), where timing does matter.
Two digest types are provided:
| Digest type | Algorithm | Use |
|---|---|---|
| 2 | SHA-256 | Primary DS digest |
| 4 | SHA-384 | Additional digest where supported |
If your registrar supports both, publish both. If only one is accepted, use digest type 2 (SHA-256).
KSK rollover
KSK rollover happens at your request — contact CNX when you need one initiated. Once started, it has a real deadline: the new DS record must be published at your registrar before CNX retires the old KSK, or DNSSEC validation for your zone will break. CNX gives you at least 30 days to complete the registrar action.
CNX notifies your technical contact (as listed in contacts.yaml) when
the pre-publish phase begins, including the submission deadline and
confirmation that latest/ds-to-publish.txt has been updated with the
new DS record. You'll get a second reminder 7 days before the deadline if
the new record hasn't yet appeared in the parent zone.
Submitting the new record follows the same registrar process as above. Don't remove the old DS record when you add the new one — both must coexist during the rollover; CNX double-signs with both keys until the old one is retired. Once CNX confirms the new DS record is live and the required cache/TTL safety period has elapsed, it will tell you when it's safe to remove the old one. Removing it early, during the double-sign window, will cause DNSSEC validation failures.
| Phase | Duration | Action required |
|---|---|---|
| Request | Customer-initiated | Contact CNX to start a rollover |
| Pre-publish | CNX-managed | CNX introduces the new KSK while the existing one remains valid |
| DS submission window | At least 30 days | Submit the new DS record to your registrar |
| Overlap / validation | Until CNX confirms the new DS is published and the safety period has elapsed | None — old and new trust data may coexist |
| Old key retirement | CNX-controlled | Remove the old DS only after CNX instructs you to |
ZSK rollovers are managed entirely by CNX and never require any action from you — see DNSSEC.
Where to check what's live
Cross-check the key tag in latest/ds-to-publish.txt against
03-serving-state.txt (the DNSKEY CNX is actually serving) and
04-parent-ds.txt (what your parent zone currently publishes) in the
same day's report — see
Reports repository format.
Don't wait until a deadline to act — a late DS submission during a rollover is the most common cause of DNSSEC outages. Contact CNX via the support channel in your service agreement if you're unable to submit in time.