How to Audit DNS Records Before a Domain Migration (Without Downtime)

Most domain and server migrations do not fail during the code deployment—they fail because an engineer updates the apex A record or switches nameservers without auditing hidden TXT, MX, CNAME, AAAA, or CAA records first, or without lowering the TTL 24 hours ahead of the cutover. When a residual IPv6 AAAA record still points at the old host or a restrictive CAA record blocks the new server's Let's Encrypt ACME challenge, half your visitors hit a broken TLS screen while Google Workspace or SES mail starts bouncing. Here is the exact step-by-step DNS audit workflow I run before every production cutover.

Why "Just Pointing the A Record" Causes Partial Outages

When we prepare a production cutover or build network inspection utilities for PixelValut, the most common post-migration bug we diagnose is split-brain traffic caused by incomplete DNS inventories. Modern web domains rarely hold just a root IP address. Over a year of operations, marketing, engineering, and finance teams accumulate:

• IPv6 (AAAA) records that modern mobile carriers and dual-stack browsers prefer over IPv4 (A) records via the Happy Eyeballs algorithm (RFC 8305). If you update the A record to your new server IP (203.0.113.50) but forget to delete or update the old AAAA record, every IPv6 client continues hitting the decommissioned server.
• Certification Authority Authorization (CAA) records that whitelist which Certificate Authorities can issue TLS certificates for your domain. If your old cloud provider pinned 0 issue "amazon.com" and your new server uses Let's Encrypt (letsencrypt.org), automatic HTTPS issuance fails at cutover.
• Subdomain CNAME records for transactional mail (em1234, s1._domainkey), status pages (status), CDN assets (cdn), and payment webhook receivers (api).

Complete DNS Record Audit Matrix Before Any Cutover

Use this reference table to audit every record type in your zone file before touching production traffic:

Record Type	What It Controls	Common Migration Failure Mode	Command / Verification Check
SOA	Zone serial number, primary nameserver, refresh/retry timers, negative cache TTL	Switching nameservers while negative caching TTL is high caches NXDOMAIN on new subdomains	dig +short SOA example.com
NS	Authoritative nameservers for the domain	Updating records in the old DNS panel after changing registrar NS glue records	dig +short NS example.com
A (IPv4)	Maps apex (@) or subdomain to an IPv4 address	High TTL (3600s–86400s) keeps ISP resolvers hitting the old IP for hours	dig +noall +answer A example.com
AAAA (IPv6)	Maps apex or subdomain to an IPv6 address	Updating A while leaving the old host's AAAA record active sends ~40% of mobile users to the old server	dig +noall +answer AAAA example.com
CNAME	Aliases a subdomain (www, app, mail selector) to another hostname	Deleting DKIM selector CNAMEs (s1._domainkey) or breaking www redirects during zone import	dig +noall +answer CNAME www.example.com
MX	Inbound email routing and priority servers	Auto-importing a zone on a new DNS host that overwrites Google Workspace/Microsoft 365 MX with default cPanel mail	dig +short MX example.com
TXT	SPF (v=spf1), DMARC (_dmarc), DKIM keys, Google Search Console & Stripe domain verification	Dropping the old server's IP from SPF or accidentally deleting Google/domain verification strings	dig +short TXT example.com
CAA	Restricts which CAs can issue SSL/TLS certificates for the domain	Old CAA record blocks Let's Encrypt (letsencrypt.org) or Cloudflare Universal SSL on the new host	dig +short CAA example.com

Step-by-Step Terminal & Browser Audit Workflow

Step 1: Export a Full Snapshot of Your Live Zone (48 Hours Before Cutover)

Never rely solely on screenshots of a web dashboard. Before changing a single record, export your BIND zone file from your DNS provider (Cloudflare, Route 53, DigitalOcean, or Namecheap) and commit it to an infrastructure repo or incident ticket. Then verify what authoritative nameservers are currently answering in the wild:

# 1. Check authoritative nameservers and SOA serial
dig +short NS example.com
dig +short SOA example.com

# 2. Query one authoritative nameserver directly so local resolver cache never misleads you
AUTH_NS=$(dig +short NS example.com | head -n 1)
dig @${AUTH_NS} +noall +answer example.com A example.com AAAA example.com MX example.com TXT example.com CAA

Querying @${AUTH_NS} directly bypasses your local ISP cache and shows the exact TTL and record values stored on the authoritative nameserver. If you prefer checking records visually from the browser without opening a terminal, you can run the A Record Lookup and CAA Record Checker on PixelValut alongside the 200+ utilities in the PixelValut Developer Tools directory.

Step 2: Lower Your TTLs 24 to 48 Hours Before the Maintenance Window

A DNS record's Time-To-Live (TTL) tells recursive resolvers (like 1.1.1.1, 8.8.8.8, and corporate ISP resolvers) how many seconds they may cache the answer before asking your authoritative nameserver again. If your @ and www records have a TTL of 14400 (4 hours) or 86400 (24 hours) and you lower the TTL at the exact same moment you swap the IP address, resolvers that fetched the old IP five minutes earlier will keep serving the old IP for the next 23 hours and 55 minutes.

At least 24–48 hours before cutover:

