TTL and Caching: Why a Change Takes Time

Every answer carries a lifetime, and resolvers keep the old one until it runs out.

Every DNS record carries a TTL, a time to live in seconds, and any resolver that caches the record may keep using it for that long without asking again. When you change a record, each resolver that cached the old value continues to give it out until its own copy expires, so a change reaches users gradually, at times that depend on when each resolver last asked.

Picture api.example.com with a TTL of 3600 seconds, an hour. At noon its address is changed. Two resolvers had cached the old address at different times.

A record changed at noon, and two resolvers that cached it at different times

11:20
Resolver A caches the old address
Its copy is valid for one hour, until 12:20.
11:50
Resolver B caches the old address
Its copy is valid until 12:50.
12:00
The record is changed
The authoritative servers now give the new address.
12:20
Resolver A's copy expires
It asks again and its users move to the new address.
12:50
Resolver B's copy expires
Its users move too, 50 minutes after the change.

The worst case is one full TTL after the change: a resolver that cached the record a second before the change keeps the old value for the whole hour. To know when one resolver will switch, take the TTL and subtract how long ago it cached the record.

The TTL counts down in the cache. A resolver that cached a 3600-second record 20 minutes ago returns it with a TTL of 2400, so a client can see how much life the answer has left.

Choosing a TTL is a trade. A long TTL, such as a day, means fewer queries and faster answers from cache, and slow changes. A short TTL, such as 60 seconds, means changes spread quickly and more queries reach the authoritative servers. Records that rarely change, such as NS records, use long TTLs; records that may need to move quickly, such as the address behind a load balancer, use short ones.

Absence is cached too. A lookup for a name that does not exist returns NXDOMAIN, and resolvers cache that answer for a time set in the zone's SOA record. Creating a record soon after someone looked it up can leave them seeing "does not exist" for a while.

Some resolvers and applications do not honour the TTL exactly, keeping answers longer, so treat the TTL as the shortest delay you can expect, not a promise.

← → move through sections and cards