TTL, caching, and DNS propagation

You updated a DNS record and your co-worker can see the change. You cannot. An hour later you finally see it. Your manager calls this “DNS propagation” and says to wait 24–48 hours. That framing is technically wrong and operationally expensive. Understanding what TTL actually is — permission, not a command — changes how you manage DNS records in production.

What TTL means

Every DNS record carries a TTL (Time To Live) — a number in seconds. When a resolver caches an answer, it counts down from TTL to zero. At zero it discards the cached record and re-queries. The authoritative server does not push updates; caches expire and pull the new value on their own schedule.

This has two operational consequences:

1. You cannot force a cached value to disappear. Once a TTL is published and cached, you must wait for that TTL to count down everywhere.
2. “DNS propagation” is a misleading term. Nothing propagates. All that happens is that distributed caches expire one by one. There is no wave; there is no timeline. A cache that was populated 1 minute before your change will hold the old value for (TTL - 1 minute) longer.

High TTL vs low TTL

Planned migration SOP

The standard operational pattern for a planned DNS change:

1. One week before: Lower TTL to 60 seconds. Wait for the old high TTL to expire everywhere (max wait = old TTL).
2. Change day: Update the record. Bad outcome reachable immediately — max cache age is now 60 s.
3. After stabilisation: Raise TTL back to 3600 s or higher.

Skipping step 1 means old caches can serve stale data for up to the old TTL (e.g., 24 hours) after your change.

Negative caching (RFC 2308)

DNS caches do not only store positive answers. They also cache negative responses:

• NXDOMAIN (name does not exist) — cached for min(SOA.MINIMUM, SOA.TTL), typically 1–3 hours.
• NODATA (name exists but no record of that type) — same cache duration.
• SERVFAIL — cached briefly per RFC 9520: 30 seconds to 5 minutes. Short enough to not amplify an outage, long enough to prevent a tight retry loop.

Negative caching is essential for performance: without it, every query for a non-existent subdomain would hit the authoritative server every time. Without SERVFAIL caching the internet’s early typo storms and misconfigured clients could flood authoritative servers into collapse.

SOA record and zone authority

Every zone has exactly one SOA (Start of Authority) record at the apex. Its fields govern replication and negative caching:

• SERIAL: incremented on every zone change. Secondaries compare their serial to the primary’s; if lower, they pull an update.
• REFRESH: how often secondaries poll without a NOTIFY (typically 1–24 hours).
• RETRY: poll interval when REFRESH fails.
• EXPIRE: how long a secondary serves stale data when the primary is unreachable (often 1 week).
• MINIMUM: negative-cache TTL (RFC 2308). The actual negative TTL is min(SOA.MINIMUM, SOA.TTL).

Common ops mistake: decrementing SERIAL. The convention is YYYYMMDDNN format (2026051301 = 2026-05-13, change #01). Manual edits that decrement SERIAL break replication silently — secondaries skip the “older” zone.

Browser DNS cache

Browsers maintain their own DNS cache, separate from the OS stub resolver and the upstream recursive resolver. Chrome caches DNS entries for approximately 1 minute regardless of the record’s actual TTL — intentionally short enough to forget potentially malicious answers, long enough to avoid re-resolving every link on a page. Firefox follows a similar policy.

Clearing the OS-level DNS cache (sudo systemd-resolve --flush-caches on Linux, sudo killall -HUP mDNSResponder on macOS) does not clear the browser’s cache. To force a full re-resolution: restart the browser or visit chrome://net-internals/#dns and clear the host cache.

Browsers also pre-warm DNS via <link rel="dns-prefetch" href="//cdn.example.com"> — resolving names before the user clicks a link so the lookup latency is hidden.