You move a website to a new server, change its DNS record, and confirm the new address is correct. Yet one computer still reaches the old server while another loads the new one. That usually does not mean DNS is “broken.” It means one of the caches between the user and the authoritative DNS server still has a valid older answer.

BitcoinVersus.Tech has covered the foundation from several angles, including the 2025 DNS overview, the later Domain Name System overview, and the 2024 nslookup command guide. The key idea is simple: DNS translates names into network information, but those answers are deliberately reused for a period of time instead of being rediscovered for every request.

The TTL Is a Permission to Cache

Every DNS resource record can carry a TTL, or time to live. RFC 1035 defines TTL as the interval, in seconds, during which a DNS record may be cached before the source should be consulted again. If an A record changes from one IP address to another while a resolver still has 1,200 seconds remaining on the old answer, that resolver can keep returning the old address until its timer expires.

This is why DNS changes are often described as “propagating,” although that word can be misleading. A changed record does not necessarily have to copy itself sequentially across the entire internet. More often, authoritative servers have the new answer immediately while recursive resolvers continue serving previously cached data until the relevant TTL expires.

There Can Be More Than One Cache

A lookup can encounter caching at several layers. Your browser may remember a result. Your operating system can maintain a DNS client resolver cache. Your router or local network may forward requests to another caching resolver. Your ISP, enterprise resolver, or public DNS service may also have an answer saved. The newer browser request walkthrough shows where DNS fits before the browser ever opens the web connection.

Cloudflare’s explanation of DNS servers and recursive resolvers makes the efficiency benefit clear: when a recursive resolver already has a cached answer, it can skip the full trip through root, top-level-domain, and authoritative nameservers. That saves time and reduces DNS traffic. The tradeoff is that a recently changed record can remain temporarily stale.

What FlushDNS Actually Clears

On Windows, ipconfig /flushdns clears the local DNS client resolver cache. Microsoft’s official ipconfig documentation specifically describes the command as a troubleshooting tool for discarding cached entries, including negative cache entries. BitcoinVersus.Tech’s ipconfig field guide places it in a wider workflow alongside adapter configuration and DHCP checks.

Useful Windows commands for this check are ipconfig /displaydns, ipconfig /flushdns, and nslookup example.com.

The first command lets you inspect what Windows currently remembers. The second clears that local cache. The third asks DNS for a fresh lookup path and is especially useful when paired with the newer nslookup troubleshooting guide.

But flushing your PC does not erase a stale record stored in your ISP’s recursive resolver, a corporate resolver, or another upstream cache. That distinction matters. If several devices using the same resolver all receive the same old address, the stale data may be upstream rather than on one computer.

Negative Caching Can Remember Failure Too

DNS can cache the absence of an answer as well as the presence of one. Suppose you query a hostname before it exists and receive an NXDOMAIN response. A resolver may temporarily cache that negative result. If the record is created seconds later, the hostname can still appear nonexistent to clients using the resolver that cached the earlier failure.

This is one reason “it works on my phone but not my workstation” can be a useful clue. The devices may be using different caches, different resolvers, or simply different remaining TTLs. The site’s newer DNS Basics lesson provides the beginner model; this cache behavior is what that model looks like during real troubleshooting.

The explosion of AI-bot traffic, representing over 10 billion requests per week, has opened up new challenges and opportunities for cache design. We look at some of the ways AI bot traffic differs from humans, how this impacts CDN cache, and some early ideas for how Cloudflare is…

— Cloudflare (@Cloudflare) April 2, 2026

A Better Troubleshooting Order

1. Confirm the authoritative DNS record is actually correct.
2. Use nslookup or another DNS tool to see which answer your configured resolver returns.
3. Inspect and, when appropriate, clear the local operating-system cache.
4. Try a different resolver to determine whether the stale answer is upstream.
5. Compare results from another network, such as cellular data, before changing unrelated browser or server settings.

That sequence avoids a common mistake: clearing every cache and rebooting everything before identifying which layer is actually stale. It also connects naturally to broader network troubleshooting covered in BitcoinVersus.Tech’s network configuration fundamentals.

The Big Idea

DNS caching is not an accident. It is one of the reasons the naming system can scale without forcing every lookup to start at the root. TTLs let administrators balance freshness against efficiency. When a website moves, the old address can remain visible for a while because different caches are counting down independently.

So when DNS appears “wrong,” the useful question is not merely “Did I change the record?” It is: Which resolver answered me, what did it cache, and how long is that answer still allowed to live?