Migrations9 min read
How to Check DNS After a Website or Server Migration
A successful server migration requires more than seeing the new website from your own connection. DNS, IPv6, email records, TLS and old cached routes must be checked independently before the previous infrastructure is removed.
Before the cutover
- Record the current A, AAAA, CNAME, MX, TXT and NS answers.
- Lower relevant TTL values early enough for the old TTL to expire.
- Prepare the new server to answer for every hostname before DNS changes.
- Keep mail and verification records unchanged unless they are part of the migration.
- Test the new server directly using a hosts-file override or explicit Host header.
Verify authoritative DNS after the change
Direct authoritative checksdig
dig example.com NS +short
dig @ns1.example.net example.com A +norecurse
dig @ns1.example.net www.example.com A +norecurse
dig @ns1.example.net example.com AAAA +norecurseCompare public resolver answers
Recursive checksdig
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @9.9.9.9 example.com A +shortCheck services beyond the website
- Confirm www and every application subdomain, not only the root domain.
- Check AAAA records so IPv6 clients do not reach the old server.
- Verify MX and TXT records were not lost during a DNS provider migration.
- Confirm the TLS certificate covers the migrated names.
- Inspect access logs on both old and new servers during the cache transition.
Common migration failures
Old AAAA record remains
IPv6-capable users can continue reaching the previous infrastructure.
Only root domain changed
The www hostname or API subdomain may still use an old CNAME or address.
Old server removed too soon
Clients behind cached DNS can receive connection failures.
Nameservers changed without copying the complete zone
MX, TXT, CAA or service records can disappear.
CDN proxy hides the origin test
Verify both public CDN behavior and direct origin configuration.