DNS Caching: How It Works

Every time you visit a website, your device asks a question: "What's the IP address for this domain?" Without caching, it would ask this question fresh every single time—even when you reload the same page a second later. DNS caching is the system's way of saying "I remember the answer from last time."

But here's the thing about memory: it can be wrong. Every cached answer is a bet that the world hasn't changed since you last asked.

The Bet

Caching makes DNS fast. A fresh lookup takes 50-200 milliseconds—your request hops across the Internet to authoritative servers and back. A cached lookup takes less than a millisecond. For something that happens before every single web request, that difference is everything.

But speed comes at a cost. When you cache an answer, you're trusting that the answer is still true. Usually it is. Sometimes it isn't. And there's no good way to know which.

Four Layers of Memory

Your DNS query passes through four caches, each with its own memory:

Your browser remembers for about 60 seconds. It's the fastest cache and the shortest memory. Close the browser, and it forgets everything.

Your operating system remembers longer—minutes or hours. This memory survives browser restarts. On Windows, ipconfig /displaydns shows what your system remembers. (macOS doesn't expose the DNS cache contents directly, but you can flush it when needed.)

Your resolver (usually your ISP, or services like Cloudflare or Google) remembers on behalf of millions of users. When someone in your city looks up a popular domain, everyone benefits from that memory. This is the most impactful cache—it's why google.com resolves instantly even if you've never visited it in this browser session.

CDN edge servers add another layer for domains they manage. Not part of the standard hierarchy, but they function the same way: remember the answer, serve it fast.

Each layer checks its memory before asking the layer above. For popular domains, the answer almost always comes from cache. For obscure domains, the question travels all the way to authoritative servers—then gets remembered for next time.

TTL: How Long to Remember

Every DNS record comes with a number: Time to Live, measured in seconds. It's the authoritative server saying "you can trust this answer for this long."

A TTL of 3600 means "remember this for one hour." A TTL of 300 means "forget it in five minutes." Domain owners choose their TTL based on how stable their infrastructure is:

• Long TTLs (hours to days): Fewer DNS queries, better performance, but changes take forever to propagate
• Short TTLs (minutes): Changes take effect quickly, but you're asking the DNS system to work harder

A stable production website might use 24-hour TTLs. A site about to change hosting providers drops to 60 seconds temporarily, then raises it back up after the move completes.

The Propagation Problem

Here's what makes DNS caching genuinely strange: there's no "forget" button.

When you change a DNS record, you can't broadcast a message to every cache on the Internet saying "stop believing the old answer." You just have to wait. Every cache will keep serving the old answer until its TTL expires. If someone looked up your domain an hour ago with a 3600-second TTL, they'll keep getting the old answer for another hour—no matter what you do.

This is propagation delay. It's not a bug; it's how the system works. DNS has no way to unsay something. You just wait for everyone to stop believing the old answer.

Smart administrators prepare for changes. Planning to switch servers tomorrow? Lower your TTL to 300 seconds today. That way, when you make the change, everyone's cache expires within five minutes instead of hours.

When the Bet Pays Off

Most of the time, caching is pure upside. For stable websites, it transforms DNS from a potential bottleneck into something invisible. Millions of users can visit the same domain without overwhelming authoritative servers—resolvers serve 90% or more of requests from cache.

Without DNS caching, the Internet would be unusable. Every click would wait for a fresh lookup. DNS servers would melt under the load.

When the Bet Loses

During emergencies—DDoS attacks, server failures, urgent migrations—caching works against you. You need traffic to move now, but caches are still serving the old answer. Users keep connecting to the dead server because that's what their cache remembers.

This is why emergency failovers often bypass DNS entirely. When minutes matter, waiting for cache expiration isn't acceptable. Teams use IP-based solutions or pre-positioned infrastructure instead.

Some browsers make this worse by caching beyond the specified TTL—technically incorrect, but it happens. That's why "clear your DNS cache" is troubleshooting advice, even though most users have no idea what it means.

The Trade-Off

DNS caching embodies a fundamental tension: you can have speed or you can have freshness, but you can't fully have both.

Long TTLs give you speed at the cost of agility. Short TTLs give you agility at the cost of speed (and higher DNS load). There's no free lunch—just a dial you can turn based on what matters more right now.

For most domains most of the time, err toward longer TTLs. Your infrastructure probably isn't changing hour to hour. Let the caches do their job. When change is coming, plan ahead: lower the TTL, make the change, raise it back up.

The Internet runs on cached answers. Understanding that those answers are bets—usually right, occasionally wrong, always temporary—helps you work with the system instead of fighting it.