Time to live (TTL) in DNS is the value, expressed in seconds, that an authoritative name server attaches to every resource record to tell resolvers and other caches how long they may keep the answer before asking again. A record with a TTL of 3600 may be served from cache for up to one hour; after that, the cached copy expires and the next query triggers a fresh lookup.
For a zone administrator, the TTL setting is the principal lever for the trade-off between caching efficiency and the speed of change. Long TTLs reduce query load and latency, while short TTLs let updates such as a new server address reach users quickly. Not to be confused with the IP packet header field of the same name, which limits how many router hops a packet may take.
How TTL controls DNS caching
When a recursive resolver receives an answer from an authoritative server, it stores the record together with its TTL and starts counting down. Every later client that asks the same question receives the cached answer with the remaining TTL, not the original value, so downstream caches such as operating system stub resolvers and browsers expire the record at the same moment.
The TTL is a 32-bit field in the record format. The DNS specifications clarify that values must be treated as unsigned and limited to 2,147,483,647 seconds, roughly 68 years, but in practice operators use values from seconds to a few days. All records in one resource record set, the records with the same name, class and type, must share the same TTL.
| TTL in seconds | Duration | Typical use |
|---|---|---|
| 0 | No caching | Rare, special cases only |
| 30 to 60 | Under one minute | Failover and traffic steering |
| 300 | 5 minutes | Records that may change at short notice |
| 3600 | 1 hour | Common default for most records |
| 86400 | 1 day | Stable records such as MX or NS |
| 172800 | 2 days | Typical for delegations in many top-level zones |
Negative caching and the SOA record
Resolvers also cache negative answers, responses stating that a name does not exist (NXDOMAIN) or that it has no record of the requested type (NODATA). The duration of this negative caching is taken from the zone’s SOA record: it is the lower of the SOA record’s own TTL and the value of its minimum field.
| Answer type | Where the TTL comes from | Practical effect |
|---|---|---|
| Positive answer | TTL of the returned record set | Controls how long the data is reused |
| NXDOMAIN | Lower of SOA TTL and SOA minimum | New names may stay invisible until expiry |
| NODATA | Lower of SOA TTL and SOA minimum | Newly added record types appear late |
| Referral | TTL of NS and glue records | Controls delegation changes |
Negative caching explains a frequent surprise: a hostname queried before it was created may keep returning NXDOMAIN for the length of the negative TTL. Keeping the SOA minimum value moderate, often 300 to 3600 seconds, limits this delay.
Time to live and DNS propagation
The popular term DNS propagation describes the period during which some users still see an old record while others already see the new one. Nothing is actively pushed; the delay is simply the time it takes for cached copies to expire according to their TTL.
The TTL that matters for a change is therefore the old TTL, the one that was in effect when caches stored the record. Lowering the TTL at the moment of a migration does not help resolvers that already hold the record with a long TTL; the reduction must be made at least one old TTL period in advance.
| Step | Action | Timing |
|---|---|---|
| 1. Lower the TTL | Reduce from 86400 to 300 | At least one day before the change |
| 2. Wait | Let caches pick up the short TTL | For the full length of the old TTL |
| 3. Change the record | Point to the new address | Planned migration window |
| 4. Verify | Query several public resolvers | During the next minutes |
| 5. Raise the TTL again | Return to a long value | After the new setup is stable |
Choosing a TTL in practice
There is no universally correct TTL. The right value balances agility, resolver load, latency and resilience, and different record types in the same zone often deserve different values.
- Short TTLs speed up changes and failover but increase query volume and expose users to more lookup latency.
- Long TTLs improve cache hit rates and keep a domain resolvable for longer if its authoritative servers become unreachable.
- Load balancing by DNS typically uses 30 to 300 seconds so that steering decisions take effect quickly.
- NS and MX records change rarely and usually justify TTLs of several hours to a day.
The resilience aspect is often overlooked. During an outage or attack on authoritative servers, records with long TTLs continue to resolve from cache, while records with very short TTLs disappear almost immediately for many users.
Limitations and common misconceptions
TTL is a maximum, not a guarantee. Caches may discard records earlier, for example under memory pressure, and some resolvers apply their own policies to the values they receive.
- Resolver caps: many resolvers impose a maximum cache time, often one day to one week, regardless of longer TTLs.
- Minimum floors: some resolvers and networks raise very short TTLs to reduce load, delaying changes.
- Serve-stale behavior: resolvers may return expired records when authoritative servers are unreachable.
- Application caches: browsers, runtimes and connection pools can hold addresses longer than the TTL.
- Delegation TTLs: name server changes at a registrar depend on the parent zone’s TTL, not the child zone’s settings.
Because of these factors, operators plan changes with a safety margin beyond the nominal TTL and keep old servers running for a while after switching records.
Stripped to the essentials
When a computer looks up a website’s address, it does not want to ask the same question every time. So it writes the answer down and reuses it for a while. Time to live is the expiry date on that note, set by whoever owns the website’s domain.
A long expiry means fewer questions and faster browsing, but if the address changes, people may keep using the old note until it expires. A short expiry means changes spread quickly, at the cost of asking more often.
Where it is applied
A university IT department is replacing its on-premises mail gateway with a cloud email service during the semester break. The MX records for the main campus domain carry a TTL of two days, which means sending servers around the world could continue delivering mail to the old gateway for up to 48 hours after any change.
Three days before the cutover, the administrators shorten the MX TTL to 600 seconds and confirm with several public resolvers that the new value is being served. On cutover morning they publish MX records pointing to the cloud service, and within roughly ten minutes incoming messages begin arriving there. The old gateway stays online for a week and forwards any late deliveries, so no messages are lost. After two quiet weeks, the team restores a TTL of one day, which suits records that rarely change.