DNS TTL explained

Overview

TTL stands for time to live, and on a DNS record it is the number of seconds a resolver is allowed to remember an answer before asking the authoritative server again. Every DNS answer carries a TTL, whether it is the positive A record, a NOERROR empty answer, or an NXDOMAIN. That number is the single most important value for understanding why DNS changes do not take effect instantly.

What the value means

When a resolver receives example.com A 203.0.113.7 with a TTL of 3600, it stores it for an hour. Each following lookup from a browser is answered from that cache without a new query to the authoritative server. Only after the hour the resolver asks the authoritative server again.

| TTL value | Cache duration | Typical use |

| 300 | 5 minutes | During a planned migration, changed-but-unstable records |

| 3600 | 1 hour | Routine records on an established site |

| 86400 | 24 hours | Defaults on many providers; fine for records that never change |

Lower TTL means the authoritative answer both expires faster and the change reaches browsers faster, at the cost of more queries against the DNS service. Higher TTL means fewer queries and better resilience when authoritative servers wobble. "Propagation" is simply each resolver's cache expiring at its own pace; there is no signal from the authoritative server that pushes new records around the internet.

Why a TTL number can differ from what you set

The authoritative record TTL is a ceiling, not a command. Each resolver may cache for less time, and browsers also cache their own short DNS results. That is why lowering TTL does not flush every cache instantly; it only shortens the remaining life of each old answer. Some resolvers, ISP and cloud operators routinely use the TTL they receive; others impose their own minimums. A CDN or a router that ignores TTL is rare but real, and the "still old everywhere" symptom comes straight from that.

The practical change plan

1. Before the migration: set the TTL of the record you will change (typically A, AAAA, CNAME, and also MX/NS if email moves) to 300 (or the provider's minimum).
2. Wait for the old TTL to elapse, so no resolver is holding the old 24 hour answer at the moment you flip.
3. Make the record change (the actual new IP, new provider). Then start the clock on the new TTL window.
4. After the new answer normalizes (usually minutes to a few hours), raise the TTL back to 3600 or 86400 so the site does not hammer the resolver.
5. Verify with nslookup example.com 8.8.8.8 and a public DNS checker, comparing several resolvers. If Google shows the new IP but your ISP still shows the old one, you are inside the TTL window, not misconfigured.

Common curbed

• "I changed the DNS, why is it still old?" Because the previous TTL must burn out, and the browser cache holds its own copy; clear the local cache (ipconfig /flushdns on Windows, dscacheutil -flushcache on macOS) and wait out the remainder of the TTL window before you judge the resolver pool.
• "Set it to 1 to make it instant." TTL 1 forces every resolver to re-ask per query; most providers ignore very small TTLs, and the useless churn means slightly slower lookups. Use 300 as the practical floor.
• "My host told me a fixed TTL." Some providers hard-code the TTL, so the "lower it first" play is impossible; do the change at a low-traffic time instead.

When to leave TTL alone

If email on the domain uses the same records (MX/SPF hosts), a very low TTL on those means the mailbox provider re-resolves every mail delivery, harmless but useless. For a record that never changes, 86400 is defensible. The point of the TTL tool is the migration, not a permanent setting.

The propagation article covers the resolution order and per-cache story; the record reference lists the record types that carry a TTL.