You change a DNS record. Most users see the change immediately. Some see it an hour later. A handful are still seeing the old value 24 hours later, no matter what you do. The reason is DNS caching — layers of caches between your authoritative DNS and your users, each holding the previous answer until its TTL expires.

This post explains DNS caching at a practical level: where the caches are, what TTL actually controls, how negative caching works (and why it bites you), and the operational patterns for making DNS changes predictably.

Why DNS Has So Many Caches

Every DNS query that hit authoritative servers in the early internet would have been catastrophic at modern scale. Billions of devices doing DNS lookups for billions of names — the root servers and TLD servers couldn’t handle it.

The architectural answer: cache everywhere. Every device, every router, every resolver caches DNS responses. The vast majority of lookups never reach an authoritative server.

The layers:

Application cache — Browsers, OS apps cache DNS for the lifetime of the process.
OS cache — systemd-resolved, dnsmasq, Windows DNS Client all cache.
Local router — Your home router runs a small DNS cache.
ISP / public resolver cache — Cloudflare 1.1.1.1, Google 8.8.8.8, your ISP’s resolver. These see massive query volume and cache aggressively.
CDN edge resolvers — Anycast resolver POPs that cache for entire regions.
Authoritative servers — The source of truth.

A typical query passes through several of these layers; only a tiny fraction reach the authoritative server.

TTL: The Cache’s Expiration Date

Each DNS record has a TTL (Time To Live) — how long it can be cached.

example.com.   300   IN   A   203.0.113.5
                ^
                TTL in seconds

Common TTL values:

30-60 seconds — Aggressive; used when you need rapid changes.
300 seconds (5 min) — Reasonable default for most A/AAAA records.
3600 (1 hour) — Standard for stable records.
86400 (24 hours) — Used for records that essentially never change.
604800 (7 days) — NS records and similar very-stable entries.

When a resolver caches a record, it remembers it for the TTL. After the TTL expires, the next query refetches from authoritative.

How Caching Actually Works

Step by step when your phone queries example.com:

Phone’s app cache: miss. Forward to OS.
OS cache: miss. Forward to configured resolver.
Home router resolver: miss. Forward to ISP resolver.
ISP resolver: hit. Has the answer cached. Returns it.

Or, the first time anyone in your ISP’s customer base queries:

ISP resolver: miss.
ISP resolver queries root → TLD → authoritative.
Authoritative returns example.com 300 IN A 203.0.113.5.
ISP resolver caches for 300 seconds. Returns to phone.

For the next ~5 minutes, every customer of this ISP querying example.com gets the cached answer. After 5 minutes, the resolver fetches fresh.

Why DNS Changes “Propagate Slowly”

When you change an A record from 203.0.113.5 to 203.0.113.10:

At your authoritative DNS: instant change.
At resolvers that cached the old record: still see the old value until their cached TTL expires.
For users querying through those resolvers: see the old IP until the resolver’s cache refreshes.

Worst case: a resolver cached just-before-your-change and has a TTL of 24 hours. Users of that resolver see the old IP for nearly 24 hours.

The phrase “DNS propagation” is misleading — nothing is being pushed. Each cache just expires on its own schedule.

Pre-Change TTL Reduction

The pattern for planned DNS changes:

Days before the change: lower the TTL to 60 seconds.
Wait until the old (longer) TTL has expired everywhere. Now all caches are honoring the 60-second TTL.
Make the actual change.
Within 60 seconds, all caches refresh.
After the change settles: raise the TTL back to normal.

This is the gold-standard approach for migrations. The window of “users seeing stale data” shrinks to seconds instead of hours.

For unplanned emergencies, you don’t have this option — the old TTL is what it is.

Negative Caching

What happens when a DNS query returns “no such domain”? It’s also cached — called negative caching.

The SOA record’s “minimum” field controls how long negative responses are cached:

example.com.  IN  SOA  ns.example.com. admin.example.com. (
    2026010101  ; serial
    7200        ; refresh
    1800        ; retry
    1209600     ; expire
    300         ; minimum (negative TTL)
)

So “this domain doesn’t exist” is cached for 300 seconds. If you create the record after someone queried and got NXDOMAIN, that user might see the negative response cached for 5 minutes even though the record now exists.

This is a common subtle issue. You create a new subdomain, test it from your machine, see NXDOMAIN, refresh — still NXDOMAIN. You think the record didn’t propagate. It did; you got a cached negative response.

Mitigation: keep negative TTLs low (60-300 seconds) on the SOA.

CNAME Chains and Caching

When app.example.com is a CNAME to lb-12345.region.elb.amazonaws.com, each link in the chain has its own TTL:

app.example.com    300 IN CNAME  lb-12345.region.elb.amazonaws.com.
lb-12345.region.elb.amazonaws.com.  60 IN A  52.x.x.x

