DNS TTL And The Myth Of Instant Propagation

Nothing about DNS propagates. There is no signal that travels outward from your authoritative nameserver telling resolvers a record changed. What actually happens is that recursive resolvers cache each record for the duration of its TTL, and your change becomes visible only as those cached copies expire on their own independent schedules. "DNS propagation time" is just the time it takes for the oldest relevant cache entries to age out. The single most useful thing you can do before a planned change is lower the TTL in advance, and the catch that bites most people is that it is the old TTL, not the new one, that governs how long stale answers persist.

A resolver does not push or pull updates. When someone queries your domain, their recursive resolver asks your authoritative server, gets an answer with a TTL, and stores that answer for exactly that many seconds. Every query during that window is served from cache without touching your nameserver. The change you made is real and live at the authority the instant you save it; the rest of the internet just has not asked again yet.

TTL is a cache lifetime, not a delay

The TTL field on a record is a number of seconds. It tells any resolver that fetches the record how long it may keep serving that answer before it must ask again. An A record with TTL 300 may be cached for up to five minutes; one with TTL 86400 may be cached for up to a day.

; A record with a 1-hour TTL
mail.example.com.   3600   IN   A   192.0.2.10

; the same record with a 5-minute TTL
mail.example.com.   300    IN   A   192.0.2.10

Because every recursive resolver runs its own cache, different resolvers legitimately hold different answers at the same moment. A resolver that last queried you 50 minutes ago still has the old record for another 10 minutes under a 3600 TTL; one that queried you 30 seconds ago is fresh. Two users on different ISPs can see different results during a transition, and both are behaving correctly. There is no global state to be inconsistent about, only a scatter of independent caches at different points in their countdowns.

Why a change looks "slow"

When you update a record, the worst-case time for the last stale cache to clear is the TTL that was in effect before the change. If mail.example.com had TTL 86400 and you repoint it, a resolver that cached the old value one second before your edit can keep serving it for almost a full 24 hours. Lowering the TTL on the new record does not help those resolvers, because they will not re-query until their existing cached copy, with its old 86400 TTL, expires.

This is the detail that catches people. The TTL travels with the cached answer. The value that matters during a cutover is the value resolvers already have, set the last time they fetched the record.

Lower the TTL before, not during

The correct sequence for any planned change (an MX move, repointing a mail host, a server migration):

1. Days ahead, lower the record's TTL to something small, for example 300 seconds.
2. Wait at least the length of the old TTL. If the old TTL was 86400, wait a full day. This guarantees that every resolver holding the old long-TTL copy has expired it and re-fetched the record, now learning the short 300-second TTL.
3. Make the actual change. Now the worst-case stale window is only 300 seconds, because that is the TTL every resolver currently holds.
4. After the change has settled and you are confident, raise the TTL back to a normal value (3600 or higher) to cut query load on your nameservers.

Skipping step 2 is the usual mistake. Lowering the TTL and changing the record in the same sitting gives you no benefit, because the resolvers you care about are still sitting on the previous long-TTL answer.

Practical limits and gotchas

• Resolvers can clamp TTLs. Some apply a minimum (commonly 30 to 300 seconds), so a TTL of 10 may be honored as 60. Some apply a maximum and refuse to cache beyond roughly a day regardless of what you set. A handful of corporate and ISP resolvers run their own caching policy entirely.
• You cannot flush other people's caches. dig, resolvectl flush-caches, or ipconfig /flushdns only clear your local cache. The ISP and public resolvers in front of your users keep their copies until their TTLs expire.
• Negative answers cache too. An NXDOMAIN is cached for a duration set by the SOA record's minimum field (negative-caching TTL). If you query a record before it exists, the "does not exist" answer sticks around per the SOA minimum, so create the record before you point anything at it.

You can watch the countdown directly. The remaining TTL a resolver reports decreases on each query and resets when it re-fetches:

# query a specific resolver and watch the TTL count down
dig @8.8.8.8 mail.example.com A
# the TTL in the ANSWER section is the seconds left on that resolver's cached copy

For mail infrastructure this matters more than for a website, because email retries. A web visitor who hits a stale A record sees a moment of failure and reloads. A sending MTA that resolves a stale MX may queue and retry for hours against the wrong host, or deliver to a server you have already torn down. Lowering MX and A-record TTLs before a mail migration, and waiting out the old TTL, keeps that retry window short.

If you are asked in an interview how long a DNS change takes to "propagate," the answer that shows you understand the mechanism is: it does not propagate, resolvers cache the record for its TTL and re-fetch when that expires, so the visible delay equals the TTL that was live before the change; you control it by lowering the TTL ahead of time and waiting out the old one. Saying that, rather than quoting a folk figure like "24 to 48 hours," is the tell of someone who has actually run a cutover.