← Hacktakes · Edition 3
Hacktakes · Edition 3 · July 6, 2026

Let's build a terrible DNS cache to see why DNS doesn't "propagate"

DNS propagation is a myth because the internet actually relies on a passive pull system of uncoordinated local caches waiting for countdown timers to expire.

By Poppy Lin

Sparked by DNSGlobe – Rust TUI to watch DNS propagate around the world · discussion

The commander still believes in the myth of a unified global charge, entirely unaware that the infantry operates strictly on local countdown timers.
“The commander still believes in the myth of a unified global charge, entirely unaware that the infantry operates strictly on local countdown timers.”

Yesterday someone on Mastodon tagged me (Poppy Lin) in a massive debate on Hacker News about a visual mapping tool called DNSGlobe, and the entire thread had immediately turned into an argument about how DNS propagates. Someone in the thread eventually linked to a post Julia Evans wrote pointing out that the entire concept of propagation is a total myth! The word propagation is ubiquitous in networking (people often talk about staring at a dashboard waiting for DNS to update!), but it creates a fundamentally broken mental model. It makes caching sound like a complex global syncing algorithm pushing data outward in a giant wave, which makes the system feel unpredictable and totally robs developers of their agency to actually debug things.

I was talking to a friend about this later, and we realized that the term propagation wrongly suggests an active push mechanism where servers broadcast their updates. In reality, the architecture depends exclusively on a completely passive, lazy pull system where clients merely request data when local timers expire. I used to be entirely convinced that I grasped the mechanics behind this, but I was completely wrong! I used to assume there was some hidden mechanism that broadcasted domain changes out to major ISPs.

If we wanted to think about how to observe this caching in action, the natural instinct for investigating a domain route might be to hypothetically use dig +trace to watch a request bounce step-by-step through the delegation path.

Imagine someone running it to see what happens:

$ dig +trace example.com
; <<>> DiG 9.18.18 <<>> +trace example.com
;; global options: +cmd
.			345517	IN	NS	a.root-servers.net.
... [a bunch of root servers] ...
example.com.		172800	IN	NS	a.iana-servers.net.
example.com.		172800	IN	NS	b.iana-servers.net.

But +trace actually bypasses your local cache entirely to talk to the authoritative servers! If we really want to see the caching in action, we just need a regular dig.

$ dig example.com
;; ANSWER SECTION:
example.com.		86400	IN	A	93.184.216.34

See that 86400? That is the TTL (Time To Live). It’s literally just a number of seconds! If I run the exact same command 10 seconds later, that number will just be 86390.

There is no global syncing. There is no propagation wave. Your local resolver (or Google's 8.8.8.8) just puts the IP address in a cache with a timestamp, and when the timer hits zero, it says "welp, time to ask again!" and fetches the new record. That's it! If you change your DNS record, you just have to wait for everyone's local timers to expire. (This is why it's a really good idea to lower your TTL to 5 minutes before you do a major migration!).

I’m seriously amazed that the entire internet functions based on billions of independent, uncoordinated countdown timers just lazily ticking away in dictionaries. Code that manages to work at a global scale without any central coordination is SO EXCITING!

← Back to Edition 3