DNS Basics
TTL in DNS: How Long a Record Stays Cached
TTL sets how long resolvers around the world are allowed to remember a DNS answer before checking again — get it wrong and a planned change can take a day to fully show up.
300s
A commonly used low TTL before a planned change
3600s
A typical default TTL (one hour) for stable records
24-48h
Old TTL's worst-case caching window if left high
24/7
Human support for DNS and migration timing
In short
TTL, or time-to-live, is a number attached to every DNS record that tells resolvers how many seconds they're allowed to cache that answer before asking the authoritative nameserver again. A record set to 3600 can be remembered by a resolver for up to an hour after the last lookup, so a change made right after that cache fills won't be seen by that resolver until the hour runs out.
TTL only controls caching, not whether a change was applied — the authoritative DNS zone updates immediately, but every resolver that already cached the old value keeps serving it until its own TTL expires, which is why planned changes need the TTL lowered in advance, not adjusted after the fact.
Every DNS record — A, CNAME, MX, TXT — carries a TTL value measured in seconds, and it's easy to overlook until a migration or a hosting move goes wrong: the new server is live, the record was updated correctly, and yet a portion of visitors still land on the old IP address for hours. That's not a broken change, it's TTL doing exactly what it's supposed to do — honoring a caching instruction set long before anyone thought to change it.
Because TTL is read by every resolver between the browser and the authoritative nameserver, from a visitor's ISP to a corporate DNS server to a phone's carrier network, the same record can appear to update at wildly different speeds depending on which resolver a given visitor happens to be using and when that resolver last refreshed its cache.
What TTL Actually Controls
TTL is a per-record setting, expressed in seconds, that instructs any resolver caching that record how long to keep serving the cached answer before it's required to check back with the authoritative nameserver for a fresh copy. A TTL of 300 means a resolver should re-check after five minutes; a TTL of 86400 means it can go a full day without asking again.
This exists purely for efficiency — without caching, every single page load would require a fresh DNS lookup all the way back to the authoritative server, adding latency to every request on the internet. TTL is the dial that balances that efficiency against how quickly a change actually reaches everyone once it's made.
Why a High TTL Delays a Migration You Just Made
Changing a record in the DNS zone takes effect at the authoritative nameserver instantly, but every resolver that already has the old value cached has no reason to ask again until its cached copy's TTL expires — it doesn't know the record changed, because that's the entire point of caching. A record left at a high TTL, such as 86400 seconds, can mean a meaningful share of visitors keep hitting the old server for up to a full day after the switch.
This is the single most common cause of a migration that 'worked but didn't' — the new server is correctly configured and reachable, the DNS zone shows the new value, and yet support tickets come in from users still seeing the old site, simply because their specific resolver hadn't re-checked yet.
The Lower-TTL-Before-Migration Strategy
The fix is to lower TTL in advance, not after the change: at least 24-48 hours before a planned DNS or hosting migration, edit the record's TTL down to something short, commonly 300 seconds (five minutes), and leave the rest of the record untouched. That low value then has time to propagate itself, so that by the time the real change happens, every resolver has already re-checked recently and is only caching for a few minutes at most.
Once the actual migration is made and confirmed stable, typically after a few days, TTL can be raised back to its normal higher value, since a very low TTL indefinitely means more constant lookup traffic against the authoritative nameservers than is necessary for a record that isn't changing anymore.
Choosing a Sensible TTL Day to Day
Outside of a planned change, most records are fine sitting at a moderate default — commonly 3600 seconds (one hour) — which balances resolver efficiency against reasonable responsiveness if something does need adjusting unexpectedly. Records that genuinely never change, and where fast propagation isn't a concern, can sit at a higher value without any real downside.
The records worth keeping deliberately low year-round are ones tied to failover or load-balancing setups where a fast switch actually matters operationally; for a typical single-server website, the practical habit is simple — leave TTL at a sensible default, and only lower it in the days before a planned migration.
Migrate on a Schedule You Control, Not DNS Caching
A migration timed around TTL, rather than against it, is the difference between a clean cutover and days of intermittent reports that the 'new site isn't showing up' for some visitors.
Hosting Cheap's team walks through the TTL-lowering step as part of every free managed migration, so DNS catches up before the switch, not after it.
- Free managed migration including DNS timing guidance
- Clear nameserver and record details provided upfront
- 24/7 human support for TTL or propagation questions
- NVMe SSD + LiteSpeed ready the moment DNS catches up
Why Hosting Cheap
What you get
Free managed migration
Get the DNS and TTL timing handled as part of moving your site over, not left to guesswork.
Clear DNS details provided
Nameserver and record information is given upfront so TTL can be lowered before any change is made.
24/7 human support
Get a straight answer on how long a specific DNS change will take to fully propagate.
NVMe SSD + LiteSpeed
The destination server is fast and ready the moment resolvers catch up to the new record.
Free auto-renewing SSL
A certificate issues for the domain as soon as it's fully pointed at the new hosting.
30-day money-back guarantee
Move with confidence, knowing there's a refund window if the migration doesn't work out.
How It Works
Get set up in a few steps
Lower TTL in advance
Edit the record's TTL down to a short value, such as 300 seconds, at least a day or two before the planned change.
Make the actual DNS change
Update the A record, CNAME, or nameservers once the low TTL has had time to propagate on its own.
Raise TTL back once stable
After confirming the new setup works reliably for a few days, return TTL to its normal higher value.
Included
Everything you need, on every plan
- Current TTL checked before making any planned DNS change
- TTL lowered to a short value at least 24-48 hours ahead of a migration
- Actual record change made only after the low TTL has propagated
- New destination server or IP fully tested before the switch
- Free SSL confirmed active on the new destination post-switch
- TTL raised back to a normal value once the change is confirmed stable
- Any dependent records, such as MX or CNAME, checked for their own TTL
- Support contacted if visitors still report the old site well past the expected window
FAQ
Frequently asked questions
What is TTL in DNS in simple terms?
TTL, or time-to-live, is a number in seconds attached to a DNS record that tells resolvers how long they can cache that answer before checking the authoritative nameserver again. A lower TTL means faster-visible changes; a higher TTL means fewer repeated lookups.
What TTL should I set before a migration?
A common practice is lowering TTL to around 300 seconds (five minutes) at least 24-48 hours before the planned change, giving that shorter caching window time to propagate first. Making the real change only after that low value is already in effect minimizes how long any visitor sees the old server.
Does changing TTL after making a DNS change help?
No — TTL only affects how the change is cached going forward, not records already cached under the old, higher TTL. Lowering TTL has to happen before the change to have any effect on how fast it propagates.
Why do some visitors see my new site immediately while others don't for a day?
Different resolvers cache the same record independently and re-check at different times based on when they last looked it up and what TTL was in effect then. That's why propagation looks inconsistent across visitors rather than happening all at once.
What's a good default TTL for records that rarely change?
A moderate value, commonly 3600 seconds (one hour), balances reasonable responsiveness against unnecessary lookup traffic for records that aren't expected to change often. It only needs lowering temporarily around a planned change.
Does TTL affect email (MX records) the same way as website records?
Yes, MX records cache under the same TTL rules as any other DNS record, so a mail server migration benefits from the same lower-TTL-in-advance approach. Overlooking MX TTL during a hosting move is a common reason email delivery lags behind the website switch.
Ready to Migrate Without the DNS Guesswork?
Get free managed migration with TTL timing handled, plus NVMe hosting from $2.09/mo.
Get Started