Cache Clocks
Which TTL Governs a Change You Have Not Made Yet
Lowering a TTL today does nothing for today's edit — it buys you speed on the next one, which is why the drill starts a day early.
The short answer
A record's TTL is the number of seconds a resolver may keep reusing the answer it has before asking again. It is published with every answer, so it is the record's own instruction to the rest of the internet about how stale it is allowed to get.
The consequence people learn the hard way: the TTL that governs any change is the one that was already in force when the previous answer was cached. Drop a four-hour TTL to five minutes and save a new address in the same sitting, and resolvers holding the old answer will ignore both for up to four hours.
So a TTL is a scheduling tool, not a fix. Lower it in advance and the change you make tomorrow is quick.
By the Hosting & Domains team · Reviewed 18 August 2026
100+
Entries in this domains reference
2 min
Read time, roughly
Plain
English, no registry jargon
24/7
Desk cover, every day
Long values mean fewer queries, more resilience if your nameservers become briefly unreachable, and slower changes. Short values mean the opposite: an edit reaches the world in minutes, at the cost of far more traffic to your nameservers and a much smaller cushion if they go quiet.
Neither is correct in the abstract. What matters is whether a record is about to move. Anything stable can sit on hours; anything caught up in a planned migration wants minutes, set the day before rather than on the night.
The value in force is the old one
Caching is one-directional. A resolver that asked an hour ago holds whatever TTL it was given then, and it will not come back for a new instruction until that timer expires. Nothing you do in the meantime — not editing the record, not lowering the TTL, not flushing your own machine — reaches inside somebody else's cache.
That is the single fact that turns DNS work from nerves into scheduling. Lower first, wait out one full cycle of the old value, then make the change. Now propagation is a number you chose.
Values that suit each kind of record
Records that never move — the apex A record on a settled site, the MX set for an established mail provider — sit comfortably on one to four hours. Records in the middle of a move want five minutes. Nameserver delegations are cached far longer and are not really yours to tune, so treat them as a day rather than an hour.
The MX set deserves a mention of its own. Short TTLs on mail records make a cutover quick, but they also mean that if your nameservers become unreachable, sending servers lose their cached answer faster and start bouncing sooner. Return MX records to hours once a migration is finished.
The three-step drill for a planned move
Day one: lower the TTL on every record you intend to change, and note what the old value was. Wait at least one full old-TTL cycle, which is why 24 hours ahead is the safe habit rather than four. Day two: make the change. The world follows within minutes. Day three: put the TTLs back where they were.
The step people skip is the third. A zone left permanently on 300 seconds because of a migration two years ago is quietly paying for agility nobody is using, and has a much thinner safety margin than its owner realises.
The timers you do not control
Your record TTLs are only part of the picture. The registry publishes its own timers on the referral to your nameservers, commonly measured in days, which is why a delegation change takes longer to settle than a record change. Some resolvers clamp very low TTLs upwards or very high ones downwards. And negative answers cache too, on a value taken from the zone's SOA record.
That last one explains a common confusion: a brand-new subdomain that refuses to resolve for a while even though the record exists. Something asked for it before you created it, was told it did not exist, and is honouring that answer for as long as the negative cache allows.
Why a permanently short TTL is not free. Every expiry is a fresh query. Multiply five minutes across a busy site's resolver population and you are generating a great deal of traffic to buy an agility you use twice a year. More importantly, the cache is your outage insurance: while a cached answer lives, a brief nameserver problem is invisible to visitors.
Set TTLs for the state the zone is actually in. Short while you are working on it, ordinary the rest of the time.
Propagation as a number you chose
'DNS is slow' is almost always 'the TTL you set last year is still running'. This reference treats the clock as the thing you plan around, which turns a nervous evening into a scheduled ten minutes.
A free SSL certificate comes with every plan and reissues itself before the old one lapses — the padlock is never yours to diarise.
- The old-value rule stated plainly
- Sensible values per record type
- Registry and negative-cache timers included
- 100+ entries, cross-linked to their neighbours
Why Hosting & Domains
Standard on every plan
Per-record TTLs in the panel
Set the value on each record from cPanel's zone editor, so a migration drill is a few minutes of work rather than a ticket.
The whole zone visible at once
Every record and its TTL on one screen, which is how you find the one you forgot to put back.
Migrations staged before the switch
Our engineers copy the site and rebuild the records, and you verify the destination before any TTL matters.
Certificates that keep up
Free SSL issues and reissues itself once the name resolves here, so a cutover does not leave a warning page behind.
Staging to rehearse on
Staging copies let you prove the destination works before a single resolver is asked to point at it.
Answers at any hour
People on the support desk every hour of every day, including at the awkward end of a cutover.
Quick Start
Order placed to site online
- 1
Lower the TTLs a day ahead
Every record you plan to change, plus a note of the old values. Waiting out one full old cycle is the entire point of doing it early.
- 2
Make the change once the cycle has passed
Edit the records. Resolvers now come back within minutes because that is what you told them to do yesterday.
- 3
Verify against a public resolver
Not the browser you have been reloading. When an outside resolver agrees with your authoritative answer, the change has landed.
- 4
Put the values back
Return the TTLs to hours. The cushion they provide is what keeps a brief nameserver hiccup invisible to visitors.
Built In
Fitted to every plan
- Per-record TTLs editable from the cPanel zone editor
- A zone editor showing every record and its TTL on one screen
- MX, SPF, DKIM and DMARC rebuilt by our engineers during a migration
- Staging copies for trying a change before it goes live
- Free SSL on every plan, reissued before the old one lapses
- Mailboxes that answer at the name you hold
- A renewal figure identical to the one you registered at
- Your existing site brought across by our engineers, at no charge
- NVMe SSD storage on every tier, not only the dear ones
- People on the support desk every hour of every day
Frequently Asked
Questions we field again and again
How far ahead of a migration should I lower TTLs?
At least one full cycle of the current value, and 24 hours is the habit worth keeping because it covers whatever the current value turns out to be. Lowering the TTL and changing the record in the same sitting achieves nothing for anyone already holding the old answer.
Does the TTL on the nameserver delegation matter?
It does, and it is not really yours. Referrals to your nameservers are cached on the registry's timers, typically far longer than your record TTLs, which is why a delegation change settles over a day or two while a record change settles in minutes. Plan a nameserver change accordingly.
My new subdomain will not resolve even though the record exists. Why?
Negative caching. Something asked for that hostname before you created it, was told authoritatively that it did not exist, and is honouring that answer for the period the zone's SOA record specifies. Wait it out; editing the record again will not help.
Can I set a different TTL on each record?
Yes, and you should. TTL is a per-record value, so the records you are about to move can sit on minutes while everything stable stays on hours. Lowering the whole zone is a blunt instrument that costs you resilience you did not need to spend.
Keep reading
SSL Certificates
Free SSL on every plan, with wildcard and EV there when more is needed.
Secure Hosting
Imunify360, isolated accounts and hardened defaults for security-first builds.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Schedule the change instead of waiting for it.
Per-record TTLs in the panel, migrations staged and verified first, certificates that reissue themselves, and support at any hour.
View SSL Certificates plans