You've changed your nameservers or updated an A record. Your host says it's done. But your site still doesn't work, or it works from your phone but not your laptop. DNS propagation explains why, and it's not as mysterious as it sounds once you understand how the DNS caching system works.
When a browser needs to find the IP address for a domain, it queries a DNS resolver, typically provided by your internet service provider, or a public service like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The resolver checks its cache first. If the answer is already cached and hasn't expired, it returns that answer immediately without making any further queries.
If the record isn't cached, the resolver works through a chain: it asks a root nameserver which TLD server handles .com, asks that TLD server which nameserver handles your domain, then asks your authoritative nameserver for the specific record. The result is returned to the browser and cached by the resolver for the duration of the record's TTL.
This caching happens at every layer, your ISP's resolver, your router, your operating system, and sometimes the browser itself. Each layer caches independently.
Every DNS record has a TTL (Time to Live) value specified in seconds. A TTL of 3600 means resolvers can cache that record for one hour before checking again. A TTL of 86400 means 24 hours.
When you change a DNS record, the change is immediate at your authoritative nameserver. But every resolver that has already cached the old record will continue serving that old answer until its cached copy expires based on the TTL. There's no mechanism to push an update to every resolver in the world, you can only wait for their caches to expire.
This is why you see different results from different locations after a DNS change: users whose resolver cached the old record recently still see the old answer; users whose resolver hasn't cached it yet (or whose cached copy has expired) get the new answer.
Updating an A record and changing nameservers involve different parts of the DNS hierarchy. An A record change only affects your zone: resolvers that cached the old A record serve the old IP until their TTL expires. Relatively fast.
A nameserver change is different. It updates the delegation records in the parent TLD zone (the .com zone, .co.uk zone, etc.). Those records have their own TTL, typically 24 to 48 hours, set by the registry, not by you. Resolvers that have cached the old nameserver delegation will continue using the old nameservers until that delegation TTL expires, which is why nameserver changes typically take longer than simple A record changes.
"48-hour propagation" is often cited as the worst case, but in modern infrastructure, most changes are globally consistent within a few hours when TTLs are reasonable.
You can significantly reduce propagation time by lowering your TTL before making a DNS change. The process:
If you forget to lower the TTL in advance, you're stuck waiting for whatever TTL was in place when the old record was last cached. You cannot retroactively speed up propagation for records that are already cached.
The most useful browser-based tool for this is our DNS Propagation Checker. Enter your domain and select the record type (A, NS, MX, CNAME). You'll see results from DNS servers in dozens of countries, showing which have the new value and which still have the old one.
To check propagation from the command line, query a public resolver directly to bypass your local cache:
nslookup yourdomain.com 8.8.8.8
Or with dig on Mac/Linux:
dig @8.8.8.8 yourdomain.com A +short
To check what your authoritative nameserver itself is returning (confirming the change is in place at the source):
dig @ns1.hosted-server.net yourdomain.com A +short
If this returns the correct value but public resolvers haven't caught up, the change is correct, you're simply waiting for cached records to expire.
Each device and network uses a different resolver, and each resolver has its own cache state. Your home router may use your ISP's resolver, your phone on mobile data uses the mobile carrier's resolver, and a colleague in another city uses an entirely different resolver. Each one cached the old record at a different time and will check for updates at a different time.
This explains why you might see the new site on your phone but not your laptop. Flushing your local DNS cache forces a fresh lookup from your configured resolver, but if that resolver still has the old record cached, you'll get the old answer. You'd need to also switch to a public resolver that has already updated to see the new answer immediately.
No. You cannot force every resolver in the world to flush its cache. The TTL system is by design, it's what makes DNS fast and scalable globally. The only control you have is to set low TTLs before making changes, which minimises the window during which stale records are served.
What you can do immediately: flush your own machine's DNS cache, switch to a public resolver like 8.8.8.8 to test, and use our DNS Propagation Checker to see the global picture. Within a few hours of a well-prepared DNS change (with pre-lowered TTLs), propagation will be essentially complete worldwide.
Register your domain directly with HostBible and it points to your hosting automatically, no DNS configuration or propagation delays to manage.
Register a Domain