TTL and DNS Caching: Why DNS Changes Are Not Instant

When you change a DNS record and it does not update everywhere at once, nothing is broken. That gap is caused by TTL and DNS caching, and understanding both explains why a change you just made in cPanel can take minutes or hours to reach every visitor. This Ultra Web Hosting guide covers what TTL actually is, how caching works across the internet, how to plan a change so the switch is fast, and how to check what the world is currently seeing.

01. What TTL Actually Is

TTL stands for Time To Live. It is a value attached to every DNS record, expressed in seconds, that tells any resolver how long it may cache the answer before it has to ask again. A record with a TTL of 3600 may be remembered for one hour. A record with a TTL of 300 may be remembered for five minutes. Once that clock runs out, the cached copy is discarded and the next request goes back to your authoritative nameservers for a fresh answer.

TTL is set per record, not per domain. Your www A record can have a TTL of 86400 while a record you are actively migrating sits at 300. Common values you will see in the wild:

• 300 - five minutes. Fast to change, slightly more query traffic.
• 3600 - one hour. A sensible default for most records.
• 86400 - one full day. Good for records that almost never change.

02. How DNS Caching Works Across the Chain

When someone types your domain, the answer is not fetched fresh from your nameservers every time. It passes through a chain of caches, and each link can hold a copy for up to the TTL:

1. Your device. The operating system keeps a small DNS cache. Your browser keeps its own on top of that.
2. Your router. Most home and office routers cache DNS for the whole local network.
3. Your ISP resolver. The recursive resolver your ISP runs caches answers for every customer, which is where most of the "lag" lives.
4. Public resolvers. If you use Cloudflare's 1.1.1.1 or Google's 8.8.8.8 instead of your ISP, those hold their own caches shared by millions of users.
5. Your authoritative nameservers. The source of truth. On Ultra Web Hosting that is ns1.ultranameservers.com, ns2.ultranameservers.com, and ns3.ultranameservers.com. This is the only copy you edit.

Here is the key point: a change you make at the authoritative layer is only seen by a given resolver after that resolver's cached copy expires. Your home router might still hold the old answer for another 40 minutes while a public resolver on the other side of the country already fetched the new one. That is why a change looks "done" on your phone's mobile data but not on your office wifi at the same moment.

03. TTL and "Propagation": The Honest Explanation

You will hear people say DNS changes need time to "propagate," as if your new record is being pushed out across the internet. That is not how it works, and the misunderstanding causes a lot of needless anxiety during a migration.

There is no push. Nothing is broadcast. When you save a record, your authoritative nameservers update immediately, within seconds. Every other cache in the world keeps serving its old copy until that copy's TTL expires, and only then does it come back and pick up your new value. "Propagation" is just the sum of all those caches timing out at their own pace.

The practical takeaway: the maximum time anyone can be stuck on your old record is the TTL that was in effect before you made the change. If that TTL was 86400, some caches will hold the old answer for a full day. If you had already lowered it to 300, the longest anyone waits is five minutes. This is why the playbook in Section 05 lowers the TTL first.

04. Choosing a TTL: Long vs Short

There is no single correct TTL. The right value depends on how often the record changes and how much you care about fast switches versus minimal query load.

For a typical hosting account, 3600 is a fine everyday value for most records. Drop to 300 only around a planned change, then put it back. Going below 300 rarely helps and just adds query noise; many resolvers quietly enforce a floor anyway.

05. The Planned-Change Playbook

This is the sequence that makes a DNS migration or IP change feel quick and clean. It works because you shrink the TTL before you make the real change, so the old value has already drained out of every cache by the time it matters.

1. A day or two before the change, edit the record in cPanel Zone Editor and lower its TTL to 300. Do not change anything else yet.
2. Wait out the old TTL. If the record was previously at 86400, wait a full day so every cache has fetched the new short-TTL version. This step is the whole point; skipping it wastes the effort.
3. Make the actual change. Update the record's value (the new IP, new MX target, and so on). With TTL at 300, caches now refresh every five minutes.
4. Confirm the new value is live using the DNS Lookup tool at tools.ultrawebhosting.com, or with dig as shown in Section 07.
5. Once everything is confirmed stable, raise the TTL back to 3600 (or higher) so you are not paying the extra query cost long term.

