LEARN. PRACTICE. GROW.Concept and mechanism
TTL indicates how long DNS data may be cached under applicable rules. Lowering the published TTL now does not retroactively change answers already cached with the old value. Negative answers can also be cached: a newly created name may still appear nonexistent to a resolver holding an earlier negative response. Policies may serve stale data under defined conditions, and applications can have caches too, so one number does not describe the entire operational duration.
Guided application
In a fictional cutover, authority had TTL 3600 and changed it to 60 immediately before changing the address. Some clients may still use the old answer for the validity they received. Prepare TTL changes ahead of time, measure relevant resolvers, and keep the old destination compatible during the planned transition. If rollback is needed, account for caches of both old and new addresses. Record each observation’s time and distinguish change publication from client adoption.
A resolver received an answer at 10:00 with TTL 3600. At 10:05 you lower authoritative TTL. This does not force the resolver to forget the answer at 10:06.
Common pitfalls
Promising “propagation in 60 seconds” merely by changing TTL; ignoring negative and application caches.
Related topics: NXDOMAIN, NODATA, SERVFAIL, and timeout · DNS transport and DNSSEC validation
Publication, expiration, and client use are distinct moments.
Reference: RFC 2308: negative caching · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20