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).
Planning a DNS change around TTL
The standard pattern is to lower the TTL well before a planned cutover. If your record currently has a 24-hour TTL, drop it to 300 seconds at least 24 hours in advance. After the change, monitor with a propagation checker until consensus is reached, then raise the TTL back up if you don't expect frequent changes.
TTL vs reality
Some ISP resolvers ignore short TTLs and cache aggressively for hours regardless of what you publish. This is why a small number of resolvers can lag behind the rest by hours or even days after a DNS change. There is no way to force someone else's resolver to drop its cache.
Related: NXDOMAIN · resolver · DNS caching.