A domain can have apparently correct nameserver and website records while DNSSEC validation still fails. During a DNS migration, the delegation, signing keys and parent trust information need to remain compatible throughout the transition.
Understand the trust relationship
DNSSEC adds signed information that validating resolvers use to check DNS answers. The parent zone's DS record identifies a trusted key for the child zone. Signing information served by the authoritative DNS service must fit that chain.
If a replacement DNS service uses a different key, leaving incompatible old DS information can break validation. Copying the ordinary website and email records alone does not establish that the signed zone will work.
Inventory the existing arrangement
Identify the registrar, current authoritative DNS service, relevant parent DS records and who can make changes. Record the zone's website, email and other service records, including important subdomains. Keep an export and a current operational contact list.
Check whether DNSSEC is active and whether the current state validates before beginning. A migration should not conceal an existing failure. Record the baseline, so later investigation can distinguish the original state from a transition problem.
Agree the supported migration method
Some supplier combinations support a coordinated multi-signer migration that maintains signing during the move. Such a process involves key coordination and specific provider capabilities, which can include the existing provider serving relevant DNSKEY records in its DNS responses. Confirm support for the actual documented procedure before planning this approach.
The existence of an advanced procedure does not mean it fits every pair of services. Ask both suppliers to confirm the necessary capabilities and responsibilities. Do not partially follow an incompatible procedure and improvise the missing steps.
Where that method is unsuitable, obtain a documented alternative that covers parent trust records, signing state, delegation, cache timing and restoration of the intended protection. Have the responsible DNS specialist explain the sequence and consequences before changes begin.
Plan verification and recovery
Specify what will be checked after each stage, who checks it and when progress pauses. Confirm both authoritative answers and validation from suitable resolver paths. A result from one local connection is insufficient evidence that every important path is working.
Account for cached delegation and trust information using the actual records and timing. Do not promise a universal propagation duration. Define recovery arrangements that remain compatible with the key and delegation states reached during the transition.
Test the business services
Verify website access, enquiry delivery, incoming and outgoing email, relevant subdomains and connected applications. DNS changes can affect services that were absent from the initial website brief. Give operational owners a clear checklist and reporting route.
Keep old arrangements available for the documented period where required. Do not retire a service merely because the new website opens in one browser. Confirm the agreed completion criteria and retain the final record of the change.
Keep ownership clear afterwards
Record the final registrar and DNS responsibilities, validation state and recovery contacts. Confirm how future signing or key changes are managed in the actual arrangement. Automatic updates depend on supported capabilities rather than being universal.
Review permissions and documentation after handover. The business should know where to report a DNS problem and who is authorised to investigate it. A technically successful move still needs an understandable operational record.
Migration checklist
- Record current delegation, trust records and signing state.
- Confirm baseline validation and export the zone.
- Agree a method supported by both suppliers.
- Specify stage checks, timing and recovery.
- Test website, email and connected services.
- Document the final state and responsible owners.
Our DNS records guide explains delegation and caching. The hosting migration checklist covers the wider service handover.
