# The DNS 'propagation' myth and what actually happens
> DNS records don't 'propagate' — they expire from caches. Here's what's really going on when you wait for a record to update, and how to make changes faster.
- Canonical: https://starcomputers.in/blog/dns-propagation-myth
- Published: 2026-04-05
- Tags: dns, networking
---
## The language is misleading

"Wait 24-48 hours for propagation" is something hosting providers tell users because it's
simpler than the truth. There is no propagation. DNS is eventually consistent because of
caching.

## What actually happens

1. You update a record at your authoritative name server. That change is **instant** at
   the origin.
2. Every resolver in the world that had previously looked up that name is still holding
   the old answer, cached with the original record's TTL.
3. Each cache independently expires that answer when its TTL runs out and fetches a fresh
   copy.
4. Clients talking to a resolver that hasn't re-fetched still see the old value.

Nothing "spreads." Nothing gossips. Each resolver is an independent island.

## The only way to make changes faster

Lower the TTL **before** you make the change.

```bash
# Step 1: weeks ahead of a planned change, drop the TTL.
dig www.example.com
# ;; ANSWER SECTION:
# www.example.com.  300  IN  A  203.0.113.10

# Step 2: wait for the old high TTL to expire globally.
# Step 3: make the change. Now caches only hold it for 5 minutes.
```

If you only lower the TTL at the same time as the change, you're still bound by the old
TTL that's currently cached everywhere.

## When you've already made the change

You're stuck waiting for the old TTL to expire. Forcing a "flush" on a handful of
resolvers near you doesn't help the rest of the internet. Tell users the honest answer:
"caches expire within N hours, where N was the TTL at the time of the change."

## Takeaways

- Drop the "propagation" framing. It trains bad mental models.
- Pre-lower TTLs for any planned DNS change.
- Keep production records at a TTL you can live with during an unplanned change — 300s
  for critical records is a reasonable default.