Confirm cross-provider DNSKEY support before planning a Cloudflare DNSSEC-preserving migration

Keeping validation active requires cooperation from the previous provider, not only a nameserver change.

Source facts

Cloudflare’s active-DNSSEC migration procedure requires the previous provider to add DNSKEY records at the apex and return them in answers. The workflow cross-imports zone signing keys and checks that both providers return both ZSKs before moving through registrar and provider-removal stages. This is an advanced coordinated migration rather than an ordinary one-step nameserver replacement.

Source: Cloudflare — DNSSEC migration tutorial.

Applicability

This concerns the documented Cloudflare migration path that preserves DNSSEC.

DSE recommendation

DSE recommends obtaining explicit confirmation of external DNSKEY support from both DNS teams before scheduling the cutover. Record current DS records, keys, nameservers, TTLs, and the exact rollback stage. Follow the full provider procedure rather than combining isolated steps from unrelated migrations. Keep the old provider available until the documented trust and delegation transitions have completed and been checked. Give each key-import, DNSKEY-answer, registrar, and provider-removal checkpoint an explicit owner. Preserve the observed key identifiers at every stage. Stop the migration when either provider cannot demonstrate the required shared key set rather than trying to compensate with an early nameserver change.

Verification

In a controlled rehearsal or approved migration, query each authoritative provider for the expected DNSKEY set and inspect the registrar DS state at each stage. Validate representative records through trusted validating resolvers. Record completed checkpoints separately and do not remove the old provider simply because the new dashboard shows the zone as configured.

Official reference

Cloudflare — DNSSEC migration tutorial. Reviewed October 20, 2026.