TTL
TTL (Time to Live) specifies how long a piece of data remains valid before it must be discarded and fetched fresh. It appears in several contexts, most notably in DNS, where it controls how long resolvers may cache a record, and in web caching, where it defines how long a stored response can be reused. In every case, TTL is a countdown that governs the trade-off between freshness and efficiency.
TTL in DNS
Each DNS record carries a TTL telling resolvers how many seconds they may cache the answer. During that window, a DNS server or client reuses the cached value instead of asking again, which speeds up lookups and reduces load. The cost is propagation delay: if you change a record such as a CNAME, resolvers keep serving the old value until the TTL expires. That is why teams lower the TTL before a planned migration, so changes take effect quickly, then raise it afterwards to benefit from longer caching.
TTL in caching and beyond
The same principle governs web caching: a cached page or asset is served directly until its TTL runs out, after which the cache fetches a fresh copy. A long TTL maximises performance but risks showing stale content; a short TTL keeps data current at the cost of more frequent refreshes. TTL also appears at the network level, where it limits how many hops a packet may travel before being discarded, preventing packets from looping forever. Across all these uses, choosing the right TTL is a balancing act: it decides how quickly changes propagate versus how much you benefit from reusing stored data. Understanding TTL is essential whenever you plan a change whose effects depend on caches clearing out.
Powiązane pojęcia
Najczęstsze pytania
Why lower the TTL before changing DNS records?
A lower TTL means resolvers cache the old value for a shorter time, so a change propagates faster. Teams often reduce the TTL a day before a migration, make the change, then raise it again once everything is stable.
