A website can move to a new server while one device still reaches the old address and another reaches the new one. The site itself may be healthy in both places. The difference can come from DNS caching: a resolver is reusing an answer it received earlier instead of asking the authoritative DNS service for the current record.
This behavior is part of normal DNS operation. Caching reduces repeated queries and lets resolvers answer familiar names without starting a fresh lookup each time. It also means a DNS record change does not become visible to every client at the same instant.
DNS answers can be reused
DNS maps names to several kinds of records. An A record carries an IPv4 address, an AAAA record carries an IPv6 address, and other record types serve different roles. A recursive resolver obtains records on behalf of clients and can retain eligible answers in its cache.
Each DNS resource record has a time to live, usually called TTL. The TTL places a limit on how long a cached record may be retained for ordinary reuse. A resolver that has a usable cached answer can return it without repeating the full resolution process against upstream DNS servers.
The remaining lifetime decreases while the record sits in cache. When that cached lifetime ends, the resolver can no longer treat the old copy as current merely because it is still present in memory. A later query normally requires fresh resolution.
This is different from browser caching. A browser may cache web documents, images, scripts, and other HTTP responses. DNS caching concerns name-resolution data used before a connection to a web server is made. Clearing browser files therefore does not necessarily remove every DNS answer involved in reaching a site.
TTL creates a period of mixed answers
Suppose an address record has been cached and the domain operator then changes that record at its authoritative DNS service. A resolver holding the earlier answer can continue returning it until the cached TTL expires. A resolver with no cached copy may obtain the new answer immediately.
That produces a temporary period in which clients using different resolvers can receive different addresses for the same name. There is no single global DNS cache that updates all devices together.
The effect depends on when each resolver obtained its copy. Two resolvers can hold the same old address but have different remaining TTL values because they cached it at different times. One may refresh soon while the other can legitimately reuse its answer for longer.
For a planned migration, lowering a record’s TTL shortly before changing the address does not retroactively shorten copies already cached with the previous, longer lifetime. The lower value needs time to reach resolvers through refreshed answers before it can constrain caching of the later change.
More than one cache may be involved
A device often does not perform every DNS query directly against authoritative servers. Applications can rely on operating-system resolution services, and the device commonly sends queries to a recursive resolver supplied by a home router, internet provider, organization, or configured DNS service.
Caching can exist at more than one point in that path. The exact arrangement varies by operating system, application, network, and resolver implementation.
This layered structure explains cases in which reconnecting an application changes nothing. The stale-looking answer may be held outside that application. Switching networks can appear to fix the issue because the device begins using a different recursive resolver with different cache contents.
A home router can also act as a DNS forwarder or intermediary, depending on its configuration. As a result, two devices on the same local network may share part of their resolution path, while devices on different networks may not.
A cached address is not proof of a DNS fault
Receiving an earlier address during its permitted cache lifetime does not by itself indicate a broken resolver. The resolver is doing what the TTL permits.
This matters when diagnosing a server migration. If the old destination is shut down immediately after the DNS record changes, clients with valid cached answers can still attempt to connect to that destination. Keeping the previous endpoint able to serve traffic during the expected transition can avoid turning normal caching into a visible outage.
DNS also does not guarantee that one hostname maps to one fixed address. A name can have multiple address records, and DNS-based traffic distribution can intentionally return different record sets or ordering. Seeing different addresses therefore requires context before it can be labeled stale data.
Application behavior adds another layer. Software may keep existing network connections open after DNS data changes. A connection already established to an old server does not have to move merely because a later DNS lookup would return a new address. DNS resolution and connection lifetime are separate mechanisms.
Failed lookups can be cached too
Caching is not limited to successful answers. DNS supports negative caching, which lets resolvers retain information that a requested name or record does not exist.
An NXDOMAIN response indicates that the queried domain name does not exist. DNS also has cases in which the name exists but no record of the requested type is available. Standards define how authoritative information in these negative responses supplies a lifetime for caching.
Negative caching has a practical consequence during configuration changes. If a name is queried before its new record exists, a resolver can cache the negative result. Creating the record moments later does not necessarily make that resolver query again immediately. It can continue returning the cached negative answer until its allowed lifetime ends.
That can resemble propagation trouble even though the authoritative service already contains the new record. A resolver that never cached the failed lookup may see the record sooner.
Clearing a local cache has limited reach
Many operating systems provide a way to discard locally cached DNS data, and some applications maintain resolution state of their own. Removing a local entry can force that layer to request an answer again.
It cannot force an upstream recursive resolver to discard its cache. If the next resolver in the path still holds an eligible old answer, the device can receive the same address again immediately after clearing its own state.
Changing to another recursive resolver can produce a different result, but that does not prove the first resolver is malfunctioning. The second resolver may simply have no cached copy, or it may have cached the record at a different time.
For the same reason, repeated cache clearing is not a reliable substitute for checking the authoritative record, the TTL, and the answer returned by the resolver actually in use. Those pieces distinguish a current authoritative configuration from an older answer that is still valid for cache reuse.
DNS changes are controlled by cache lifetime, not a global refresh
A DNS edit is available at the authoritative service once that service is serving the updated data, but cached copies elsewhere expire on their own schedules. The TTL attached to the earlier answers sets the main boundary for normal positive-cache reuse, while negative answers have their own caching rules.
That makes DNS changes less like pushing a new value to every device and more like allowing distributed copies to age out. During a migration, the practical design should account for those copies rather than assume that saving a DNS record instantly redirects every existing client.