Engineering Glossary · DNS
DNS propagation — Nothing Propagates: You Are Watching Caches Expire
Half the team sees the new site and half still sees the old one, and someone has started saying the word propagation.
The short answer
DNS propagation is not a process — it is the period during which independent resolver caches around the world are still serving the answer they fetched before your change. Your authoritative nameservers were correct the second you pressed save.
Because it is cache expiry rather than distribution, it is measurable instead of mysterious. Poll a list of public resolvers for the record and count how many return the new value; that percentage, rising over time, is the only honest progress bar there is.
By the HostingFast team · Reviewed 24 August 2026
100+
Terms defined properly
2 min
Read time, end to end
Plain
English, no hand-waving
24/7
Engineers on shift
Every resolver keeps its own clock, which is why results look patchy. One visitor gets the new server, another gets the old one, and both resolvers are behaving correctly — they simply fetched their copies at different moments.
This also explains the classic office-versus-phone split. A corporate resolver holding hours of TTL will keep serving the old address long after a mobile network with a colder cache has moved on.
Polling instead of refreshing
Pick half a dozen public recursive resolvers in different networks and query each one for the record. Anything still returning the old value is a cache with time left on it, and the TTL in that answer tells you precisely how much.
Run the same loop every few minutes and you have a progress measurement rather than a feeling. It also tells you when to stop worrying: once your own authoritative servers and a majority of independent resolvers agree, the remainder is arithmetic.
Ruling out the things that are not propagation
Before blaming caches, confirm the authoritative answer is right. Query your nameservers directly, bypassing every cache, and check the record is what you meant to publish. A surprising share of propagation complaints are simply a wrong record that has propagated perfectly.
Then check the delegation. If the parent zone points at a different provider from the one you edited, nothing you do will ever appear, no matter how long you wait.
Negative caching, the part nobody plans for
Failures are cached too. If a name did not exist when a resolver asked, that non-existence is stored for a period derived from your zone's SOA record, so publishing the record two minutes later does not undo the failure for anyone who already asked.
Practically, this means creating a hostname before you announce it, rather than announcing it and then creating it. The order costs nothing and saves you a support thread about a name that works for you and not for anybody else.
Local caches you can clear, and ones you cannot
You control three caches and no more: the browser's, the operating system's stub resolver, and your own router or local recursive resolver. Clearing those gives you a clean read of what the wider internet is doing, which is useful for testing and irrelevant to your visitors.
Everyone else's timers belong to them. The only real lever is preparation — a TTL lowered in advance — and it is a lever for the next change, never for the one currently in flight.
Concepts with a progress bar attached
Where a wait is involved, the useful entry is the one that tells you how to measure it rather than how to endure it. That is what this reference tries to do.
Daily backups run on every plan and restoring a file or a database is one click in the panel, not a ticket and a queue.
- 100+ entries, measurement over reassurance
- Resolver polling explained step by step
- Wired into TTL, DNS and Nameserver
- Written by the engineers who run cutovers
Why HostingFast
Standard on every plan
Cache expiry, not distribution
Naming the mechanism correctly is what makes the wait predictable.
Propagation, quantified
Poll a spread of resolvers and you have a percentage rather than an opinion.
Non-propagation faults ruled out
Wrong records and wrong delegations look identical to a slow cache until you check.
Negative caching flagged
Why a name you fixed quickly can stay broken for other people considerably longer.
Honest about your levers
Three caches are yours; the rest are not, and no tool changes that.
Continues into its neighbours
TTL, DNS and A Record carry the same thread onward.
Quick Start
From order to online
- 1
Check the authoritative answer first
Query your own nameservers directly. If the record is wrong there, no amount of waiting will help.
- 2
Confirm the delegation matches
Make sure the parent zone names the provider whose zone you edited. A mismatch here is the fault, not the cache.
- 3
Poll a spread of public resolvers
Query the same record at several independent resolvers and count how many return the new value. Repeat on a timer.
- 4
Read the TTL in the stale answers
The remaining TTL in a resolver's reply is how long that particular cache will keep disagreeing with you.
Built In
Loaded onto every plan
- Full zone editing with per-record TTLs in the panel
- Free engineer-run migration of an existing site
- Old site kept serving traffic until the new one is verified
- Staging environments for rehearsing a release
- Daily backups with one-click restores
- LiteSpeed caching at server level on every plan
- First year of your domain free on annual orders
- Human support on shift at any hour
Frequently Asked
What people ask us most often
How do I measure propagation rather than guess at it?
Query the record at a spread of independent public resolvers and count how many return the new value. Each stale answer also carries a remaining TTL, so you know exactly how long that cache intends to keep disagreeing. Repeat the loop on a timer and you have a genuine progress measurement.
The record is right on my nameservers but wrong everywhere else. Is that normal?
Yes, for a period equal to the old TTL. It becomes abnormal if it persists well beyond that, at which point suspect a second conflicting record, a delegation pointing at a zone you are not editing, or a resolver that ignores short TTLs and applies a floor of its own.
Why does a name I just fixed still fail for other people?
Negative caching. The failed lookup was stored using a value derived from your zone's SOA record, so the absence of the record outlives your correction. Create hostnames before you publicise them and this class of problem disappears.
If I cancel, what happens to my site and files?
They stay yours. Download a full backup from the panel at any time, before or during cancellation. Domains remain registered in your name for the term you paid for and can transfer to any registrar once the standard 60-day window has passed.
Keep reading
A Record
The record most cutovers change, and how to prove which server answered.
TTL (Time To Live)
The timer that decides how long any of this lasts, and when to lower it.
How to Check DNS Propagation
Polling resolvers properly instead of refreshing a browser tab.
VPS Hosting
KVM virtual servers with root access, DDoS filtering and a flat monthly price.
Drupal Hosting
Drupal with Composer, Drush and per-site PHP control on tap.
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.
Cut over on a measured timer.
Every plan carries the things other hosts bill as extras, plus support that answers when you need it.
View VPS Hosting plans