DNS
DNS Export

How DNS Propagation Works (and Why It Takes Time)

· 8 min read · By DNS Export team

"DNS propagation" is a misleading phrase. Nothing actually propagates. Your authoritative DNS server is updated instantly. What's really happening is that caches all around the world are expiring at different rates, and until they expire, they keep serving the old answer. Understanding this changes how you plan DNS changes.

The three layers of DNS caching

When your browser asks for an IP, the answer can come from up to four places, in order:

  1. Your browser's own cache. Chrome, Firefox, and Safari cache DNS answers for somewhere between 30 seconds and 5 minutes, regardless of TTL.
  2. Your operating system's resolver cache. Windows, macOS, and Linux all keep their own caches that honor the TTL returned by the server.
  3. Your ISP or recursive resolver's cache. Cloudflare 1.1.1.1, Google 8.8.8.8, your ISP's resolver, and corporate resolvers all cache aggressively to reduce upstream queries. This is the cache that has the biggest impact on "propagation."
  4. The authoritative DNS server. The only source of truth. When you edit a record at your DNS provider, this updates instantly.

A DNS lookup walks down this list until it finds a non-expired answer. The recursive resolver layer is shared by potentially millions of users, so the answer you get may be one a stranger triggered fifteen minutes ago.

TTL: the only knob that matters

Every DNS record carries a TTL ("time to live") — a number of seconds resolvers are allowed to cache it. When you query example.com and the resolver hands you an IP, it also hands you the remaining TTL. After that many seconds, the resolver discards the cache entry and asks the authoritative server again.

So if your A record has a TTL of 3600 (one hour), the worst case after a change is:

For a TTL of 86400 (one day), the worst case stretches to 24+ hours. This is the entire story behind "DNS propagation takes 24–48 hours" — it's actually about TTL values, not propagation.

The pre-change ritual

If you know in advance that you'll be changing a record, lower the TTL before the change. Set it to 300 (5 minutes) at least one TTL-length ahead, so that by the time you make the real change, all resolvers have learned the short TTL. Then your actual change rolls out everywhere within 5 minutes.

Sequence for a planned IP move:

  1. Today: change TTL from 3600 to 300. Don't change the IP yet.
  2. +1 hour later: every resolver has now re-fetched with the new short TTL.
  3. Whenever you want: change the IP. Resolvers re-fetch within 5 minutes.
  4. After the change settles: bump TTL back to 3600 for steady-state efficiency.

This is the single biggest tool you have for predictable DNS changes.

Why it looks like "propagation"

Because different resolvers cache different records with different remaining TTLs, the new value appears at different resolvers at different times. From your user's perspective, "the change is propagating around the world." From a DNS-internals perspective, "old caches are gradually expiring."

Geo-DNS (where your authoritative server returns different IPs based on the resolver's location) adds another layer of apparent inconsistency, but that's not propagation either — it's just different correct answers for different regions.

Checking propagation in real time

The standard way to verify a change rolled out: query several geographically distributed resolvers and confirm they all return the new answer. DNS Export's Propagation tab does this with four global resolvers in parallel (Cloudflare, Google, AdGuard, AliDNS) and flags any disagreement. If they all agree, propagation is effectively complete for the public internet — though private corporate resolvers may still be stale.

For the command line, the equivalent is:

dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +short A example.com @9.9.9.9

The browser cache curveball

Even when public resolvers all return the new value, your own browser may still serve the old IP because of its in-process DNS cache. Symptoms: every public lookup tool says the change is live, but your laptop keeps hitting the old server. Fixes:

Negative caching

One subtlety that surprises people: resolvers also cache non-existence. If a record didn't exist when a resolver checked, the resolver remembers that for a while (governed by the SOA record's minimum TTL field). So if you just created a record that didn't exist before, you may have to wait for negative caches to expire too. This is why "I just added the record, why isn't it working?" sometimes has a longer wait than you'd expect.

Practical rules of thumb

Further reading

← All articles