Engineering Glossary · DNS
TTL Is the Only Part of Propagation You Get to Schedule
You have a cutover booked for Tuesday night and you need it to finish before the office logs in on Wednesday.
The short answer
TTL is the number of seconds a resolver may keep reusing a cached DNS answer, and therefore the only lever you hold over how quickly a change reaches the world. Lower it in advance and a cutover completes in minutes; leave it alone and the change runs on whatever value was already in force.
That last clause is the whole trick. The TTL governing today's edit is the one that was cached before you made it, so dropping the value at the same moment you change the record does nothing at all for this change — only for the next one.
By the HostingFast team · Reviewed 12 August 2026
100+
Terms defined properly
2 min
Read time, end to end
Plain
English, no hand-waving
24/7
Engineers on shift
Long values, measured in hours, cut query volume and add resilience: if your nameservers become unreachable, resolvers keep serving the last good answer until the timer runs out. Short values, measured in minutes, make you agile and make every resolver ask more often.
Both are correct in the right place. Records that never move can sit at hours. Records inside a planned migration belong at minutes, for the duration of the migration and no longer, because a permanently short TTL taxes resolvers for agility you almost never use.
Watching a TTL count down
You can see caching happen. Query a record through a public recursive resolver twice in quick succession and read the TTL in each answer: the first is the full value, the second is lower by roughly the seconds that elapsed. That countdown is the resolver telling you exactly how long it intends to keep ignoring your changes.
Query your authoritative nameserver directly instead and the value is always the full TTL, because there is no cache in front of it. The gap between those two answers is the clearest demonstration of what propagation actually is.
The cutover timetable, written out
Day minus one, at least one full old-TTL cycle before the change: lower the TTL on the records you intend to move and confirm the new value is being handed out. Cutover: make the change. Day plus one: put the TTLs back up.
If the old value was four hours, you must lower it at least four hours in advance — earlier is safer. Skipping that first step is the reason so many migrations that were planned as a five-minute window turn into a day of mixed results.
What TTL cannot do for you
Delegation records live in the parent zone and carry a TTL set by the registry, typically long and not yours to change. A nameserver switch therefore has a tail you cannot compress, which is a good argument for moving a site with an A record change rather than a delegation change when both are options.
Negative answers are cached too, on a value taken from the zone's SOA record. Publish a name, get the spelling wrong, fix it two minutes later, and some resolvers will still be returning the failure for as long as that negative cache lasts.
TTL controls on this platform
Every record in the zone editor carries its own TTL, so you can drop one record to five minutes for a migration and leave the rest at their normal values rather than making the whole zone chatty.
SSH, Git and Composer on the developer-focused plans mean the application side of a cutover can be scripted to the same schedule as the DNS side, which is usually what turns a nervous evening into a routine one.
Timings, thresholds and the order to do things in
A reference is most useful when it tells you when to do something, not only what it is. These entries carry the sequence as well as the definition.
Per-site PHP version switching from the control panel means a legacy application and a current one can run side by side on one account.
- 100+ entries with the sequence included
- Cutover timetables, not vague reassurance
- Wired into DNS, Propagation and A Record
- Written by engineers who have run the change
Why HostingFast
Standard on every plan
A schedule, not a wait
TTL turns propagation from weather you endure into a window you booked.
TTL, demonstrated
The countdown is visible in two consecutive queries, and this entry shows you where to look.
The one-cycle rule
Why lowering a TTL on the day achieves nothing, stated before you find out the hard way.
Limits acknowledged
Parent-zone TTLs and negative caching are outside your control, and pretending otherwise wastes an evening.
Per-record control
Drop one record for a migration instead of making the whole zone noisy.
Continues into its neighbours
DNS, DNS Propagation and A Record carry on from here.
Quick Start
From order to online
- 1
Read the current value from a cache
Query the record through a public resolver twice and watch the TTL fall. That figure is how long your next change will take to reach that resolver.
- 2
Lower it a full cycle before the change
If the value is four hours, drop it at least four hours ahead. Anything less and the change runs on the old timer regardless.
- 3
Confirm the new value is being served
Query your authoritative server and check the short TTL is actually in the answer before you rely on it.
- 4
Restore the value afterwards
Put the TTL back the following day. Permanently short values buy agility you are not using and cost query volume you are.
Built In
Loaded onto every plan
- Per-record TTL control in the zone editor
- SSH, Git and Composer on developer-focused plans
- Staging environments for rehearsing a release
- Daily backups with self-service restores
- 99.9% uptime target, monitored around the clock
- NVMe SSD storage on every tier
- Money-back cover: 30 days on hosting plans, 7 on reseller
- cPanel as standard, with full zone editing
Frequently Asked
What people ask us most often
What TTL should I actually set?
One to four hours for records that do not move — it keeps query volume sensible and means a nameserver problem does not become an instant outage. Five minutes for anything inside a planned change, for the duration of that change only. Leaving everything permanently at 300 seconds buys agility you use twice a year and pays for it every day.
I lowered the TTL and the change still took hours. What happened?
The old value applied. Any resolver already holding a four-hour answer keeps ignoring your new five-minute value until that original timer expires. The lower value only governs the next change, which is why the drop has to happen at least one full old-TTL cycle before the cutover.
Why do bad records seem to linger even after I fix them?
Negative caching. A failed lookup is cached too, using a value derived from your zone's SOA record, so a typo you corrected two minutes later can keep returning a failure for considerably longer than you expect. It is the same mechanism as ordinary caching, applied to the absence of an answer.
Can I choose my own PHP version?
Yes — PHP is set per site from the control panel, so a legacy application and a current one run side by side on one account. Extensions and per-site tuning are on the same screen, and none of it needs a support ticket.
Keep reading
A Record
The record most cutovers actually change, and how to test the destination first.
Nameserver
The servers that answer with these values, and how to time their replies.
How to Reduce Server Response Time
Cutting server response time, measured properly at each layer.
SSL Certificates
Free SSL on every plan, with wildcard and EV available when you need more.
Secure Hosting
Imunify360, isolated accounts and hardened defaults for security-first builds.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Book the window, do not wait for one.
Scaling from one site to a rack of servers is an account change here, not a migration you have to survive.
View SSL Certificates plans