Changed Your DNS? Why It's Not Working Yet (and How to Check)

The short answer: DNS changes aren't instant because the internet caches DNS answers at four layers — your browser, your operating system, your ISP's resolver, and the TTL value on the record itself. Until each cached copy expires, different people see different answers, which is why your site looks updated to you but broken to your client. Typical propagation takes minutes to 48 hours. Here's what's actually happening, how to check whether your change is live, and the mistakes that make the wait longer than it needs to be.

The 4 layers between your edit and the world

When you change a DNS record at your provider, you've only updated the authoritative copy. Everyone else learns about it through caches, and each cache has its own expiry rules:

1. Your browser's DNS cache. Browsers keep their own short-lived DNS cache (Chrome's lasts about 60 seconds by default) so repeat visits don't re-resolve. This is why a change can look live in one browser and stale in another on the same machine.

2. Your operating system's cache. Windows, macOS, and Linux all cache DNS responses at the OS level, typically honoring the record's TTL but sometimes imposing their own minimums. This cache is shared across all your browsers and apps.

3. Your ISP or resolver's cache. This is the big one. Your ISP's recursive resolver — or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1 — caches your record for the full TTL and serves that cached answer to thousands of users. A resolver in another country may refresh at a completely different time, which is why "it works for me but not for them" is the classic propagation complaint.

4. The TTL on the record itself. Every DNS record carries a Time-To-Live value (in seconds) that tells resolvers how long they're allowed to cache it. A TTL of 3600 means "trust this answer for one hour." Until that hour passes, no resolver will even ask your authoritative server for the new value. TTL is the single number that controls your propagation speed — more on that below.

If you're fuzzy on what these records actually are, our DNS records explained guide covers each type and what it does. The short version for this article: the record type doesn't change propagation mechanics — TTL and caching do.

How long DNS propagation actually takes

"It depends on the TTL" is the honest answer. Here's what typical values mean in practice:

The worst case people quote — 48 hours — comes from stacking: a 24-hour TTL on the old record plus slow resolvers that don't refresh promptly, plus your own local caches. In practice, with a sensible TTL, most of the world sees the change within a few hours, and stragglers clear within a day.

The pro move: lower your TTL before you migrate

This is the step almost everyone learns the hard way. If you know a DNS change is coming — a host migration, a nameserver switch, moving email providers — lower the TTL on the affected records to 300 seconds at least 48 hours beforehand. That gives the old, long TTL time to expire everywhere while the old values are still correct. Then make your change: propagation now takes minutes instead of hours. Once everything is stable, raise the TTL back up (longer TTLs mean faster resolution for your visitors and less load on your nameservers).

Changing the TTL at the same moment as the record itself does nothing — resolvers already holding the old value with the old TTL will keep serving it until that old TTL expires. The 48-hour lead time is the whole trick.

How to check whether your DNS change is actually live

Don't test from just your own browser — your local caches lie to you in both directions. Check from the outside:

1. Query from multiple locations. A DNS lookup tool that checks your records through different resolvers (FrostRank's checks via Cloudflare and Google, for example) shows you whether the new values are visible beyond your own network. If multiple independent resolvers return the new record, your change is live — any staleness you still see is local caching, not a propagation problem.

2. Ask the authoritative server directly. Bypass all caches by querying your authoritative nameserver itself with dig or nslookup: dig @ns1.yourprovider.com yourdomain.com A. If the authoritative answer is correct, your edit went through — everything else is just waiting on caches. If it's wrong here, the problem isn't propagation at all: you edited the wrong zone, the wrong record, or the change didn't save.

3. Check Google's cached copy. Google Public DNS lets you inspect (and, if needed, flush) what its resolvers currently hold for your domain via the Google Public DNS cache tool. Useful when a big chunk of your audience uses 8.8.8.8 and you want to confirm what they're getting.

DNS propagation checker tools: what to look for

A useful propagation checker queries your domain from many resolver locations worldwide and shows the answers side by side, so you can see at a glance which regions have the new values and which are still cached. Look for: multiple geographic locations (not just one resolver), the TTL it's observing, support for the record type you changed (A, CNAME, MX, TXT — not just A), and a clear timestamp of when each check ran. Free tools cover this completely — it's a simple query repeated from many places, not something worth paying for.

Troubleshooting: symptom → cause → fix

4 mistakes that make propagation slower than it needs to be

1. Not lowering the TTL in advance. Covered above — the 48-hour lead time is the highest-leverage move in DNS migrations, and skipping it is why "simple" moves turn into two-day sagas.

2. Changing nameservers and records in one step. Move in two phases: first point the new nameservers at identical records, wait for the NS change to settle, then edit the records. Combining both means debugging two moving parts at once.

3. Testing only from your own network. Your browser, OS, and ISP caches make your machine the least reliable propagation monitor you own. Always verify from external resolvers before declaring victory — or defeat.

4. Editing the wrong DNS zone. If your domain's nameservers point at Cloudflare but you edited records at your registrar (or vice versa), your authoritative answers never change no matter how long you wait. Check where your NS records actually point first — Cloudflare's DNS docs walk through the delegation chain clearly.

Frequently asked questions

How long does DNS propagation take?

Minutes to 48 hours, controlled by the TTL on your records. With a 300-second TTL set in advance, most resolvers pick up the change within minutes; with a 24-hour TTL, expect up to a full day of mixed old/new answers worldwide.

What's the best DNS propagation checker?

One that queries from many locations and shows answers side by side with timestamps — that geographic spread is the whole point, since propagation is never uniform. FrostRank's free DNS lookup tool checks records through multiple major resolvers; pair it with a query against your authoritative nameserver directly to separate "my edit is wrong" from "caches haven't expired yet."

Why do propagation checkers show different results per location?

Because each resolver cached your record at a different time under the old TTL. A resolver that cached it 23 hours into a 24-hour TTL serves the old answer for one more hour; one that cached it 5 minutes ago serves it for nearly the full TTL. The differences converge as each cache expires — it's normal, not a bug.

Can I speed up propagation after I've already made the change?

Mostly no — you can't force other people's resolvers to drop cached records early. What you can do: clear your own local caches for testing, ask affected users to do the same, and use Google's public-DNS cache tool for the slice of traffic on 8.8.8.8. The real speed-up (lowering TTL 48h ahead) only works before the change.

Is it a propagation issue or did I break something?

Query your authoritative nameserver directly (dig @your-nameserver yourdomain.com). Correct answer there = propagation, wait it out. Wrong or missing answer there = your edit itself is the problem — fix the record, don't wait. If browsers show a DNS error instead of your site at all, see our DNS_PROBE_FINISHED_NXDOMAIN explainer to tell a propagation delay apart from a genuine resolution failure.

Do I need to flush my DNS cache?

Only for your own testing — flushing local cache (browser or OS) lets you see the new values sooner, but it changes nothing for anyone else on the internet. It's a diagnostic step, not a fix for propagation.