Resolving a name from the DNS hierarchy can require several network exchanges. Repeating that entire process for every application request would add latency, increase traffic, and place unnecessary load on authoritative servers.

DNS avoids this cost through caching. Resolvers store recently learned information and reuse it for a limited time. The Time to Live, or TTL, attached to each resource record set controls when the resolver must consult the DNS source again.

Caching makes DNS fast and scalable, but it also means that a record change is not instantly visible everywhere. Different caches learn the data at different times, hold independent countdowns, and may sit at several layers between an application and an authoritative server.

Understanding those countdowns explains most reports that “DNS has not propagated yet.”

Consider a cold lookup for:

A recursive resolver may need to contact root, top-level-domain, and example.com authoritative servers before it obtains the requested address.

If 10,000 clients behind that resolver request the same popular name, repeating the hierarchy walk 10,000 times would waste work. Instead, the resolver stores the answer and reuses it while it remains fresh.

Caching provides three major benefits.

Lower latency: A cache hit can return data without waiting for authoritative queries.

Lower DNS traffic: Many client requests collapse into occasional refreshes.

Greater resilience: Fresh cached data remains usable during a temporary authoritative-server or network failure.

DNS caching is distributed. There is no single global cache and no central process that pushes every update to every resolver.

A DNS result may pass through several caching layers before reaching an application.

Application or Runtime

A browser, database driver, language runtime, or application framework may retain resolved addresses. Some use the DNS TTL, while others apply their own minimum, maximum, or fixed cache policy.

An application can also continue using an address through an already open connection after its DNS entry expires. Connection reuse and DNS caching are separate lifecycles.

Operating-System Resolver

The operating system can run a local caching service shared by applications. A request may be answered locally without sending a new packet to the configured DNS server.

Not every operating system or environment has the same cache design. Containers may share the host's resolver path, run a local forwarding process, or send queries directly to a network resolver.

Local Forwarder

A home router, company gateway, or cluster-local DNS service can cache answers while forwarding misses to another resolver.

This creates another TTL boundary. A forwarder receives the remaining TTL from upstream and counts down from that value; it does not restart the authoritative TTL.

Recursive Resolver

The recursive resolver usually holds the most significant shared cache. It stores final answers as well as information needed to navigate the hierarchy.

Thousands or millions of clients can benefit from one cached RRset. A highly popular name may therefore produce far fewer authoritative queries than application lookups.

Authoritative Server

An authoritative server publishes source data for its zones. That data is not a resolver cache entry that expires when its TTL reaches zero. The TTL tells other systems how long they may reuse the published data.

A server can combine authoritative and recursive roles, but the authoritative zone and recursive cache remain logically different data sources.

Every DNS resource record carries a TTL measured in seconds:

The TTL is 300, so a resolver can normally reuse the RRset for up to five minutes before consulting the DNS source again.

Suppose a recursive resolver receives this record at 12:00:00.

If a client asks at 12:02:00, the resolver can answer from cache with approximately:

The resolver returns the remaining TTL, not a fresh 300. A downstream forwarder that receives this response can cache it for roughly 180 more seconds.

When the entry reaches expiry, the resolver must treat it as no longer fresh and consult the source before using it normally again.

TTL Is a Maximum, Not a Minimum

A resolver is allowed to discard an entry before its TTL expires. It may restart, evict data because of memory pressure, or enforce a lower local maximum.

Consequently, a TTL of one hour means “this data may be reused for up to one hour,” not “every resolver must keep it for exactly one hour.”

The inverse is more subtle. Modern resolvers may retain expired data for exceptional serve-stale behavior, but they must attempt to refresh it before treating it as current.

For an ordinary positive answer, a recursive resolver follows this basic process:

Implementations add optimizations around this flow.

A resolver can coalesce several simultaneous misses for the same question into one upstream resolution. Without coalescing, a popular RRset expiring could cause a thundering herd of identical authoritative queries.

