TTL (Time To Live)
TTL stands for "time to live." It's a number, expressed in seconds, attached to every DNS record. It tells any recursive resolver that fetches the record how long it's allowed to keep that answer in its cache before it must ask the authoritative nameserver again.
How TTL works
When you query example.com for an A record, the authoritative nameserver returns the IP plus the TTL. Your resolver returns the answer to you and stores it for that many seconds. The next user who asks the same resolver gets the cached answer instantly: but they get the old answer until the TTL expires, even if you've already changed the record at the authoritative source.
Typical values
- 300 seconds (5 minutes): common for records you might change often (CDN configs, geo-balanced services).
- 3600 seconds (1 hour): a common default for general-purpose web records.
- 86400 seconds (24 hours): common for stable records like NS or MX.
- 172800 seconds (48 hours): typical TTL for delegations at the registrar level (NS records published by the parent zone).
Worked example: lowering TTL before a Friday cutover
You're switching from one CDN to another on Friday morning. Your apex A record currently has a TTL of 86400 (24 hours). If you change the record at 9am Friday, resolvers that cached it at 8:59am will keep returning the old IP until 8:59am Saturday. Full weekend of split traffic.
Instead, on Thursday morning at 9am, change the TTL value (without changing the IP) to 300. Wait 24 hours. By Friday 9am, every resolver that previously cached the record has refreshed, and the new copy they hold has TTL 300. Now make the IP change. Within 5 minutes, every resolver re-fetches and serves the new IP. After traffic stabilizes that evening, raise the TTL back to 3600 or 86400.
What TTL is, exactly
TTL is a maximum. Resolvers may evict records earlier under memory pressure: they almost never hold them longer than the published TTL. But the "almost never" hides one of the biggest gotchas in DNS operations: some consumer ISP resolvers (and a few corporate forwarders) cap minimum TTL at 600 or 3600 regardless of what you publish. There is no fix for this on the publisher side. It's why a small minority of resolvers will lag your change by hours even when everyone else has caught up.
TTL vs negative TTL
Records that exist are cached for the record's TTL. Records that don't exist are cached for the SOA "minimum" field (also called the negative caching TTL): typically one hour. This is why a freshly-created subdomain can NXDOMAIN at some resolvers for up to an hour after you've added it: those resolvers cached the "doesn't exist" answer earlier and haven't expired it yet.
Verify on WhereIsDNS
Run a lookup for any record and watch the per-resolver answers. If 13 of 14 return the new value and one returns the old, that resolver has a stale cache that will expire on its own. WhereIsDNS doesn't show TTL directly (DoH responses often strip it), but the divergence pattern itself tells you the cache story.
Related: NXDOMAIN · resolver · DNS caching.