Migrating DNS without downtime: TTL, record copying and verification with dig

Moving a domain's DNS to a new provider or new server is something you do only a few times in a domain's lifetime, but if you get the sequence wrong you risk hours of downtime or, worse, email disappearing into the void. You don't need any exotic tools: just the DNS panel, dig from the terminal and a bit of patience with wait times. The part that's almost always skipped is precisely the waiting itself.

Lower the TTL beforehand, not during

The TTL (Time To Live) tells resolvers how long to cache a record before requesting it again from the authoritative server. If a record has a TTL of 86400 seconds (24 hours) and you change it without notice, lowering the TTL to 300 seconds must be done well before the change, letting at least one full old TTL period pass after the authoritative publication before the cutover. In practice: if the current TTL is 24 hours, you must lower it at least 24–48 hours before, not an hour before.

Multiple independent technical sources converge on the same timeframe. A TTL of 60–120 seconds should be set 24–48 hours before planned DNS changes, to prepare the system for rapid propagation during server migrations or hosting provider changes. Alternatively, 24–48 hours before the migration, modify the A record (and any other record that will change, such as www and MX) by setting the TTL to 300 seconds.

Phase	Recommended TTL	When
Stable production	3600–86400 s	No changes in sight
Pre-migration	300–600 s	24–48 hours before cutover
During migration	300 s	Until propagation confirmed
After, once stability confirmed	3600 s or original value	Once verified everywhere

Be careful not to overdo it the other way: very low TTL values, below 60 seconds, force resolvers to query authoritative nameservers much more frequently, increasing the load on DNS infrastructure and potentially increasing resolution latency for end users.

The list of records to copy

Before touching any TTL, you need a complete inventory of the current zone. The records most often forgotten are not A and CNAME, but TXT and MX. Check them in this order:

• A / AAAA: IPv4 and IPv6 address of the site, for the bare domain and for any subdomains (www, app, api).
• CNAME: aliases to third-party services (CDN, SaaS platforms, marketing tools).
• MX: mail servers, with their numerical priorities.
• TXT: this is where the greatest risk lies. You need SPF (sender authentication), DKIM selectors (often one per mail provider), and the DMARC record on _dmarc.domain.tld. An error on any of these three won't break the website, but will make emails end up in spam or be rejected altogether.
• NS: if you're also changing the DNS provider and not just the hosting server, verify these last, after the entire zone has been recreated on the new panel.

A technical note that generic tutorials often skip: along a chain of CNAME records, the effective cache follows the minimum TTL across all links in the chain. If a CNAME points to another CNAME with a different TTL, the lower of the two counts.

Verify with dig before shutting down the old server

The basic command to check a record is dig DOMAINNAME TYPE, but to understand whether propagation is complete you need to query different resolvers, not just your own:

dig A domain.tld @8.8.8.8 +short
dig A domain.tld @1.1.1.1 +short
dig A domain.tld @9.9.9.9 +short

If queries to Google DNS, Cloudflare DNS and Quad9 all return the same result, the change has propagated to the major public DNS servers; if they return different results, propagation is still in progress or caching is causing different responses across servers.

For mail and authentication records, repeat the same commands with the correct types:

dig MX domain.tld +short
dig TXT domain.tld +short
dig TXT _dmarc.domain.tld +short

A step worth doing before calling propagation complete: query the new provider's authoritative nameservers directly, not just public resolvers. After a planned change it's worth querying each authoritative nameserver directly and then comparing public resolvers like 8.8.8.8, 1.1.1.1 and 9.9.9.9: if the authoritatives agree but public resolvers still return the old value, their caches haven't expired yet. Different results between resolvers, however, aren't always a problem: GeoDNS, load balancing, split-horizon DNS and EDNS Client Subnet can intentionally produce different responses even after propagation is complete, so don't automatically mistake them for a delay.

For a multi-location check without opening terminals on servers scattered across the globe, any public DNS lookup tool with nodes on multiple continents gives the same type of response all at once: useful for a quick verification, but the dig command remains the reference when you need to understand why a node still sees the old data.

The coexistence period

Until you're certain that all resolvers that matter for your audience see the new address, the old server must stay on and reachable. Shutting it down too soon is the most common mistake: it often happens that you move the site and see the new IP working for some users, while a portion of traffic continues to reach the old server for hours, because their resolver's cache hasn't expired yet. The practical rule is simple: the old server stays live at least as long as the old TTL plus a safety margin, and is shut down only after verifying from multiple resolvers that the new address is everywhere the answer.

Restore the TTL and final checklist

Once propagation is confirmed, bring the TTL back to the normal production value (typically 3600 seconds or the value used before the migration): once stability is confirmed restore the TTL to the normal value, usually 3600 seconds or whatever standard was used previously. Leaving it low forever isn't a serious error but it's pointless: it only means more queries to nameservers with no benefit.

Checklist before closing the migration ticket:

• Incoming and outgoing email works on the new server (not just webmail: also SMTP authenticated from external clients).
• SPF, DKIM and DMARC return the same content as before the migration, verified with dig TXT.
• The SSL certificate on the new server is valid for all hostnames served (bare domain, www, any subdomains), not just the main one.
• The old server remains reachable for a few more days as a safety net, even after restoring the original TTL.
• The TTL has been brought back to the production value and wasn't left at 300 seconds by mistake.