DNS Migration for Server Changes

Executive summary and objectives

This guide explains how to move your DNS records from one provider to another with minimal downtime and risk.
It gives a clear, step-by-step plan covering inventory, design, testing, cutover, rollback, and post-migration cleanup.
The main objectives are: keep services available, preserve email and SSL behavior, maintain security (DNSSEC, access controls), and document the change for audits.

Scope and prerequisites

Define what you will move and what you will not. Include all authoritative zones, glue records, subdomain delegations, and related records (A, AAAA, CNAME, MX, TXT, SRV, PTR where applicable). Exclude reverse DNS if managed by your ISP unless you have permission to change it.

Prerequisites:

• Admin access to current DNS provider and registrar.
• Admin access to target DNS provider and any APIs you will use.
• A complete zone export or API access to list every record.
• Contact list: registrar, DNS providers’ support, app owners, email admins.
• Scheduled maintenance window and stakeholder approvals if needed.
• Backup of current zone files and SOA serials.

Current DNS inventory and dependency mapping

Start by making a full list of zones and records. Use the provider UI, API, or tools like dig and zone transfer (AXFR) when allowed:

• dig axfr example.com @ns1.example-dns.com
• dig +short any example.com @8.8.8.8

Map dependencies for each record:

• Web sites and CDN endpoints.
• Load balancers and failover services.
• Mail servers, MX and SPF/DKIM/DMARC.
• API endpoints and mobile apps.
• Certificates and ACME/DNS challenge records.
• External partners that use your DNS names.

Look for hidden or stale records:

• Old subdomains still resolving.
• Wildcards that could expose services.
• Records autogenerated by orchestration tools.

Record the TTLs, SOA serials, and any DNSSEC configuration. Capture which records are used by automation pipelines.

Target DNS architecture and design

Decide how your DNS will be structured in the new provider:

Key design choices:

• Anycast vs unicast: Anycast improves global latency and resilience.
• Primary/secondary or multi-master: choose based on provider features.
• Zone layout: keep the same zones unless consolidation helps management.
• DNSSEC: enable if you need cryptographic validation; plan key rollover.
• Access controls: use role-based access and API keys with limited scope.
• Logging and query analytics: enable for troubleshooting and compliance.
• Health checks and failover: configure only if provider supports it.

Define standard TTLs and naming conventions. Decide on who manages each record post-migration.

Migration strategy and approach

Choose one of two main strategies:

• Phased (recommended): stage zones and records on the new provider, run both providers in parallel, then switch delegations at the registrar. This reduces risk.
• Big-bang: change NS at the registrar in one window. Faster but riskier.

A safe phased approach:

1. Prepare the new zones with every record and identical SOA/serial if possible.
2. Lower TTLs on critical records well before cutover.
3. Validate new zone answers directly against the new nameservers.
4. Change NS records at the registrar to point to the new provider.
5. Keep the old provider running until propagation completes.

Define roles: migration lead, registrar contact, app owners, support staff, and a rollback owner.

TTL and record update strategy

TTL controls how long resolvers cache records. Plan TTL carefully.

Recommendations:

• For critical records, reduce TTL to 60–300 seconds at least 48–72 hours before cutover. This allows quick propagation during cutover.
• For MX and email-related records, do not set TTL too low unless necessary; email delivery retries respect TTL but also use retry logic.
• Leave non-critical records at a higher TTL to reduce DNS traffic.
• After successful migration and verification, raise TTLs back to normal (for example, 3600–86400 seconds) after 24–48 hours.

Notes:

• Some resolvers ignore low TTLs; expect a small percentage of slow propagation.
• Changing TTL itself is a record update that obeys the old TTL until it expires.

Zone preparation and record staging

Prepare zones on the target provider exactly as on the source.

Steps:

1. Export or list all records from the source provider.
2. Clean the list: remove duplicates and stale records, confirm wildcard usage.
3. Create zones on the target provider and import records. If importing by API, do it in a way that preserves record types and metadata.
4. Increment the SOA serial appropriately if the provider requires it.
5. If possible, set up the target provider as a secondary (AXFR/IXFR) and replicate from the current primary to reduce mistakes.
6. For DNSSEC, stage keys and test in a non-signed state if necessary, then plan a carefully timed DS record update at the registrar.

