DNS answers are often reused instead of being requested from authoritative servers for every connection. A resolver can keep a record in its cache for a limited period, then answer later queries from that cached copy.
The record’s time to live, commonly written as TTL, sets that cache lifetime in seconds. A value of 300 permits caching for up to five minutes, while 3600 permits up to one hour. Once the remaining lifetime reaches zero, the cached record is no longer considered fresh and the resolver normally needs a new answer before serving it again.
This timer creates a practical trade-off. Longer values reduce repeated DNS work and can lower query traffic. Shorter values allow record changes to become eligible for refresh sooner.
TTL starts counting down when a record is cached
A TTL is not a scheduled switch time. It is a lifetime attached to DNS data.
Suppose an authoritative server returns an A record with a TTL of 3600 seconds. A recursive resolver that caches the answer begins reducing that lifetime. If another client asks for the same record 20 minutes later, the resolver can return its cached answer with roughly 40 minutes remaining.
Different resolvers can therefore hold the same record with different remaining lifetimes. One may have cached it seconds ago while another may be close to expiration. A DNS change does not cause all existing caches to discard their older data at the same instant.
This is the source of the gradual transition often seen after changing an address or other DNS record.
Changing a record does not rewrite existing caches
Editing an authoritative DNS record changes the answer available to new queries that reach the authoritative service. It does not normally send an invalidation message to every recursive resolver that already holds the previous answer.
A resolver with an unexpired cached copy can continue serving that copy until its cache policy permits a refresh. A resolver with no cached copy can receive the new data immediately. Two users can consequently reach different destinations during a transition even when both are making valid DNS queries.
The effect is often described as DNS propagation, but cache expiration is a major part of what users observe. The authoritative data may already be updated while recursive caches still contain earlier answers.
Lowering TTL shortly before a migration can reduce stale time
A common migration pattern is to reduce the TTL before changing a record. The timing matters.
If a record currently has a TTL of 86400 seconds and its value is changed at the same moment its TTL is reduced to 300, resolvers that cached the earlier answer under the one-day lifetime can still retain it. The new five-minute value does not retroactively shorten those existing cache entries.
Reducing the TTL far enough in advance gives older long-lived entries time to expire. Fresh queries can then cache the record with the shorter lifetime. When the actual address change occurs later, those shorter cache windows can make the transition faster for many resolvers.
After the migration settles, the TTL can be raised again if frequent refreshes provide little benefit.
Short TTL values increase query frequency
A shorter cache lifetime is not free. Records expire more often, so recursive resolvers must refresh them more frequently. That can increase traffic toward authoritative DNS infrastructure and create more opportunities for lookup latency to appear after cache expiration.
Caching also absorbs repeated requests for popular names. A resolver serving thousands of clients may answer many queries from one cached record rather than forwarding each request through the DNS hierarchy.
For stable records, a longer TTL can make efficient use of that behavior. For records expected to change during controlled operations, a temporarily shorter value can provide more flexibility.
The useful value depends on the service, expected change rate, DNS provider, traffic pattern, and operational requirements rather than on one universal number.
Resolver policies can affect observed cache lifetime
TTL values are instructions carried in DNS responses, but real resolver behavior can add boundaries. Some recursive services apply minimum or maximum cache periods, and software layers above DNS can maintain their own caches.
Operating systems, browsers, applications, proxies, and local network components may each influence how quickly a client performs another lookup. A DNS TTL therefore does not guarantee that every application will request fresh data at the exact second the authoritative value expires from one particular resolver.
Negative answers can also be cached. If a requested name or record does not exist, DNS has mechanisms for caching that result for a period. Creating the missing record moments later does not necessarily make every previously cached negative response disappear immediately.
These layers explain cases where a change appears current through one resolver but stale from a specific device or application.
TTL applies to cached DNS data, not active connections
DNS determines addressing information used to start connections, but a TTL is not a lifetime for an established TCP, QUIC, or other application session.
If a client resolves a service, opens a connection, and the DNS record later expires or changes, the existing connection does not close merely because the DNS timer reached zero. The application may keep using that connection according to its own protocol and timeout rules.
A later connection can trigger another lookup and receive a different address. This distinction matters during migrations because DNS controls future resolution behavior rather than directly moving traffic that is already flowing through established sessions.
Cache lifetime shapes the pace of DNS changes
TTL provides a simple control with broad operational effects. It tells caches how long DNS data may be reused before it needs fresh resolution, balancing lower query volume against faster eligibility for updated records.
A record change can be available at its authoritative source while older cached answers remain valid elsewhere. Lower values can narrow that window when applied early enough, while longer values suit data that changes infrequently and benefits from efficient caching.
Treating TTL as a cache lifetime rather than a global update countdown gives a more accurate picture of DNS transitions. Each cache has its own timer, and the visible change across clients follows those independent expiration points.