What a positive answer contains
When an application needs to reach a website, it may ask DNS for an address record associated with a domain name. A successful response containing the requested DNS data is a positive answer. For example, a response to an A-record query might contain an IPv4 address for www.example.com. The answer can also include a time to live, or TTL, for the record.
TTL is expressed in seconds. It tells a DNS cache how long it may keep and reuse that record without asking upstream again. If a resolver receives an address record with a TTL of 3,600 seconds, it can generally answer matching queries from its cache for up to an hour. TTL is a limit on cached reuse, not a promise that the record will stay in every cache for that long: a cache can discard an entry earlier.
The countdown starts when an answer is cached
Imagine that an authoritative DNS server provides an A record with a TTL of 3,600 seconds. A recursive resolver retrieves and caches it. Ten minutes later, another user asks that resolver for the same record. The resolver can return its cached answer, but the remaining TTL will be about 3,000 seconds rather than a fresh 3,600. The countdown reflects how long that cached copy can still be reused.
When the cached record expires, the resolver needs to obtain a new answer before it can serve that record from its cache again. It may then receive the same address or a changed one. An application, operating system, or local network device may have its own cache too, so the path from a DNS change to what a particular user sees can involve more than one layer.
Why a DNS change does not appear everywhere at once
Suppose you change an A record from an old server address to a new one. A resolver that has no cached copy can ask for the current answer and receive the new address. Another resolver may have fetched the old address just before your change and may continue returning it until that cached record expires. Both behaviors can occur at the same time without either resolver being broken.
Lowering the TTL at the moment you make a change does not shorten the lifetime of copies already cached with the previous TTL. If you control the record and are planning a move, you can lower its TTL in advance and allow time for older cached copies to expire before changing the address. A shorter TTL can help caches check for updates sooner, but it also means more frequent DNS lookups. It cannot force every application to reconnect or guarantee that every user sees a change at one exact moment.
Each record has its own caching lifetime
A name lookup can involve several records. For instance, www.example.com might have a CNAME pointing to another name, which in turn has an address record. The CNAME and the address record have their own TTLs. If one remains cached after the other expires, the resolver may need to refresh only the expired part of the lookup. The TTL of a single record therefore does not necessarily describe the lifetime of the entire path to a website.
It also helps to separate positive answers from negative answers. A response saying that a requested name or record does not exist can be cached under different rules. An A record’s TTL does not, by itself, determine how long a previous “not found” response will linger. This distinction matters when you add a record that did not exist before.
Using TTL as a practical planning tool
Choose a TTL by considering how often you expect to change a record and how quickly you want caches to check again. A stable record may not need frequent refreshes. For a planned migration, temporarily using a shorter TTL can reduce the window in which cached old answers are expected, provided you make the TTL change early enough. After the move is working, you can reassess whether that shorter TTL is still useful.
When troubleshooting, check both the answer and its remaining TTL from the resolver you are using. A decreasing TTL alongside an old address suggests that resolver is still serving a cached copy. If the answer stays unexpected after its TTL should have expired, check the authoritative record, the resolver being queried, and any local caching or application behavior. TTL explains when a cache should seek fresh DNS data; it does not alone tell you whether the destination server is reachable or the website is working.
