How DNS Propagation Works: TTL, Caching Layers & Cache Invalidation

1. The 4 Layers of DNS Caching

DNS propagation is not an active replication protocol where servers push updates to one another; rather, it is a passive cache expiration model. An update on your authoritative nameserver takes effect at an endpoint only after that endpoint's cached copy of the previous record reaches zero in its TTL counter.

When a user navigates to a website, four distinct caching layers can store DNS records:

1. Browser Cache: Modern web browsers (Google Chrome, Firefox, Safari) maintain an internal DNS cache (typically 60 seconds) to prevent redundant system socket calls.

2. Operating System Cache: The OS resolver daemon (Windows DNS Client service, macOS mDNSResponder, Linux systemd-resolved) caches records locally for the full duration of the TTL.

3. Local Router / Gateway Cache: Home and office Wi-Fi routers act as DNS forwarders and cache responses for all devices on the local area network.

4. Recursive Resolver (ISP & Public DNS): Upstream resolvers (Comcast, AT&T, Cloudflare 1.1.1.1, Google 8.8.8.8) cache records until the authoritative TTL expires.

2. The Pre-Migration TTL Lowering Strategy

The single most effective engineering practice for seamless server migrations without downtime is the Pre-Migration TTL Lowering Strategy.

If your production A record has a standard TTL of 86,400 seconds (24 hours), recursive resolvers across the world will continue directing traffic to your old IP address for up to 24 hours after you change the record.

To prevent downtime: 48 hours prior to your planned migration, lower the TTL of your DNS records to 300 seconds (5 minutes). Wait for the old 24-hour TTL to fully expire from all global caches. Then, perform your IP switch. Global traffic will migrate to your new server in just 5 minutes.

3. Negative Caching (RFC 2308 NXDOMAIN Traps)

Many developers experience a situation where a newly created subdomain works for colleagues but displays a DNS error on their own machine. This is caused by Negative Caching (RFC 2308).

If you test a new subdomain (e.g., staging.example.com) before adding the DNS record, your resolver receives an NXDOMAIN (Non-Existent Domain) response. Under RFC 2308, the resolver caches that negative response for the duration specified by the SOA Minimum TTL (often 300 to 3600 seconds), refusing to query the server again until the negative cache expires.

4. Practical Commands to Flush DNS Caches

When testing DNS changes, flush your local operating system DNS cache to force immediate re-resolution:

# Windows: Flush DNS resolver cache
ipconfig /flushdns

# macOS: Flush mDNSResponder and directory service cache
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved): Flush and restart local stub resolver
sudo resolvectl flush-caches
# Verify flush status:
resolvectl statistics

# Query authoritative nameserver directly to verify update is live at source
dig @ns1.example.com example.com A +short