Why DNS Changes Take Time to Propagate (and How to Speed It Up)

You changed an A record twenty minutes ago. It works from your laptop, your colleague still sees the old site, and someone on mobile data gets a mix of both. The usual explanation is "DNS is propagating, give it 24–48 hours" — which is roughly the right advice for the wrong reason.

Nothing is propagating. DNS doesn't push updates outward. The moment you save a record on your authoritative nameserver, it's live — anyone asking that server gets the new answer immediately. What you're waiting for is caches expiring, and that's a different process with different rules.

What's actually happening

A DNS lookup rarely reaches your nameserver. In between sits a chain of caches:

1. The browser's own DNS cache.
2. The operating system's resolver cache.
3. The recursive resolver — your ISP's, or a public one like 1.1.1.1 or 8.8.8.8. This is the important one.
4. Sometimes a corporate or router-level resolver in front of that.

Each of those stores the answer it got, along with a countdown. Until that countdown reaches zero, the cache serves the old answer without asking anyone. That's why the rollout looks patchy and random: every resolver started its countdown at a different moment, so they expire at different times.

This is also why your machine often sees the change first. You flushed your cache, or you're querying the authoritative server directly, or your resolver happened to have a fresh record.

TTL: the number that controls all of it

TTL (Time To Live) is a value on each DNS record, measured in seconds, that tells resolvers how long they may cache the answer. It's the only real lever you have.

TTL	Meaning	Typical use
300	5 minutes	Before a planned change
3600	1 hour	Reasonable default
14400	4 hours	Stable records
86400	24 hours	Rarely-changing records

The crucial thing about TTL is the timing of when it applies. Lowering the TTL doesn't help the change you're making right now — resolvers that already cached the old record are still counting down using the old TTL value. The new, shorter TTL only takes effect after that old cache entry expires.

Which gives the actual rule for fast DNS changes:

1. Lower the TTL first — to 300 seconds, say.
2. Wait for the old TTL to elapse. If it was 86400, that means waiting up to 24 hours.
3. Now make the real change. It will roll out within about 5 minutes.
4. Put the TTL back up once things are stable.

Plan the change a day ahead and the switch itself is nearly instant. Skip the preparation and you're at the mercy of whatever TTL was already set.

Why "24–48 hours" is mostly folklore now

That advice is a holdover. It made sense when TTLs were routinely 24 hours or more and some resolvers ignored them anyway. Today most providers default to an hour or less, and the common case resolves far faster.

Two things genuinely do take longer:

• Nameserver (NS) changes at the registry. Changing which nameservers a domain is delegated to is a different operation from changing a record — it goes through the registry, and TLD nameservers have their own TTLs, often much longer. This is the case where a day is realistic.
• Resolvers that ignore TTL. Some ISP resolvers cache more aggressively than they should. There is nothing you can do about this except wait.

Checking whether it's actually done

The useful check isn't "does it work for me" — your cache is the least representative sample you have. Better:

• Query the authoritative nameserver directly. If it returns the new value, your change is correct and everything else is cache expiry. This separates "did I make a mistake?" from "am I waiting?", which is most of the diagnostic value.
• Query from a different network — mobile data rather than office wifi.
• Compare registry nameservers against live NS records. Our WHOIS & DNS lookup shows both, which is exactly the comparison that tells you whether a delegation change has gone through. How to read a WHOIS record and your DNS settings explains what you're looking at.

Flushing your local cache helps you see the change. It does nothing for anyone else, so it's a debugging aid, not a fix.

When it's not propagation at all

Before blaming caches, rule out the things that look identical from the outside:

• A typo in the record — a trailing dot missing, or an IP transposed. Querying the authoritative server catches this in seconds.
• A CNAME conflict. A hostname with a CNAME can't have other records; some providers accept the configuration and behave unpredictably.
• Two records that disagree, like an old A record left alongside a new one. Resolvers will happily return both.
• The change was made on nameservers the domain no longer uses. Common after a provider migration, and genuinely invisible until you compare the registry's nameservers with the live ones.

That last one is worth dwelling on: if you're editing records on the wrong provider, nothing you do will ever take effect, and it looks exactly like slow propagation.

The changes you didn't make

Everything above assumes the change was yours. The same caching behaviour applies to changes you didn't authorise — and a nameserver change made by someone else looks, for the first few hours, precisely like a delegation update propagating normally.

That's the argument for having your DNS watched rather than checked. DomainChest records your domains' nameservers, addresses, mail hosts and CAA records, and raises an alert when they change — so an unexpected change reaches you as a notification rather than as a mystery outage. There's more on the DNS change monitoring page.