1. Lower the TTL on every record that will change (@, www, api, SPF) to 300 seconds (5 minutes).
2. Wait until the old TTL window has completely elapsed.
3. Verify the live TTL with dig +noall +answer example.com A—the second column in the dig output displays the remaining seconds in cache.

Step 3: Check CAA and Pre-Stage Your TLS Certificates

Before switching live DNS traffic, make sure your new server can issue or already holds a valid TLS certificate. Check whether your domain publishes any CAA records:

dig +short CAA example.com
# Example output that blocks Let's Encrypt:
# 0 issue "sectigo.com"

If a CAA record exists, it acts as an explicit allowlist—any Certificate Authority not listed is forbidden from issuing certificates for that domain. Add 0 issue "letsencrypt.org" (and 0 issuewild "letsencrypt.org" if you use wildcard certs) before your new server attempts ACME validation. Once the certificate is installed on the new server, test the new host directly before changing DNS by passing --resolve to curl:

curl -Iv --resolve example.com:443:203.0.113.50 https://example.com/

For a complete post-cutover TLS chain and cipher check, follow the steps in my earlier guide on how to check an SSL certificate in 10 minutes and fix the most common HTTPS errors.

Step 4: Audit Email Authentication (MX, SPF, DKIM, DMARC) So Mail Never Drops

Even when you are only migrating a web server and leaving email on Google Workspace, Microsoft 365, or Amazon SES, two email traps regularly catch teams off guard:

1. Outbound Web Server IP in SPF: If your web application sends transactional emails directly from the host or through an internal relay listed by IP (ip4:198.51.100.24) in your v=spf1 record, add the new server's IP to the SPF record before the migration and keep the old IP in the record until the old server's mail queue is completely drained.
2. Zone Auto-Scan Overwriting DKIM or DMARC: When you add a domain to a new DNS provider using its "automatic DNS record scan," the scanner only guesses common subdomain names (www, mail, ftp, _dmarc). It cannot guess custom DKIM selector names (such as 202610._domainkey.example.com or s1._domainkey.example.com) unless you import the complete zone file.

After verifying your TXT and CNAME records, run through my checklist on how to check SPF, DKIM, and DMARC records in 10 minutes so no automated password reset or order receipt lands in spam during the migration.

Pre-Cutover & Post-Cutover DNS Checklist

Keep this checklist open during your deployment window:

• [ ] Backup Full BIND Zone File: Export all records from the current DNS host and verify custom subdomains (_dmarc, *_domainkey, status, cdn, api).
• [ ] Check Both A and AAAA: Confirm whether an IPv6 AAAA record exists; update it to the new server's IPv6 address or remove it if the new host is IPv4-only.
• [ ] Lower TTL to 300s Early: Drop TTLs at least 24 hours before the migration window.
• [ ] Verify CAA Allowlist: Confirm the target server's Certificate Authority is permitted in CAA records and test HTTPS via curl --resolve.
• [ ] Check Global Resolver Propagation: After flipping the record, verify answers across multiple global resolvers using dig @1.1.1.1, dig @8.8.8.8, dig @9.9.9.9, or the DNS Propagation Checker on PixelValut.
• [ ] Restore Production TTLs After 24 Hours: Once traffic, SSL, and email logs are clean for 24 hours, raise your TTLs back to 3600s (1 hour) to improve lookup speed.

Frequently Asked Questions (FAQ)

Why does DNS propagation sometimes take hours even when I set the TTL to 300 seconds?

Two things cause slow updates despite a 300-second record TTL: first, you may have lowered the TTL at the same time you changed the IP, meaning resolvers are still honoring the previous TTL (e.g., 24 hours); second, if you changed authoritative nameservers (NS records) at your registrar rather than editing an A record inside the existing zone, top-level domain (.com, .org, .pk) registry glue records carry their own 24-to-48-hour TTL (172800 seconds).

What happens if I leave an old IPv6 AAAA record pointing to my previous server?

Modern smartphones and dual-stack broadband connections query A and AAAA records simultaneously and prefer IPv6 whenever it responds fast enough. Leaving a stale AAAA record active sends a large share of mobile visitors to the old server even though every IPv4 check looks green.

Can I put a CNAME record on the root (apex) domain example.com?

Standard DNS (RFC 1034) forbids placing a CNAME at the zone apex (@) because a CNAME cannot coexist with other records at the same node—and the zone apex must always hold SOA and NS records (plus usually MX and TXT). If you need apex aliasing to a load balancer hostname, use a DNS provider that supports ALIAS or ANAME flattening, which resolves the target hostname at the authoritative server and returns standard A/AAAA records to clients.

Should I delete the old server immediately after DNS cutover?

No. Keep the old server running (either proxying traffic to the new server via Nginx or in read-only maintenance mode if database writes have moved) for at least 24–48 hours while monitoring access.log on the old machine until request volume drops to zero.

How can I check if a DNS change has propagated across different countries and resolvers?

You can query public resolvers directly from your terminal (dig @1.1.1.1, dig @8.8.8.8, dig @208.67.222.222) or run an instant check using the PixelValut DNS Propagation Checker to compare responses side by side.