06. Where to Set TTL in cPanel

If your domain uses our nameservers (ns1, ns2, and ns3.ultranameservers.com), you set TTL per record in the cPanel Zone Editor.

1. Log in to cPanel and open Zone Editor under the Domains section.
2. Find your domain and click Manage.
3. Locate the record you want to adjust, click Edit, and change the TTL field to the number of seconds you want (for example 300 or 3600).
4. Click Save Record. The new TTL applies to lookups that happen from this point forward.

07. Checking the Current TTL and Remaining Cache

You do not have to guess what the world is seeing. Two easy ways to check the live TTL:

Our DNS Lookup Tool

The fastest option is the DNS Lookup tool at tools.ultrawebhosting.com. Enter your domain, pick the record type, and it shows the current value your authoritative nameservers are serving along with the TTL. Use this to confirm a change is live at the source.

Using dig

On macOS or Linux (or Windows via WSL), dig shows the TTL as a number that counts down. Run it twice a few seconds apart against a public resolver and watch the number drop; when it hits zero, that resolver fetches a fresh copy.

dig @1.1.1.1 www.yourdomain.com A

;; ANSWER SECTION:
www.yourdomain.com.  2847  IN  A  203.0.113.10

That 2847 is the seconds remaining before Cloudflare's resolver re-fetches this record. Query your authoritative nameserver directly to see the full configured TTL rather than a countdown:

dig @ns1.ultranameservers.com www.yourdomain.com A +noall +answer

08. Flushing Local Caches

You can clear the caches you control: your own browser and operating system. You cannot flush your ISP's resolver, a public resolver, or a visitor's device. Those only clear when their TTL expires. Flushing is useful when a change is confirmed live at the source but your own machine still shows the old result.

# Windows (Command Prompt or PowerShell)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Browser: also clear the browser's own DNS cache.
# Chrome: visit chrome://net-internals/#dns and click Clear host cache.

09. Troubleshooting: Some Visitors See the Old Site

Half my visitors see the new site and half see the old one. Normal and temporary. Different caches at different stages of the chain are expiring on their own schedules. Give it up to the old record's TTL. If that TTL was long and you did not lower it first, this is the day-long tail you are paying for.

I see the change but a colleague does not. Your machine or resolver already refreshed; theirs has not. Have them flush their local cache (Section 08) or wait out the TTL. Nothing is misconfigured.

The change is not showing anywhere, even at the source. That is not a caching issue, it is likely the record itself. Confirm the record saved correctly and that your domain is actually on our nameservers with the DNS Lookup tool at tools.ultrawebhosting.com. See DNS Changed But Site Not Showing for the full checklist.

My domain still loads a parked or placeholder page. That can be a pointer or parked-domain configuration rather than pure caching. See Domain Pointers and Parked Domains to check how the domain is set up.

Email started bouncing right after an MX change. Cached MX records are still routing to the old server. Same TTL rules apply; it clears as the old MX TTL drains. Confirm the new MX at the source, then wait it out. See How Do I Change My MX Records.

Quick Recap: TTL and DNS Caching

If you remember only a handful of things from this guide, make it these:

1. TTL is seconds of caching. Every record carries one, and it tells resolvers how long to remember the answer before asking again.
2. Nothing is pushed. Your nameservers update instantly; the wait is just old cached copies draining out at their own TTL.
3. The old TTL is the worst case. The longest anyone stays on the old record equals the TTL that was in effect before you changed it.
4. Lower TTL before a planned change, wait out the old value, make the change, then raise the TTL back afterward.
5. Check with our DNS Lookup tool or dig, and flush only your own browser and OS caches. You cannot flush other people's resolvers.
6. MX records follow the same rules, so treat a mail move exactly like a site move and lower the MX TTL ahead of time.

Last updated July 2026 · Browse all DNS articles