The website launched this morning. Some customers see it, you get ERR_NAME_NOT_RESOLVED, and your cousin in another city gets the site perfectly. Nobody's computer is broken — the world's phone books are simply updating at different speeds. This page explains propagation honestly and shows how to prove it in two commands.
DNS is not one phone book; it is millions of copies of the phone book, held by providers and resolvers everywhere, each refreshing on its own schedule. When a domain is registered or its records change, the new answer spreads outward copy by copy. That spreading is propagation, and during it the same name honestly resolves in one city and honestly does not exist yet in another. For the person launching the site it feels like a fault; for the visitor whose resolver is still holding the old answer — or a cached does not exist from checking too early — it feels like their PC is broken. Neither is true. Your job with this error shape is to prove propagation rather than repair it, because every tool on your PC — flushes, server changes, restarts — can only change your view, and sometimes not even that.
Propagation is the favourite excuse of lazy support desks, so verify it like a technician. Run the same lookup through several independent resolvers:
nslookup yoursite.com 1.1.1.1nslookup yoursite.com 8.8.8.8nslookup yoursite.com — your own configured serverMixed answers — some resolvers returning the address, others returning non-existent domain — are propagation caught in the act. One more confirmation costs nothing: open the site on a phone using mobile data. A different network means a different resolver, and if it loads there, your local view is simply one of the copies that has not refreshed yet.
Here is the trap nobody warns launchers about. If you (or your whole office) tried the name before it existed, resolvers cached that negative answer — the official the name does not exist — and caching rules let them keep serving it for a while after the real record appears. This is called negative caching, and it explains the cruellest version of the symptom: the site works for strangers but not for the team that has been refreshing it since dawn.
The local half of that cache is yours to clear: ipconfig /flushdns empties your PC's memory, and fully restarting the browser clears Chrome's. But your provider's resolver cache is not yours — if it is holding the negative answer, your whole connection may have to wait for its timer even after your own caches are clean. Checking through 1.1.1.1 tells you whether the world has moved on even when your provider has not.
Every DNS record carries a TTL, a time-to-live in seconds, which is simply the publisher saying: you may remember this answer for this long. Long TTLs (a day or more) make resolution fast and stable but changes slow to spread. Short TTLs (five minutes) make changes quick but cost more lookups. The record you are waiting for spreads at the speed of the old timers, not the new ones — which is why experienced admins lower the TTL a day or two before a planned move, make the change while answers expire quickly, then raise it again.
Honest expectations: most new domains and record changes become visible nearly everywhere within a few hours. The worst cases — registrar changes, nameserver moves — can take up to 24 to 48 hours for the last stubborn caches. Anyone promising you a local trick that beats those timers is selling something.
For the site owner, some causes hide behind the word propagation that are really errors, and they do not fix themselves with time:
The resolver test distinguishes these cleanly: if no major resolver anywhere returns the record after several hours, it is not propagation any more — it is a missing or misplaced record, and the fix is in the DNS panel, not in patience. If some resolvers answer, patience really is the remaining ingredient.
Watch the video for the resolver comparison done live — the same young domain asked through three different DNS servers until the pattern is undeniable.
▶️ Watch Full VideoMost changes are visible worldwide within a few hours. Full propagation of nameserver or registrar changes can take 24 to 48 hours for the last caches to expire. If no resolver anywhere finds the record after several hours, the cause is more likely a missing record than slow propagation.
No. You can clear your own PC's cache with ipconfig /flushdns and restart your browser, which removes your local copy of a stale negative answer. Your provider's resolver cache and the rest of the world's timers are outside your control, so patience is the honest remainder of the fix.
Resolvers update at different times, and if you visited the name before it existed, your resolver may be serving a cached does-not-exist answer even after the real record appeared. Testing the name through 1.1.1.1 or 8.8.8.8, or from a phone on mobile data, shows whether the world has moved on without your network.