Verify staged records directly:

• Use dig to query the new authoritative: dig @ns1.new-dns.com example.com A
• Confirm responses, TTLs, and any provider-specific annotations.

Testing, validation, and pre-cutover checks

Run a pre-cutover checklist:

DNS-level checks:

• All record types present and matching production.
• SOA serials and zone serial strategy correct.
• NS records in the zone match the registrar delegation list (after cutover they must).
• DNSSEC keys staged and validated if used.

Service-level checks:

• Web endpoints return correct content and certificates.
• Mail flow tested end-to-end (send and receive).
• API endpoints respond as expected from multiple geolocations.

Tools to use:

• dig, host, nslookup for raw responses.
• online DNS checkers for propagation and consistency.
• provider logs and query analytics for request patterns.
• Postman or curl for HTTP endpoint checks.

Get sign-off from stakeholders before scheduling the cutover.

Cutover execution and synchronization

Execute the cutover with a clear runbook and a defined time window.

Typical cutover steps:

1. Ensure TTLs have been lowered for critical records.
2. Confirm both old and new providers are serving identical records.
3. Change the NS delegation at the registrar to the new provider’s name servers.
4. If there are in-bailiwick nameservers (ns1.example.com), update glue records at the registrar as needed.
5. Monitor registrar confirmation and WHOIS to verify the change.
6. Keep the old provider active for at least one full previous TTL period to catch late caches.

During cutover monitor:

• DNS query success rates and error codes.
• Application health dashboards.
• Email delivery logs for bounce or delay signs.

Expect partial propagation: some resolvers switch immediately, others take longer.

Rollback and contingency procedures

Have a clear rollback plan before touching registrar settings.

Rollback triggers:

• Major traffic loss or service outage lasting beyond an agreed threshold.
• Critical services failing validation after NS change.
• Security or DNSSEC failures that cannot be resolved quickly.

Rollback steps:

1. Re-point registrar NS back to the old provider.
2. Confirm registrar processed the change and WHOIS/NS records show the old servers.
3. Notify stakeholders and reroute any provider-specific services if needed.
4. Restore old TTL values and any configurations you changed temporarily.
5. Log the incident and root cause for later analysis.

Prepare both technical and communication rollbacks: who calls whom, and which teams are responsible.

Monitoring, validation, and post-migration cleanup

After migration, monitor for at least 72 hours with focus on:

• Query error rates (NXDOMAIN spikes, SERVFAIL).
• Latency and resolved IPs from different regions.
• Email bounce messages and SPF/DKIM failures.
• Application and CDN logs for unexpected origins.

Validation checklist:

• Confirm DNSSEC is active and validated if used.
• Verify zone transfers or synchronization (for multi-master setups).
• Ensure automation and CI/CD integrations are pointing to the new DNS provider.

Cleanup tasks:

• Decommission old zones only after you confirm no traffic goes to them and after double the maximum TTL has passed.
• Remove temporary support records used for testing.
• Raise TTLs back to normal.
• Revoke any temporary API keys used during migration.

Communication, documentation, and compliance

Before migration:

• Notify internal teams, support, and customers as appropriate.
• Post a short maintenance notice if end users may see interruptions.

During and after migration:

• Provide live status updates to stakeholders.
• Share a single source of truth (a runbook or ticket) with timestamps for actions taken.

Documentation to produce:

• Final zone files and a diff from pre-migration state.
• Runbook of how cutover and rollback were done.
• Incident report if anything went wrong.
• Access lists, API keys and who has them.

Compliance considerations:

• Check data residency rules for DNS logging if you operate in regulated industries.
• Preserve audit trails for registrar changes and provider admin actions.
• Keep DNSSEC DS records and key rotation records for audits.

Final note: treat DNS as critical infrastructure. Test well, communicate early, and keep the old configuration available until you are sure the new setup is stable.