During a server migration, two users can reach different origins because their resolvers cached the address at different times. Consider a hypothetical online shop where the DNS record changes while some customers still use the old address. The challenge is not only refreshing DNS: both paths must handle sessions, orders and data consistently.
This guide explains DNS TTL planning for server migrations, including preparation time, negative caching, mail, delegation changes and rollback. Lowering TTL reduces one source of delay; it does not by itself produce zero downtime or protect writes. The migration plan must also control application state, connections and the transition between data stores.
What TTL Actually Does (And What It Doesn’t)
Think of TTL like a “how long you can trust this” note attached to each DNS answer. When a resolver (like the one your ISP or Google Public DNS runs) looks up your domain and gets an IP, TTL tells it how long to cache that answer before asking again. Shorter TTLs mean changes spread faster. Longer TTLs reduce DNS load and can make lookups a hair faster. But there’s more to the story.
There are multiple layers of caching. Your browser can cache, your device can cache, your local resolver caches, upstream resolvers cache, even CDNs sometimes layer their own logic. And each can behave a little differently. That’s why two people might see different results at the same moment. It’s not that the internet is “still propagating” like smoke across a room—it’s that old answers are living out their cached lifetimes all over the place.
Negative caching can preserve an NXDOMAIN response or the absence of a particular record type. Its lifetime is not necessarily shorter than a positive record’s TTL: RFC 2308 derives it from the smaller of the SOA record TTL and SOA MINIMUM. Create required names in advance and verify the authoritative answers; adding a short-lived A record does not invalidate a negative answer already cached elsewhere.
Planning TTL Changes Before the Cutover
Start with an inventory of the current TTLs and every changed dependency. Set an overlap period based on those values and the application behavior, then decide how the old path will remain safe while traffic shifts. Immediate refresh by every resolver is not a condition you can enforce.
Lower TTL ahead of time
A proposed 300-second TTL is a common planning example, subject to the provider’s supported range and query load. Apply the lower value on all authoritative servers, then allow at least the previous TTL before cutover, with extra margin for dependencies. A previous 48-hour TTL needs more runway than a generic one-day recommendation. Include relevant A/AAAA records, CNAMEs and separate API or checkout hosts. This preparation does not shorten an answer already cached under the old value.
Keep the old server alive for a while
Keep the old path available while it still receives legitimate traffic and while rollback is required. One new short-TTL cycle is not a reliable retirement deadline. Check logs, active connections, application state and authoritative health. RFC 8767 also permits stale answers when a resolver cannot refresh from the authoritative service, so TTL should not be treated as an absolute global switch time.
Stage the change: one piece at a time
If you’re moving both web and email, do them in separate phases. Web first, then MX, or vice versa. Adjust TTLs for each record independently, cut over one service, watch it, then proceed. Choose windows with suitable traffic levels and available support coverage so each change can be observed.
A Practical Migration Sequence
The sequence below separates DNS preparation from application and data cutover. Adapt it to the actual architecture and test the failure and rollback paths before making the public change.
1) Prepare your new origin
Prepare the new runtime, files, configuration, certificates and database. For dynamic sites, define one authoritative write path; two independently writable copies can diverge even if they were initially identical. With one-way replication, measure lag, fence old writes and follow a controlled promotion sequence. Other options include sharing an appropriate data source or briefly pausing writes for final synchronization. Test the real hostname through a local override, including login, uploads and payment flows without causing real transactions.
2) Lower TTLs where it matters
Bring down TTL on your A/AAAA records and any CNAMEs involved. Do it well ahead. If you’re using a CDN, check whether the CDN is masking your origin in a way that affects visibility. And if you’re planning to change MX records, reduce those TTLs early as well. You can use a short TTL like 300 seconds, wait for at least one prior TTL period to pass, and confirm authoritative answers as well as sampled resolver responses.
3) Run a dry run with host overrides
Before you flip DNS, test by adding a temporary line to your local hosts file to point the domain at the new IP. It’s the closest you’ll get to how the real thing will behave. Test from multiple devices or a clean VM so you’re not accidentally using cached sessions. When moving from shared hosting to VPS, check PHP versions, extensions, and path differences that can trip up a live app. Local overrides do not redirect third-party webhooks or payment providers; test those separately and remove the override afterward.
4) Flip during your quietest window
After final synchronization and the controlled write handoff are complete, switch the A/AAAA records or the CNAME target to the new origin. Lowering TTL sufficiently early can shorten the refresh interval, but it does not set a global completion time. Some clients may continue using the old path beyond the new TTL, so keep that path safe until the retirement checks in the next step are satisfied.
5) Keep the old server forwarding
A tested reverse proxy on the old origin can send remaining traffic to the new application. Its upstream must point directly to the new destination or a dedicated origin name, not the public name that could resolve back to the proxy. Verify TLS/SNI, Host headers, redirects, cookies, client-IP trust and any WebSocket behavior. Watch both origins and keep forwarding until the retirement criteria are met; an arbitrary hour is not sufficient evidence.
6) Turn the TTL dial back up
Once the dust settles and you’re happy, bring the TTL back up to something stable. You don’t have to go huge; something like 1800 to 3600 seconds is a sweet spot for many sites. It keeps resolvers happy and load lower, with a corresponding longer preparation interval for future changes; these values do not promise a global completion time.
What If You Forgot to Lower TTL? Your “Oh No” Toolkit
We’ve all been there. The change is urgent, or it’s already in motion, and you realize the records are sitting at a comfy 4 hours or, gulp, a full day. Breathe. You still have options.
Use the old server as a bridge
If the old server is still in your control, a temporary reverse proxy may bridge traffic after configuration and application tests. Put a lightweight reverse proxy in place so any users stuck on the old IP get forwarded to the new origin. Validate the same upstream and state requirements described above before relying on it.
Plan a CNAME for future changes where appropriate
An A record contains an IPv4 address, not a CNAME target. For a suitable non-apex hostname, replacing an A record with a CNAME to a controlled origin name may simplify later changes, but the CNAME and target answers still have their own TTLs. It cannot invalidate an old cached A answer. At the zone apex, ordinary CNAME coexistence rules conflict with required SOA/NS records; provider-specific ALIAS/ANAME or flattening may return address records instead. Verify the provider’s behavior before adopting that design.
Leverage a CDN as a migration wrapper
If a CDN or reverse proxy is already in the traffic path, switch the origin within that layer. Adding one during an emergency usually requires its own DNS/TLS transition; it does not bypass old cached addresses. For an existing front layer, user-visible records can remain unchanged while the CDN just starts fetching from the new server. This is especially nice when your app needs a gradual move or a quick rollback. If you’re still deciding whether a CDN fits your setup, the related primer is what a CDN is and how it helps your website.
Be mindful of mail and third-party integrations
When you can’t lower TTLs ahead of time, mail systems and external services can bite. Web is easy to bridge, but MX cutovers and SPF/DKIM changes are less forgiving because different mail hops cache in their own peculiar ways. For a saner mail transition, the steps for SPF, DKIM, DMARC, and rDNS are covered in this friendly email deliverability guide. The short version: sequence changes, keep TTLs low for TXT and MX, and plan a measured overlap, mailbox synchronization and authentication checks.
A Quick Word on the Records That Sneak Up on You
Migrations are rarely just about “point A to point B.” There are a few DNS corners that people forget, and they’re often the ones that cause the frantic messages the next day.
NS changes and glue records
A nameserver migration changes delegation as well as ordinary record answers. Prepare and verify the complete zone on every new authoritative server before updating delegation, then keep both services consistent during overlap. Parent NS and relevant glue records have their own lifetimes; lowering an A record in the child zone does not shorten them. Plan DNSSEC DS/key handling separately. Registrar transfer and DNS-hosting migration are distinct operations; the domain transfer guide covers their coordination.
MX and the “mail drift” sensation
Mail can feel like it has a mind of its own during a move. Some senders will continue delivering to the old MX for a while. That’s normal. Keep the old delivery path reachable during a measured overlap, with a final mailbox sync or tested forwarding. Prevent loops and duplicate delivery; ordinary forwarding can affect SPF, so verify the chosen relay and authentication design. Don’t forget to align SPF, DKIM, and DMARC to reflect the new sending paths. If your new mail provider has a recommended TTL, use it during the move, then ratchet it up later.
Wildcards can hide complexity. If you’re using *.example.com and moving providers, double-check internal tools and undocumented subdomains that rely on the wildcard. Those often sit quietly at higher TTLs because nobody touches them. A few minutes spent crawling and grepping logs can save hours of post-migration cleanup.
DNSSEC considerations
If you have DNSSEC enabled, treat key changes and DS records with respect. Valid signatures alone are not enough: they must match the parent DS chain throughout the planned transition. Use the old and new providers’ supported DNSSEC migration procedure. The timeline is gentle but unforgiving if rushed. If you’re curious about the safety angle and how it actually protects you, the related explanation is what DNSSEC is and how it keeps your site safer.
Verification: Authoritative DNS, Resolvers and Applications
Use several independent checks. A few public-resolver samples can reveal problems, but cannot prove that every cache worldwide has refreshed. Combine them with authoritative answers and real application observations.
Local checks with specific resolvers
Start with a local lookup and then target specific resolvers. A quick dig A example.com followed by dig @8.8.8.8 A example.com and dig @1.1.1.1 A example.com samples their answers from your test location. Inspect the returned addresses and TTL values, but do not treat a countdown alone as proof that the new lower TTL has taken effect: an answer cached under the previous value can also count down. Also query each actual authoritative nameserver with dig and check A and AAAA separately. If stale answers persist, investigate authoritative reachability, delegation, negative caching and resolver policy rather than assuming waiting alone will fix it.
Resolver cache nudges
If something hangs longer than expected, there are a few gentle nudges you can try. For Google Public DNS, you can use the Google Public DNS cache flush tool to ask nicely for a refresh. A provider-specific tool such as OpenDNS CacheCheck, when available, only describes that provider’s service; querying it does not establish a global purge. For a sample of how selected remote probes resolve a name, WhatsMyDNS is a handy glance. Google’s flush affects Google Public DNS; it does not clear ISP, browser or application caches.
Application-level checks
Verify key endpoints, test logins, uploads and safe payment test flows, then confirm requests and resulting data on the intended origin. Watch error rates, latency, queue processing, sessions and missing configuration or runtime modules. External callbacks may still use normal DNS even when your laptop uses a hosts override. DNS resolution alone is not evidence that checkout or background processing works.
Speeding Things Up with Anycast, Health Checks, and Smart Routing
Once you get comfortable with basic TTL moves, the next level is making the internet work in your favor. Anycast DNS, smart failover, and weighted records don’t just help in a crisis—they make migrations smoother too.
Anycast DNS and why it feels faster
With Anycast, routing directs queries toward an advertised service location according to network policy, which is not necessarily the geographically nearest or fastest site. It’s like having a local post office in every city. The benefit during migrations is subtle but real: authoritative DNS can gain resilience and lower latency depending on topology, but existing recursive caches are not flushed. If you want to know how Anycast plus automatic failover can keep you up when everything else goes sideways, the related overview is this piece on Anycast DNS and failover.
Weighted and health-checked records
Some DNS providers let you split traffic across multiple targets with weights, or fail over to a secondary when the primary stops answering health checks. During a migration, this can support a gradual change. Weights apply to DNS answers, not exact end-user request proportions, and shared caches can skew the observed split. You start low weight to the new origin, observe behavior, then gradually raise it. If something breaks, DNS health checks can steer users back automatically while you fix the issue. It’s not instant (remember those caches), but it’s incredibly reassuring to have a parachute.
CDN origin swaps with grace
When a CDN is in front, you can often swap the origin in minutes without touching public DNS. That’s powerful. Where supported, read-only traffic can be shadowed safely for comparison. Do not replay orders, payments, emails or other side-effecting requests against a second live system. Validate the responses and state model before changing the origin. If your CDN supports blue-green style testing or request mirroring, the migration becomes less a cliff and more a sloped hill. The trick is making sure headers, cookies, and caching rules match your app’s assumptions so you don’t introduce weirdness mid-flight.
The Human Bits: Communication, Rollback, and Sanity
DNS moves aren’t just technical. They’re emotional. A calm plan and simple communication turn a nail-biter into a routine Tuesday.
Announce a window, even if you don’t need it
Share a migration window with stakeholders, even for zero‑downtime switches. This sets a shared expectation and calms everyone down. If something odd happens for a handful of users, you’ve already told them a change was in progress. That makes everything easier.
Make rollback boring
Plan traffic rollback and data rollback together. After writes reach the new database, simply restoring the old DNS address may expose stale data or lose new orders. Define how writes are paused, reconciled or replicated back, and whether the old application remains compatible with the updated schema. Keep the old origin available according to tested recovery criteria, and account for caches continuing to send traffic along both paths.
Measure what matters
Watch error rates, response times, and logs. Don’t obsess over every single DNS lookup—watch the app’s behavior in the real world. If analytics or server graphs show a traffic dip after the switch, investigate it rather than assuming success. Compare traffic across both origins and confirm successful user flows and resulting data; a quiet graph alone does not distinguish a healthy migration from requests failing to reach the application.
Record Types, Gotchas, and a Quick Refresher
If you’re feeling a little foggy about which records do what, that’s normal; DNS is a bag of three-letter acronyms. If you want a clean, friendly refresher, the walkthrough covers A, AAAA, CNAME, MX, TXT, SRV, and CAA and their pitfalls in DNS records explained like a friend. The short version for migrations: A/AAAA move users, CNAMEs help you manage targets, MX moves mail, TXT updates policies, and SRV hides in apps you forgot use it. CAA can block new certificates if it’s misconfigured, so keep it updated if you change certificate providers during the move.
Common Migration Questions
“How low should I set TTL?”
For illustration, 300 seconds balances a shorter refresh interval against DNS query load in many configurations. A 60-second TTL may be supported, but changing it during an emergency does not shorten old cached answers. Steady-state values such as 1800–3600 seconds are options rather than rules. Choose the value using provider limits, authoritative capacity and the preparation time acceptable for future changes.
“How long will propagation take?”
The honest answer: it depends on which answers were cached, their previous TTLs and the behavior of the clients and resolvers involved. Lowering TTL sufficiently early can reduce the delay, but it does not guarantee completion within minutes. If old answers persist beyond the expected interval, compare authoritative answers with samples from several resolvers and investigate reachability, delegation, negative caching and resolver policy. A supported cache-flush tool affects only its provider’s cache, not every user’s path.
It may be possible when the application and provider capabilities support a safe overlap; TTL alone cannot guarantee it. Shorten TTL sufficiently early, sync content, dry run with a hosts override, and complete final synchronization and a controlled write handoff before changing DNS. Keep the old host proxying only if the provider supports the tested configuration, and retain the old path until traffic and recovery checks justify retirement. Increase TTL once the service is stable. For a focused checklist, see moving from shared hosting to a VPS with zero downtime. It’s the same spirit we’ve been talking about here, just focused on that specific jump.
A Tiny Bit of Myth-Busting
Propagation gets treated like a mysterious fog rolling across the world. It’s not. It’s just cached answers expiring on their own timelines. You can plan for those timelines, shorten them where you control them, and bridge around them where you don’t. When a migration goes smoothly, it looks like nothing happened. And that’s the best compliment you can get in this job.
Wrap-Up: The Calm Way to Move Fast
The operating principle is to use TTL like a dimmer, not a switch. Lower it early where it matters, test quietly behind the scenes, complete the controlled data and write handoff, and flip during a calm window. Keep the old path safe until traffic and recovery checks justify retiring it, then raise TTL once the service is stable. When you can, lean on tools like Anycast, health checks, and CDNs to give yourself guardrails. A tested reverse proxy on the old host can bridge remaining traffic where the hosting platform supports it; it does not replace the data-consistency plan.
And don’t forget the less glamorous parts: mail records, wildcards, and security settings that might be hiding in the attic. Keep your playbook simple, your rollback obvious, and your communication kind. If this helped you sketch a plan for your next move, use it as the basis for a rehearsal. If you want to go deeper on the resilience side, the related guide explains how Anycast DNS and automatic failover keep your site up, and if your brain just wants a soothing refresher, that DNS records explained like a friend article is there for you. Hope this was helpful! See you in the next post—and may your next cutover be so smooth nobody notices it happened.