A resolver can also prefetch popular data shortly before expiry. It still consults the source, but refreshes early enough that clients are less likely to wait on a cold lookup.

These behaviors change when upstream traffic occurs; they do not change the record's authoritative contents.

The normal unit of caching is an RRset identified by:

For example:

forms one A RRset. Both members must have the same TTL and are cached together.

Different record types at the same name have independent cache entries:

The A RRset can expire while the AAAA and TXT RRsets remain fresh.

Using different TTLs for records inside one RRset is invalid. Otherwise, a cache could lose only part of the set and return an incomplete answer. If an authoritative source supplies inconsistent TTLs in one RRset, clients should treat all members as having the lowest supplied TTL.

Positive caching stores a response that contains the requested DNS data.

Suppose a resolver obtains:

The resolver can answer later A queries for the same name from cache until the TTL expires. It does not need to contact the root, .com, or example.com authority again for each request.

The cached data is only valid for its name and type. It does not answer:

Those are different questions.

Positive caching also applies to other record types. A resolver can cache mail exchangers, TXT data, reverse mappings, service records, aliases, and authoritative-server information according to their respective TTLs.

DNS also caches authoritative statements that requested data does not exist. This is negative caching.

Without it, repeated queries for a nonexistent name would traverse the hierarchy every time. Attack traffic, typos, and misconfigured applications could generate enormous authoritative load.

Two negative outcomes must be distinguished.

NXDOMAIN: The Name Does Not Exist

An NXDOMAIN response says that the queried name does not exist:

Because the name itself is absent, the cached conclusion can apply when clients ask for different record types at that same nonexistent name.

If an operator later creates missing.example.com, resolvers holding the earlier NXDOMAIN result can continue returning the negative answer until its negative cache lifetime ends.

NODATA: The Name Exists, but the Type Does Not

A NODATA response says that the name exists but has no RRset of the requested type.

For example:

An A query can receive a successful DNS response with an empty answer section. This is not NXDOMAIN because api.example.com exists.

NODATA is type-specific. A cached absence of A data does not imply that AAAA, TXT, or another type is absent.

Where the Negative TTL Comes From

A negative response has no requested RRset whose TTL can control caching. The authoritative server therefore includes the zone's SOA record in the authority section.

The effective negative TTL is derived from the lower of:

For example:

The resolver can reuse the negative conclusion for up to five minutes.

This is why the SOA MINIMUM field is operationally important when new names or new record types are created frequently. A long negative TTL can keep a newly added name invisible to clients that recently looked it up and cached NXDOMAIN.

NXDOMAIN and NODATA are useful authoritative responses. A resolution failure is different: the resolver could not obtain useful information about whether the data exists.

Failures can result from:

Resolvers cache these failures briefly to prevent retry storms. If thousands of clients request a name whose authorities are unreachable, immediately repeating the full failed resolution for every client would amplify the outage.

Modern DNS requirements call for resolution failures to be cached for at least one second and no longer than five minutes. Implementations can use backoff within that range when a failure persists.

Failure caching does not turn a timeout into an authoritative claim that the name is absent. It temporarily suppresses repeated work until the resolver is allowed to try again.

This can make recovery appear delayed for a short period after an outage is fixed. The resolver may still be honoring its failure cache instead of immediately recontacting the recovered server.

An alias and its target address are separate RRsets with independent TTLs:

The resolver can cache the CNAME for one hour and the target address for five minutes.

After five minutes, it can reuse the cached alias but must refresh the target's A RRset. If the target address changes, clients can learn the new address without re-fetching the CNAME.

The reverse also matters. If the domain owner changes shop.example.com to point at a different target, resolvers can continue following the old CNAME until its one-hour TTL expires even if the new target has a very low address TTL.

A chain can contain several aliases and target RRsets. Each expiration is tracked separately, so the chain's behavior cannot be summarized by looking at only the final address TTL.

