Migrations
DNSSEC transitions
Use DNSMigrator's DNSSEC transition workflow to remove stale DS records, wait safely, change providers, verify the new chain, and switch back if needed.
6 min read
On this page
How the DNSSEC transition workflow works#
A managed DNS provider signs a zone with keys it controls. The registrar publishes a DS record into the parent zone, creating a chain from the DNS root to that provider’s DNSKEY. If delegation changes while a cached DS still identifies the old key, the new provider’s otherwise correct answers fail validation and resolvers return SERVFAIL.
DNS record apply and DNSSEC delegation are therefore separate:
- Apply writes ordinary destination records but does not publish registrar DS data.
- Rollback reverses destination record writes but does not change DS or nameservers.
- Cutover reads live DNSSEC state, performs or guides DS and NS changes, and watches DNS.
How does a DNSSEC migration work?#
Enter the DS, DNSKEY, and parent NS TTLs below to see why the safe sequence has separate waiting periods.
Verify the destination first
Apply the migration and resolve every failed authoritative verification. Check the current domain with the DNSSEC checker or generate a tailored sequence with the DNSSEC migration checker.
Start Cut over
Choose We switch it with an active registrar connection or I’ll switch it for guided changes. At start, DNSMigrator asks live DNS whether the zone is signed and how many DS records exist. It does not decide from copied zone-file records.
Remove the old DS
Automatic mode calls the registrar’s DS API when available. Guided mode displays Remove the DS record and checks every five minutes; after changing it, select I’ve done this, check now for an immediate check.
Wait after removal is observed
Once live detection reports no DS, Wait for the DS record to expire waits a fixed 86,400 seconds. This creates an unsigned interval: the old provider may still sign, but the parent no longer tells resolvers to require that key.
Switch nameservers and watch propagation
DNSMigrator changes or checks the registry NS set, then samples public resolvers until at least 80% of returned probes report the destination nameservers. Keep both providers serving during this overlap.
Enable destination signing
If the destination adapter implements DNSSEC changes, Enable DNSSEC at the new provider calls it and records how many DS records it returned. Otherwise the step is marked skipped and its detail tells you to use the provider dashboard.
Publish the new DS
DNSMigrator reads DS data from the destination where possible. Automatic mode uses the registrar DS API when available; otherwise the panel displays the DS fields or asks you to copy them from the destination. The step completes after live detection sees at least one parent DS; use the DNSSEC checker afterward to verify that it matches the destination DNSKEY.
The DNSSEC steps are included when live detection finds a parent DS or reports a signed or broken chain at cutover start. With no DS, cutover goes directly through nameserver switch and propagation. If that result is surprising, stop and check with the DNSSEC checker before continuing.
What happens to DNSSEC record types#
Source-signer material is not treated like ordinary zone content:
| Source material | Migration behavior | Reason |
|---|---|---|
| SOA and apex NS | Managed | The destination creates records for its own authoritative service. |
| DNSKEY | Managed in ordinary translation | It belongs to the provider’s signer. |
| RRSIG, NSEC, NSEC3, NSEC3PARAM, CDS, CDNSKEY in a BIND import | Ignored by the parser | Signatures, denial chains, and child signaling must be regenerated. |
| DS in the parent zone | Changed during cutover, not copied from the child zone | It is registrar/registry state. |
A BIND file can contain a child-zone DS for a delegated subdomain; that is an ordinary delegation record within the imported zone. Do not confuse it with the domain’s own DS, which lives at its parent and is discovered live.
A BIND file cannot establish the domain’s current parent DS state. Cutover detects that state from live DNS instead of trusting imported child-zone records; see BIND zone files.
The fixed wait is not a universal TTL calculation#
The cutover worker waits one day after it observes that the old DS is gone. It does not query the parent record’s prior TTL, calculate how long each resolver may have cached it, or vary the wait by TLD. Read how long DNS propagation takes for the cache model behind those waiting periods.
Every cutover step has a 72-hour maximum from its start. A DS removal or publication that is still incomplete at that point changes the cutover to Needs attention rather than advancing.
Automatic and guided DS handling#
“Automatic” describes registrar API use, not guaranteed end-to-end DS automation. Four capability combinations matter:
| Destination DNSSEC API | Registrar DS API | Behavior |
|---|---|---|
| Available | Available | DNSMigrator enables signing, reads DS, and asks the registrar to publish it. |
| Available | Unavailable | DNSMigrator enables signing and displays the DS for manual publication. |
| Unavailable | Available | You enable signing in the destination dashboard and follow the panel’s manual DS instruction; DNSMigrator observes the live result. |
| Unavailable | Unavailable | You enable signing and publish DS in both dashboards; DNSMigrator keeps polling live DNS. |
For removal, a registrar without setDsRecords always falls back to a dashboard instruction. The provider and registrar capability catalog is under Supported providers; setup paths are on each provider page, such as Route 53 and Cloudflare.
Check the new chain#
After Publish the new DS record completes:
- Use the DNSSEC checker to confirm DS and DNSKEY agree.
- Query important A/AAAA, MX, TXT, and CNAME records through validating resolvers.
- Check the propagation checker for the new NS set.
- Keep the old provider active while cached delegations can still reach it.
Do not manually publish a DS copied from the old provider. Use the key tag, algorithm, digest type, and digest reported by the destination after it has enabled signing.
Switching back safely#
Switch back to the old provider restores only nameservers in automatic mode; guided mode merely records the revert while you change the registrar yourself. It does not remove the new DS, restore the old DS, disable destination signing, or restore TTLs lowered at the source.
Record rollback can happen only after traffic has a safe authoritative path. Coordinate the order with Rollback and the full Nameserver cutover behavior.
DNSSEC migration questions#
What is the safe order for a DNSSEC migration?
Why can changing DNS providers cause DNSSEC SERVFAIL?
SERVFAIL until the chain is repaired or the stale DS expires.