A website can move to a new server while one device still tries the old address. Another device on the same network may connect normally. That mismatch can come from DNS caching: a resolver has kept an earlier answer and is still allowed to reuse it.
DNS caching is not a single cache in one fixed place. Browsers, operating systems, local network software, and recursive DNS resolvers can all retain DNS information. The result is fewer repeated lookups, but it also means a changed record does not necessarily appear everywhere at the same instant.
What a DNS cache keeps
The Domain Name System maps names such as example.com to records used for network communication. An address record can associate a hostname with an IPv4 or IPv6 address, while other record types carry different information.
When a DNS resolver obtains a record, the answer normally includes a time to live, or TTL. The TTL is a duration expressed in seconds. It tells caching resolvers how long that record may be retained before they need a fresh answer.
If a cached record is still valid, a resolver can return it without repeating the full lookup process. This cuts repeated DNS traffic and can remove part of the lookup delay for names that are requested often.
The cache does not permanently establish the destination. It stores an answer for a limited period.
The TTL controls reuse, not an exact global switch time
Suppose a DNS record has a TTL of one hour. A resolver that cached the record 50 minutes ago may keep using it for roughly another 10 minutes. A different resolver that fetched the same record only a minute before the change can retain that older answer for much longer.
This creates a gradual transition after a record changes. Different caches acquired the previous value at different times, so their remaining lifetimes differ.
A TTL also does not guarantee that every application visibly holds an entry for exactly that duration. Software can apply its own caching behavior, and some resolver implementations impose limits or policies around cached data. The key constraint is that authoritative DNS data and cached copies are separate: changing the authoritative record does not reach into every cache and erase the previous answer.
Several cache layers can be involved
A browser may ask the operating system for name resolution, and the operating system may send a query to a recursive resolver supplied by a router, internet provider, enterprise network, or public DNS service. Some applications also perform DNS resolution through their own mechanisms.
Because more than one layer can retain information, clearing one cache does not guarantee that every upstream copy disappears. If the operating system drops its local entry but the recursive resolver still has a valid cached answer, the next query can receive the same address again.
The reverse can also happen. An upstream resolver may already have fresh data while an application or local resolver continues using an older local entry.
This layered behavior explains cases where restarting one application changes the result but restarting another does not, or where switching networks appears to alter which address a device receives.
Cached DNS and established connections are different
DNS resolution usually happens before a connection is established. Once an application has an active connection to a server, changing or expiring the DNS record does not automatically move that existing connection to a new address.
A browser can therefore continue exchanging data over a connection created earlier even after a later DNS lookup would return a different destination. Connection reuse, DNS caching, and DNS record lifetime are related parts of network behavior, but they are not the same mechanism.
This distinction matters when diagnosing a service move. A fresh DNS answer may be correct while an already-open connection still points at the previous server. Closing the relevant connection or application can change the observed behavior without altering DNS itself.
A stale address does not always mean the cache is faulty
If a cached record has not reached the end of its permitted lifetime, returning it is normal behavior. The data may be outdated relative to a recent administrative change, yet still valid according to the TTL attached to the earlier answer.
This is one reason DNS operators commonly reduce a record’s TTL before a planned migration. After older copies with the previous, longer TTL have expired, a later record change can become visible to caches within the newer, shorter caching window. Raising the TTL afterward can reduce query frequency again.
That preparation cannot retroactively shorten records that resolvers already cached. A resolver holding an older record uses the TTL it received with that record.
DNS failures can also be cached
Caching is not limited to successful address answers. DNS supports negative caching for responses indicating that requested data does not exist. This prevents resolvers from repeatedly asking authoritative servers for the same missing name or record.
That behavior can be noticeable when a new hostname is created shortly after clients queried it while it was absent. A resolver may continue returning a cached negative result until the applicable negative-cache lifetime expires.
As with positive caching, the exact observed timing depends on which resolver answered the client and what information it cached.
When changing DNS service appears to fix a connection
Switching a device from one recursive DNS service to another can produce a different result because the new resolver has a different cache state. It may already hold the updated record, or it may need to query authoritative DNS and receive the current value.
That does not establish that the original DNS service is generally defective. Its cached answer may simply have been obtained earlier and still be within its permitted lifetime.
Changing resolvers can also alter other variables, including resolver routing, filtering, encrypted DNS configuration, and local application behavior. For diagnosis, the useful question is which address each resolver returns and whether that answer is still valid under the record’s caching rules.
Cache flushing has a limited scope
Operating systems and applications often provide ways to clear local DNS state. Doing so can help when a local cache contains an entry that should no longer be used, but it cannot purge caches operated by external recursive resolvers.
After a local flush, the next lookup may therefore return exactly the same record from upstream. That is expected if the upstream copy remains valid.
For an ordinary user, waiting for cached data to expire is often the only action required after a legitimate DNS change. For someone operating a service, planning TTL values before a migration is more reliable than expecting every client cache to refresh immediately after the record changes.
DNS caching works by allowing temporary disagreement between cached copies and newly published data. The TTL bounds how long a particular cached record may be reused under normal DNS rules, while the layered resolver path determines where that copy may exist. When two devices briefly reach different addresses for the same name, checking cache timing and resolver choice is often more informative than treating the mismatch as a general internet failure.