A domain can point to a new server and still resolve to its previous address for some people. The change may already be present on the authoritative DNS server, yet a resolver that received the older record earlier can continue returning that cached answer until its permitted lifetime runs out.
That lifetime is expressed through DNS time to live, usually shortened to TTL. It gives caching resolvers a limit for retaining record data. TTL makes repeated lookups less dependent on contacting authoritative servers, but it also means a DNS change is not necessarily visible to every resolver at the same moment.
DNS answers can pass through a cache
Applications usually do not query a domain’s authoritative name server directly. A device sends a DNS query through a resolver, often supplied by a network provider, an organization, or a public DNS service. That recursive resolver can contact other DNS servers as needed and return the resulting answer.
When the resolver caches an answer, later clients asking for the same record can receive the stored result. The resolver does not need to repeat the complete resolution process while the cached data remains valid.
Caching can exist at more than one layer. Operating systems and applications may keep DNS results locally, and some network components can also participate in name resolution. Exact cache behavior varies by implementation, so clearing one local cache does not force an upstream recursive resolver to discard its own stored data.
This layered behavior is one reason two devices can receive different answers even when they request the same name within seconds of each other. They may use different recursive resolvers, or one path may already have cached an older record while another performs a fresh lookup.
TTL limits reuse of a DNS record
DNS resource records carry TTL values measured in seconds. A caching resolver uses that value to determine how long the record may remain in its cache.
The remaining lifetime decreases as the cached record ages. If a resolver receives an address record with a TTL of 3600 seconds, for example, a query near the end of that period can be answered with a much smaller remaining TTL. The original one-hour value is not restarted each time a client asks the caching resolver for the record.
Once cached data expires, the resolver cannot continue treating that entry as a normal valid cached answer. A subsequent query can trigger fresh resolution and obtain the current record from the relevant DNS hierarchy.
TTL therefore controls cache lifetime rather than a synchronized update timer. Authoritative servers do not send a message to every recursive resolver when a record changes. Each resolver refreshes data according to the state of its own cache and the queries it receives.
A DNS change can coexist with an older cached answer
Suppose an address record has a TTL of four hours. A recursive resolver queries it at 10:00 and stores the result. If the authoritative record changes at 11:00, that resolver can still have roughly three hours of valid cache lifetime for the old value.
Another resolver that had no cached copy at 11:05 can query the authoritative data and receive the new value. Both results can therefore appear at the same time without either resolver ignoring DNS rules.
This effect is often described loosely as DNS propagation. The term can suggest that a new record travels outward through the internet in a single spreading process. Ordinary recursive caching is more distributed than that. Cached entries expire independently, and resolvers refresh them when resolution activity requires it.
A lower TTL before a planned change can shorten the period during which previously cached data remains reusable. That adjustment has to reach resolvers before the change itself. Lowering the TTL at the same moment as changing the record does not retroactively shorten an older cache entry that was obtained under the previous TTL.
Different record types have separate cache entries
A domain name can have several kinds of DNS records, and their cache state is not one shared object. Address records, aliases, mail routing records, and other resource-record sets can carry different TTL values.
Changing an IPv4 address record does not imply that an IPv6 address record or a mail record has the same lifetime. An alias can also introduce another lookup whose target has its own cached data and TTL. The visible result can depend on more than one record in the resolution chain.
This matters when a service move changes several DNS elements. A resolver may have fresh data for one part of the chain and older but still valid data for another. Looking only at the TTL shown on the final address can miss a cached alias or delegation-related record that also affects resolution.
The practical unit to inspect is the specific DNS data involved in the lookup, not just the domain name as a whole.
Missing names can also be cached
DNS caching is not limited to successful answers. Resolvers can cache negative responses that indicate a requested name or record does not exist.
Negative caching prevents repeated queries for the same absent data from constantly reaching authoritative servers. Its cache lifetime is derived from information in the zone’s SOA record under DNS rules, rather than from a nonexistent answer record.
This produces a counterintuitive result during configuration work. If a resolver asks for a name before that name exists, it can cache the negative answer. Creating the record immediately afterward does not necessarily make it visible through that resolver at once. The cached negative result can remain usable until its allowed lifetime expires.
Modern DNS specifications also define caching behavior for certain resolution failures. These rules reduce repeated traffic during failure conditions, but they also mean a transient DNS problem can have effects that persist briefly after the underlying condition has cleared.
Clearing a device cache has a limited reach
Flushing a local DNS cache can remove answers held by that device or a particular application. It does not invalidate records already cached by a recursive resolver elsewhere.
If the upstream resolver still has a valid older answer, the next local query can simply retrieve that same answer again. Switching to another recursive resolver can produce a different result if that resolver has different cache state, but this is not proof that one service is globally current and the other is globally stale. Their histories can differ for each queried record.
The same distinction applies to restarting a router or browser. Such actions can affect local state, but they do not create a global DNS refresh.
For diagnosing a recent record change, the useful questions are which resolver returned the answer, which record type was requested, what TTL remains on the response, and whether an alias or other DNS data sits in the path.
TTL is a cache boundary, not an update guarantee
A short TTL can make cached records eligible for refresh sooner, but it does not guarantee that every client observes a change after exactly that interval. Local caches, application behavior, resolver policies, network interruptions, and multi-record resolution paths can affect what a particular device sees.
A long TTL reduces how often unchanged data needs fresh resolution, while also allowing an old value to remain valid for longer after an authoritative change. A short TTL narrows that cache window at the cost of more frequent resolution activity.
The central point is that DNS caching is distributed. Each cache has data obtained at a particular time and a remaining lifetime attached to it. A record change becomes visible as those independent cache states expire and fresh queries obtain the current authoritative data. That model is more accurate than treating DNS as a single directory that updates everywhere at once.