DNS During Domain Migration

## DNS During Domain Migration Domain and server migrations are among the riskiest operations in web infrastructure. Done incorrectly, they cause email loss, website downtime, and hours of troubleshooting. Done well, migrations are nearly invisible to users. This guide covers the two most common migration types: moving a website to a new server, and switching DNS providers (nameservers). ## Core Principle: Reduce TTL First Every migration starts the same way: **lower your TTLs at least 24–48 hours before the change.** If your A record has `TTL 86400`, resolvers can serve the old IP for up to 24 hours after you change it. By lowering to `TTL 300` two days in advance, you guarantee that by migration time, all cached records will expire within 5 minutes of your change. This single step is the difference between a migration that fully propagates in 15 minutes versus one that drags on for 24+ hours. ## Scenario 1: Migrating a Website to a New Server **Timeline:** **T-48 hours: Prepare** 1. Note all current DNS records (export from your DNS provider if possible) 2. Lower TTL on A/AAAA records for the domain to 300 seconds 3. Lower TTL on any CNAMEs pointing to your site to 300 seconds **T-48 to T-0: Configure the new server** 1. Set up the new server completely — web server, SSL certificate, application code 2. Test the new server by editing your local `/etc/hosts` file to point the domain at the new IP: ``` 203.0.113.20 example.com www.example.com ``` Browse your site — it should work fully on the new server before you touch DNS. 3. Remove the `/etc/hosts` entry after testing **T-0: Make the DNS change** 1. Change the A record value from old IP to new IP 2. Keep the TTL at 300 for now 3. Note the exact time of the change **T+15 minutes to T+1 hour: Monitor** - Check the new server's access logs for incoming traffic - Query from multiple public resolvers to confirm propagation: ```bash dig @8.8.8.8 example.com A dig @1.1.1.1 example.com A dig @9.9.9.9 example.com A ``` - Keep the old server running until you confirm the new server handles all traffic **T+24 hours: Finalize** 1. Once traffic has fully shifted, raise TTLs back to 3600 2. Shut down the old server after another 24 hours of monitoring ## Scenario 2: Switching DNS Providers (Nameservers) Moving from registrar DNS to Cloudflare, Route 53, or another provider involves NS record changes — the most propagation-intensive DNS change. **T-48 hours: Export and recreate records** 1. Export all DNS records from your current provider 2. Recreate every record in the new provider — A, AAAA, CNAME, MX, TXT, CAA, SRV records 3. Verify record-by-record — mismatched or missing records cause downtime **Key records to double-check:** - MX records and their A record targets - SPF/DKIM/DMARC TXT records - CAA records - Any SRV records - Subdomain records that might not be visible in exports **T-48 hours: Lower TTLs at the OLD provider** Lower all record TTLs (especially MX and A) to 300 seconds at your current provider. This ensures that during the NS transition, when some users are still pointing at the old provider, changes propagate fast. **T-0: Update nameservers at registrar** 1. Log into your registrar 2. Change NS records to the new provider's nameservers 3. The registry (`.com`, `.org`, etc.) updates its glue records within minutes 4. Resolvers holding the old NS records flush when their TTL expires **T+0 to T+48 hours: Monitor both providers** During NS propagation, some resolvers still use the old nameservers while others use the new ones. Keep both providers' records identical and both providers active. Do not delete the old provider's records yet. **T+48 hours: Verify and clean up** 1. Confirm all major resolvers (Google, Cloudflare, your ISP) return records from the new provider: ```bash dig example.com NS ``` 2. Once the new NS records are globally visible, raise TTLs at the new provider to 3600 3. Remove or deactivate the old DNS provider ## Scenario 3: Migrating Email Providers Email migrations are the most fragile — a misstep can lose messages in transit. **Process:** 1. Set up the new email provider and confirm you can log in and send test messages 2. At T-1 day, lower MX TTL to 300 seconds 3. Add the new MX records *without* removing the old ones — both providers will receive mail during the transition 4. Verify the new server is receiving messages (check logs) 5. Remove the old MX records after confirming all mail flows to the new server 6. Update SPF/DKIM/DMARC TXT records for the new provider 7. Raise MX TTL back to 3600 Running both MX records simultaneously during transition prevents the small window where senders might try to deliver to the old server after you've removed it but before the change propagates. ## Rollback Plan Before every migration, document your rollback procedure: 1. What are the current record values? (Write them down) 2. How long will rollback take? (Current TTL on affected records) 3. Who do you call if the migration fails at 2am? Keep the old server or DNS configuration active for 24–48 hours after migration. With low TTLs, switching back takes 15 minutes. ## Migration Checklist - [ ] All current records documented - [ ] TTLs lowered to 300s at T-48h - [ ] New server/provider tested before DNS change - [ ] DNS change made and time recorded - [ ] Traffic monitored on new server - [ ] Old server/provider kept active for 24h post-migration - [ ] TTLs raised to 3600 after stability confirmed ## Tools for Monitoring Use [whatsmydns.net](https://www.whatsmydns.net) to check A and MX record propagation from dozens of global locations simultaneously. The DNS Record Helper tool also helps verify current record values. See Understanding DNS Propagation for deeper explanation of propagation mechanics, and DNS Troubleshooting Guide if anything goes wrong post-migration.