The resolver caches each level independently. When app.example.com is queried, the resolver:

Resolves the CNAME (cached for 300 seconds).
Resolves the underlying A record (cached for 60 seconds).

When the cloud provider rotates the ALB IP (often), the underlying A record’s 60-second TTL matters more than the CNAME’s 300-second TTL.

This is why hosting providers use very short TTLs for their underlying load balancer records — they need to rotate IPs frequently without breaking customers.

The “Anchor TTL” Problem

Some resolvers don’t honor the TTL exactly. They may:

Cache longer than the TTL says for performance reasons.
Cache shorter than the TTL says under memory pressure.
Apply minimum TTLs regardless of what the record says.

Public resolvers (1.1.1.1, 8.8.8.8) are well-behaved. Older ISP resolvers and some enterprise networks are less reliable. The TTL is a hint, not a contract.

Some resolvers also implement TTL clamping — clamping all TTLs to a maximum (e.g., 24 hours) or minimum (e.g., 30 seconds). The intent is operational stability; the side effect is your carefully-tuned TTL might be ignored.

Browser Caching

Browsers cache DNS too, separate from the OS:

Chrome: ~60 seconds in older versions; configurable via flags.
Firefox: Similar.
Safari: OS DNS cache; no separate browser cache.

A browser that’s already cached the DNS for example.com won’t re-query, even if you changed the record. Restart the browser or wait for the cache to expire.

For testing during DNS changes:

Chrome: chrome://net-internals/#dns → Clear host cache.
Firefox: Restart or use a private window.
Command line: dig queries fresh; doesn’t use browser cache.

How to Test What DNS Resolvers See

Different tools query different layers:

# Query your local resolver (uses OS cache)
dig example.com

# Bypass local cache, query a specific resolver directly
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# See the TTL on the cached response
dig example.com  # TTL counts down on subsequent queries until cache expires

# Query authoritative directly (no caches)
dig @ns1.example.com example.com

For checking “has my change propagated everywhere,” query several major public resolvers from different regions:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
dig @9.9.9.9 example.com
dig @208.67.222.222 example.com  # OpenDNS

Each should return the new value after the relevant cache has expired.

Caching for Internal Names

Internal/corporate DNS often has different caching considerations:

Short TTLs for service discovery (1-30 seconds) so containers and pods can shift IPs fast.
Internal-only resolvers that cache aggressively for performance.
Split-horizon DNS where the same name returns different IPs internally vs externally.

For Kubernetes specifically, CoreDNS caches with defaults that work for most workloads (~30 seconds for most records). Aggressive scaling sometimes requires tuning.

Practical Lessons

A few rules from production DNS work:

Pre-lower TTLs before any change

The night before a migration, lower TTLs to 60 seconds. After migration settles, raise back.

Don’t depend on instant DNS changes

Build your application so that “DNS change” isn’t on the critical path of fast operations. Use other mechanisms (load balancer pool changes, health checks) for fast switching.

Keep negative TTLs low

A long negative TTL caches “this doesn’t exist” too long. 60-300 seconds is reasonable.

Cache externally too if you can

If your application is doing many DNS lookups per second for the same names, cache results in your application layer. Don’t hit the resolver for every query.

Monitor with health checks, not DNS

DNS is too slow for “is service X up” decisions. Use HTTP health checks against the underlying IPs.

DNS Caching and Geolocation

A side note relevant to IP intelligence: DNS resolvers see massive query patterns. Cloudflare’s 1.1.1.1 alone serves ~50 million queries per second globally. This aggregate data is what powers things like Cloudflare Radar and informs operational dashboards across the industry.

For per-IP intelligence — country, city, ASN — see the Ip2Geo API. The IP-side analog of DNS caching: also cache per-IP results in your application, since an IP’s geolocation rarely changes in minutes.

TL;DR

DNS is cached everywhere — app, OS, router, resolver, edge POP, all the way down.
TTL controls cache duration. Lower TTL = faster propagation = more queries to authoritative.
Pre-lower TTL before planned changes. Raise back after.
Negative caching caches NXDOMAIN responses; controlled by SOA minimum.
CNAME chains cache each link independently.
Resolvers may not honor TTL exactly. Treat it as a hint.
For testing, query multiple public resolvers directly with dig.
Don’t depend on DNS for fast operational changes. Use it for stable addressing.

DNS caching is the reason the internet’s name system scales. It’s also the reason your DNS changes never feel instant. Understanding the cache layers, the TTL mechanics, and the operational patterns for safe changes is essential for any infrastructure work. For DNS basics, see how DNS lookup works; for the record types you’ll be working with, DNS record types reference; for the encrypted layer, DNS over HTTPS vs TLS.

DNS Caching Explained: TTL, Negative Caching, and Why DNS Changes Take Time