Recursive resolvers do not cache only final application answers. They also cache information used to navigate DNS:

This lets a resolver start closer to the responsible zone on later queries instead of returning to the root.

Delegation data has its own TTLs. Updating an application's A record does not invalidate cached name-server information, and updating a child zone's NS records does not immediately replace a parent-side delegation already held in caches.

Glue addresses also expire independently. During a name-server migration, operators must consider:

Changing only one of these values can leave some resolvers using an old authority path while others use the new one.

Suppose an A record has a one-hour TTL and changes at 14:00.

Resolver A fetched the old address at 13:59. It can continue using that value until nearly 14:59.

Resolver B fetched the old address at 13:05. Its cache expires around 14:05, after which it can learn the new value.

Resolver C had no cached entry at 14:01, so it immediately asks the authority and receives the new value.

All three resolvers can behave correctly while returning different answers:

A device behind Resolver B might also have the older result in an operating-system or application cache. Its visible behavior depends on the remaining lifetime at every layer it uses.

This gradual convergence is often called DNS propagation, but most of it is cache expiration. The new record is not slowly copied from one global DNS server to another. Resolvers pull fresh data when their existing entries can no longer be used.

An authoritative DNS provider may need a short time to distribute a zone update across its own serving infrastructure, but that is a separate process from recursive cache expiry.

Lowering a TTL only affects responses fetched after the lower value becomes authoritative. It cannot shorten the lifetime of old data already stored elsewhere.

Suppose an address currently has:

and the operator wants a five-minute transition window. A safe rollout is:

The critical wait occurs before the address change. During that hour, every conforming cache holding the earlier one-hour answer gets a chance to expire. Any resolver that refreshes during the wait receives the same old address with the new five-minute TTL.

After the full old TTL has passed, the address can change. Remaining caches should then hold either no answer or an answer with at most five minutes left.

Once the migration is stable, the TTL can be raised again to reduce normal query load.

If the operator lowers the TTL and changes the address immediately, caches that fetched the old one-hour answer a moment earlier can still use it for nearly an hour. The new low TTL does not travel backward in time.

There is no universally correct TTL. It is an operational tradeoff between freshness and efficiency.

Lower TTLs

A lower TTL can:

It also causes:

Reducing a TTL from one hour to one minute can theoretically cause a resolver to refresh that RRset up to 60 times as often.

Higher TTLs

A higher TTL can:

It also means:

Stable records often tolerate longer TTLs than endpoints expected to move frequently. Delegation and mail-routing records are commonly kept relatively stable, while an actively managed service endpoint may use a shorter value.

Consider the Entire Dependency Chain

An address TTL is not the only timing input. CNAMEs, NS records, glue, negative responses, failure caches, application caches, and persistent connections can all affect what a client observes.

Choose TTLs based on the expected change process, authoritative capacity, failure strategy, and client behavior rather than adopting one number for every record.

A low TTL does not turn DNS into a real-time health-check or traffic-switching protocol.

For DNS-based failover, the visible recovery time can include:

Even with a 30-second TTL, a client might keep an established connection to the old address or use a runtime cache with a separate policy. Another client may refresh immediately.

DNS also does not withdraw an unhealthy member from a multi-address RRset by itself. An external control system must detect the failure and update the authoritative data.

Low TTLs can reduce one part of recovery time, but they cannot provide a strict global failover guarantee.

A TTL of zero has special meaning:

The record can be used for the transaction currently in progress but should not be cached for reuse.

TTL zero greatly increases query load and makes clients more dependent on DNS availability and latency. It also cannot invalidate an older nonzero-TTL entry already stored in a cache.

If a resolver cached the record with TTL 300 two minutes ago, changing the authoritative TTL to 0 does not remove that cached copy. The resolver can continue using it for the remaining three minutes.

TTL zero data is also excluded from serve-stale reuse because it was never eligible to be cached.

