DNS Propagation: Why Changes Take Time

You point your domain to a new server, hit save, and refresh the page. Nothing changes. A friend in another city says they already see the new site, but you still get the old one. A coworker sees something in between. If this has ever made you doubt whether you saved the change at all, you are not alone — and almost certainly, you did everything right.

What you are bumping into is called DNS propagation. It is one of the most misunderstood parts of running a website, mostly because the name itself is a little misleading. In this article we will walk through what is actually happening behind the scenes, why the delay exists, and what you can do to make future changes go more smoothly. By the end, that “it still shows the old site” feeling should stop being mysterious and start being predictable.

A quick refresher: what DNS does

Before we talk about propagation, let’s make sure the foundation is solid.

Every website lives on a server, and every server has a numeric address called an IP address — something like 192.0.2.45. Computers love numbers; people do not. Nobody wants to type a string of digits to visit a site. So instead we type a friendly name like acy-partner.com.

DNS, the Domain Name System, is the service that translates those friendly names into the numbers computers actually need. A useful way to picture it: DNS is the phone book of the internet. You look up a name, and it hands back the number to dial.

When you “change a DNS record,” you are essentially editing one line in that phone book. For example, you might change the A record (the one that maps a name to an IP address) so that acy-partner.com now points to a brand-new server.

The catch is this: there is not just one phone book. There are millions of copies, scattered all over the world, and they do not all get updated at the same instant.

Why the change isn’t instant: caching

Here is the heart of the matter. Looking up a DNS record from the original, authoritative source every single time would be slow and wasteful. Billions of people visit websites every day; if each visit triggered a fresh lookup across the globe, the whole system would crawl.

To avoid that, DNS relies heavily on caching. Caching just means “keeping a temporary copy of an answer so you don’t have to ask again right away.”

When your computer or your internet provider looks up acy-partner.com, it does not just use the answer and throw it away. It saves that answer for a while. The next time anyone on that network asks for the same name, the saved copy gets handed back instantly — no need to travel across the internet to ask the authoritative server again.

This caching does not happen in one place. It happens in layers:

You (browser)              keeps its own small cache
   ↓
Your operating system      keeps a cache too
   ↓
Your ISP's resolver        caches answers for ALL its customers
   ↓
Other resolvers worldwide  each cache independently
   ↓
Authoritative server       the original, "true" record lives here

When you edit a record, you change it at the bottom — the authoritative server. But all those cached copies above it are still holding the old answer. They will keep serving that old answer until their saved copy expires. Until then, anyone relying on that cache sees the previous record.

That is why the change feels uneven: different people are talking to different caches, and those caches expire at different moments.

TTL: the timer that controls everything

So how long does a cached copy live before it expires? That is decided by a single setting called TTL, short for Time To Live.

Every DNS record carries a TTL value, measured in seconds. It is an instruction that says, in effect: “After you fetch this answer, you are allowed to keep using it for this many seconds before you must ask again.”

A few common values translated into plain time:

Here is the key insight: the TTL that matters for your change is the one that was in effect before you made the change.

Imagine the TTL on your record was 86400 (24 hours). Right before you edited it, some resolver in another country fetched the old answer. That resolver is now allowed to keep using the old answer for up to 24 hours, no matter what you do afterward. Your edit happened, but that cache already made its promise. It will only come back to ask for the fresh record once its 24-hour clock runs out.

This is why “DNS propagation” can take anywhere from a few minutes to a couple of days. It is not random and it is not broken — it is just caches counting down their individual timers.

TTL = 3600 (1 hour)

10:00  Resolver fetches OLD record, starts its 1-hour timer
10:15  You change the record at the authoritative server
10:30  Visitors via this resolver → still see OLD (timer not done)
11:00  Timer hits zero → resolver asks again → gets NEW record
11:01  Visitors via this resolver → now see NEW

Why people see different things at the same time

Once you understand TTL, the “everyone sees something different” puzzle solves itself.

Each resolver around the world fetched the old record at its own moment, so each one started its TTL countdown at a different time. A resolver that happened to fetch your record five minutes before your change will expire its copy first. One that fetched it an hour earlier might already be due to refresh. Another that fetched it just after your change already has the new answer.

Add in the fact that your own browser and operating system keep their own little caches, and you can even get the strange situation where your phone shows the new site but your laptop on the same Wi-Fi still shows the old one. They simply cached the answer at different times.

# Ask a public resolver what it currently has cached
nslookup acy-partner.com 8.8.8.8

# On macOS/Linux, 'dig' even shows the remaining TTL countdown
dig acy-partner.com

How to plan changes so they go smoothly

You cannot make caches expire faster after the fact — but with a little planning beforehand, you can make a DNS change feel almost instant. The trick is to think about TTL before you switch anything.

Lower the TTL ahead of time

This is the single most useful tactic. Well before the day you plan to change a record, lower its TTL to something small, like 300 seconds (5 minutes).

Why ahead of time? Because lowering the TTL today only takes full effect once the old, higher TTL has expired everywhere. So if your record currently has a 24-hour TTL, you would:

1. A day or two early: drop the TTL to 300 and save. Now you wait out the old 24-hour caches one last time.
2. On switch day: make your real change. Because every cache is now refreshing every 5 minutes, the new record reaches almost everyone within minutes.
3. A day later: once everything is stable, raise the TTL back up (say, to 3600 or higher) so the system is efficient again.

Don’t delete the old server too soon

A common mistake is to point the domain at a new server and immediately shut down the old one. Remember that some visitors will still be routed to the old address until their cache expires. Keep the old server running for at least as long as the original TTL, so nobody hits a dead end during the overlap.

Double-check the record before you save

Many “propagation problems” are really just typos. A missing letter in an IP address, an extra space, or the wrong record type can send people to nowhere. Because the wrong value will get cached and stick around for the full TTL, a small mistake costs you the whole waiting period twice — once for the bad record, once for the fix. Read it carefully before saving.

A simple mental model to keep

If you remember one thing, make it this: a DNS change is saved instantly, but the rest of the world is allowed to keep using its old, cached copy until that copy’s TTL runs out. “Propagation” is just the planet’s caches quietly expiring and refreshing on their own schedules.

So the next time a record change does not appear right away, you do not need to panic, re-save five times, or assume something is broken. You can check the authoritative server directly, confirm the new value is correct there, and then simply wait out the TTL. The delay is a feature that keeps the whole internet fast — not a bug.

Recap

• DNS translates friendly names like acy-partner.com into numeric IP addresses — it is the internet’s phone book.
• Lookups are cached at many layers (browser, OS, ISP resolver, and resolvers worldwide) so the system stays fast.
• A DNS change is saved instantly at the authoritative server, but cached copies elsewhere keep serving the old answer until they expire.
• TTL (Time To Live) is the timer that decides how long each cache holds an answer. The TTL that was in place before your change is the one that governs the wait.
• “Propagation” is cache expiry, not data spreading — which is why different people see different results during the transition.
• To make changes smooth: lower the TTL in advance, keep the old server alive during the overlap, and verify the record carefully before saving.

Once propagation makes sense, a natural next step is getting comfortable reading DNS records themselves — the different record types (A, CNAME, MX, TXT and friends) and what each one is for. Understanding those turns DNS from a black box into something you can confidently manage.