Normally, an expired RRset cannot be returned as a fresh cache hit. Some recursive resolvers support serve stale, which retains expired data for use when authoritative refresh fails.

A typical sequence is:

Serve stale trades freshness for availability. An old address may still reach a working service during a DNS outage, but it may also point to infrastructure that has been removed.

When a resolver returns stale records, it gives them a small positive response TTL rather than exposing a negative countdown. A commonly recommended value is 30 seconds, which limits rapid repeated requests while encouraging another refresh soon.

Serve-stale behavior is bounded and configurable. It does not give resolvers permission to ignore TTLs during normal operation. The source must be consulted when the TTL expires, and stale data is a fallback when authoritative refresh is unsuccessful.

Some users reach the new server while others reach the old one. Their resolvers probably cached the previous answer at different times or use different local cache layers.

A new hostname still returns NXDOMAIN. A negative answer may have been cached before the record was created.

The address TTL is low, but clients still use the old endpoint. A CNAME earlier in the chain, an application cache, or an existing connection may have a longer lifetime.

A name-server migration is inconsistent. Parent delegation, child NS data, glue, and name-server address records may have different cached lifetimes.

The authoritative server shows the new record, but a recursive resolver does not. The resolver may still have a fresh old RRset. The authority cannot push an invalidation into that cache.

A DNS failure continues briefly after the authority recovers. A resolver may be honoring a short resolution-failure cache to prevent retry storms.

Expired data appears during an authoritative outage. The resolver may be intentionally serving stale data for resilience.

These patterns are easier to reason about by identifying the cached RRset, its original TTL, when each layer fetched it, and whether any aliases or delegations add separate TTLs.

TTL is not an instruction to refresh exactly at fixed intervals. It is the maximum normal reuse time before the source must be consulted again.

A cache can discard data early. TTL does not guarantee that an entry remains stored for the full duration.

The TTL shown by a recursive response is usually the remaining value. It can be much lower than the authoritative configuration.

Changing a TTL does not update existing cache entries. Old entries keep the lifetime they received earlier.

Lowering a TTL after changing a record is too late for that change. The old TTL must be allowed to expire before the record value changes.

Different answers do not necessarily mean a DNS server is broken. Independent caches can temporarily hold different generations of valid data.

DNS propagation is mostly pull-based cache expiry. Authoritative servers do not broadcast invalidations to every recursive resolver.

NXDOMAIN and NODATA are different. One says the name does not exist; the other says the requested type is absent at an existing name.

Negative answers have cache lifetimes. Creating a previously missing record does not instantly erase cached NXDOMAIN or NODATA responses.

Members of one RRset must share a TTL. Different record types at the same name can use different TTLs.

CNAME and target records expire independently. The final address TTL does not control the entire alias chain.

A low TTL is not a complete failover strategy. Detection, publishing, application caching, and connection reuse also affect recovery.

Expired does not always mean deleted from memory. A resolver can retain data for controlled serve-stale fallback while no longer treating it as fresh.

DNS caches at applications, operating systems, forwarders, and recursive resolvers reduce latency and authoritative load. TTL sets the normal maximum reuse time, with replies showing the remaining countdown. Caches store RRsets by owner, type, and class, and all members share a TTL.

Positive caching retains data; negative caching retains authoritative NXDOMAIN or NODATA results using the lower of the SOA TTL and MINIMUM. Resolvers may also cache failures briefly to suppress retries. CNAME targets, delegations, name-server addresses, and glue each have independent lifetimes, so resolvers can temporarily return different versions.

For a migration, lower the TTL, wait through the previous value, make the change, and raise it after stabilization. Lower TTLs improve potential freshness but increase load and reliance on authoritative availability. TTL zero cannot erase older entries, and serve-stale resolvers may temporarily use expired data during failures.

DNS changes become visible when caches refresh, not when an operator saves the new record.