You type a website address, press Enter, and expect the page to appear immediately. Behind that simple click, however, your device has to figure out where the website actually lives on the internet. That is where the Domain Name System, better known as DNS, enters the picture.

DNS works a little like the internet’s contact list. Instead of forcing you to remember a numerical IP address for every website, it translates human-friendly domain names into addresses computers can use. To make this process faster, your computer and other parts of the network may temporarily save previous DNS results in a DNS cache.

Most of the time, caching is wonderfully boring. It quietly speeds things up and reduces unnecessary DNS lookups. Occasionally, though, the cache remembers an address that is no longer correct. Then the internet starts behaving like a GPS that insists a restaurant is still located in a building demolished three years ago.

This guide explains what DNS cache is, how it works, why cached DNS records sometimes become stale, and how to update or flush DNS cache on Windows, macOS, Linux, browsers, routers, and public DNS resolvers.

What Is a DNS Cache?

A DNS cache is temporary storage containing information from previous DNS lookups. When your device successfully resolves a domain name, it may remember the result so that the next request can be completed more quickly.

For example, suppose you visit example.com. Your device needs to determine the IP address associated with that domain. Rather than performing the full lookup process every single time you revisit the site, a DNS resolver may store the answer temporarily.

The next time the same domain is requested, the resolver can often answer from its cache instead of starting another lookup from scratch.

Where Can DNS Information Be Cached?

DNS caching does not happen in only one place. A lookup may pass through several layers, and more than one of them can remember the result.

• Application or browser cache: Some applications and browsers may maintain their own DNS-related state.
• Operating system cache: Windows, macOS, and many Linux systems can temporarily store resolved DNS records.
• Router or local network resolver: Some routers and network services cache or forward DNS queries.
• ISP or public recursive resolver: Your internet provider or a service such as Google Public DNS or Cloudflare 1.1.1.1 may cache answers.
• Other recursive infrastructure: Corporate networks and managed environments may add additional caching layers.

This layered structure explains why clearing the DNS cache on your laptop does not always fix a problem immediately. You may have emptied one cupboard while the stale can of beans is still sitting in another.

How DNS Caching Works

When you request a domain that is not already cached, your configured DNS resolver attempts to find the appropriate answer. Depending on what it already knows, the process can involve information obtained through the DNS hierarchy and the domain’s authoritative DNS servers.

Once the resolver receives an answer, it can temporarily store that result. Future requests for the same record may then be served from the cache.

This approach provides several benefits:

• Faster repeat DNS lookups
• Lower latency when opening frequently visited websites
• Less traffic sent to upstream DNS infrastructure
• Reduced workload for authoritative DNS servers

In other words, DNS caching prevents the internet from repeatedly asking the same question five seconds after receiving the answer. Even computers appreciate not being trapped in that conversation.

What Is DNS TTL?

DNS records generally include a value called Time to Live, or TTL. The TTL tells caching resolvers how long a record may normally remain cached before it should be refreshed.

TTL values are commonly expressed in seconds. A record with a TTL of 3,600 seconds, for example, can generally remain cached for up to one hour before the resolver needs a fresh answer.

TTL creates a trade-off:

• Longer TTL: More cache hits and fewer repeated DNS queries, but DNS changes may take longer to become visible to users with old cached records.
• Shorter TTL: Changes can be picked up sooner after existing cache entries expire, but resolvers must perform lookups more frequently.

This is why DNS updates do not necessarily appear everywhere at exactly the same moment. Different resolvers may have cached the old record at different times, so their remaining TTL values can also differ.

What About Negative DNS Caching?

DNS can also cache unsuccessful results. This is commonly called negative caching.

Suppose a resolver asks for a hostname that does not exist and receives an appropriate negative response. That result may be cached temporarily so the resolver does not repeatedly ask the same unsuccessful question.

This is useful for efficiency, but it can become confusing during DNS changes. Imagine creating a new hostname shortly after users have already tried to access it. Some resolvers may temporarily remember that the hostname did not exist.

That means simply lowering the TTL on the newly created record cannot retroactively change a negative response that is already cached elsewhere. The old cached result may need to expire, or the relevant resolver cache may need to be purged when such a feature is available.

Why Would You Need to Update or Flush the DNS Cache?

Normally, cached records expire automatically and require no intervention. Flushing the DNS cache is primarily a troubleshooting technique.

A Website Recently Changed Servers

If a domain was moved to a new web server, some users may still be directed to the old IP address until the previous cached record expires.

A DNS Record Was Recently Modified

Changes to A, AAAA, CNAME, or other DNS records may not appear instantly to every resolver. An old local cache entry can make your device continue using the previous answer.

A Website Works on One Device but Not Another

If a site opens correctly on your phone but fails on your computer while both are using the same network, cached information on the computer becomes one possible suspect.

You Previously Received a DNS Error

A failed lookup may have resulted in temporary negative caching. After the DNS configuration has been corrected, a cache flush may help your device request a fresh answer.

You Are Troubleshooting Name Resolution

System administrators and developers often clear caches during testing so they can compare current DNS responses rather than accidentally relying on an older local result.

How to Check the DNS Cache on Windows

Windows provides a straightforward command for displaying entries in the local DNS client resolver cache.

Open Command Prompt and run the command. The output may include cached record names, record types, and remaining TTL information.

The list can be lengthy, so do not panic if it looks like your computer has been secretly studying for a DNS certification exam.

How to Flush DNS Cache on Windows

To clear the Windows DNS resolver cache, open Command Prompt and run:

Windows should display a confirmation after successfully clearing the resolver cache.

PowerShell also provides a dedicated command:

These methods clear the local DNS client cache. They do not automatically purge cached records stored by your router, ISP, corporate DNS resolver, browser, or a public DNS provider.

How to Flush DNS Cache on macOS

DNS cache management on macOS can vary by operating system generation because Apple’s underlying networking components have changed over time. On modern macOS systems, a commonly used Terminal command is:

Enter your administrator password when requested. Terminal may provide little or no dramatic confirmation. This is normal; apparently, clearing a DNS cache does not qualify for fireworks.

Because command behavior can change between macOS releases, administrators managing a specific macOS version should verify the command against documentation appropriate for that release.

How to Flush DNS Cache on Linux

Linux is less interested in giving one universal answer because different distributions and installations may use different resolver services.

Systems Using systemd-resolved

On a system using systemd-resolved, the modern command is:

You can inspect resolver information with:

This helps determine whether systemd-resolved is involved in DNS resolution on the system.

Systems Using Other Caching Services

Some Linux installations may use services such as dnsmasq or nscd. In those environments, restarting the relevant service may clear its cache. Examples can include:

or:

Do not run random service commands simply because a search result told you to. First determine which resolver or caching daemon your system actually uses. Restarting a service that is not installed is harmlessly disappointing; restarting the wrong network component on a production server can be much more exciting than intended.

Can a Browser Have Its Own DNS Cache?

Yes. Modern browsers can maintain connection, host-resolution, or DNS-related state independently of the operating system. Browser behavior is also increasingly influenced by technologies such as DNS over HTTPS, commonly abbreviated as DoH.

With DoH enabled, a browser may send DNS queries to a compatible resolver over an encrypted HTTPS connection rather than relying entirely on traditional plaintext DNS resolution through the operating system’s normal resolver path.

As a result, flushing the operating system cache may not always clear every piece of DNS-related state affecting a browser session.

When diagnosing a browser-specific problem, useful steps include:

• Completely close and reopen the browser.
• Test the same domain in another browser.
• Check whether the browser is configured to use secure or encrypted DNS.
• Compare browser behavior with command-line DNS lookup tools.

Browser diagnostic pages and internal URLs can change between releases, so commands copied from a five-year-old tutorial may no longer exist in the same form.

How to Update DNS Cache on a Router

Some routers act as DNS forwarders or maintain temporary DNS information. If a local router is responsible for stale results, clearing only the computer’s cache may not solve the problem.

Depending on the router, possible approaches include:

• Using a DNS restart or cache-clear option in the administration interface
• Reconnecting or restarting the router’s DNS service
• Rebooting the router when no dedicated cache function is available

A reboot is a blunt instrument and should not be treated as the answer to every networking mystery. In a business environment, restarting shared network equipment can interrupt users and should be planned appropriately.

What If a Public DNS Resolver Has the Old Record?

Clearing your local cache does not force an external recursive resolver to forget its cached answer.

For example, major public DNS services may continue serving an unexpired cached result. Some providers offer dedicated tools that allow a domain’s DNS cache entry to be refreshed or purged.

Google Public DNS provides a cache-flush mechanism for supported DNS records. Cloudflare’s 1.1.1.1 service also provides a DNS cache purge feature.

This can be especially useful after significant DNS changes, but it is not a magic button for the entire internet. Other recursive resolvers may still have their own cached answers.

Flushing DNS Cache Is Not the Same as Changing DNS Servers

These two actions are frequently confused.

Flushing the DNS cache removes stored DNS answers so that new lookups can be performed.

Changing DNS servers changes which recursive resolver your device uses for future queries.

For example, switching from an ISP-provided DNS resolver to a public resolver changes where new DNS questions are sent. It does not automatically rewrite authoritative DNS records or repair an incorrectly configured domain.

Similarly, flushing the cache will not fix:

• An incorrect authoritative DNS record
• A broken DNS delegation
• A server that is offline
• A firewall blocking access
• An expired or invalid TLS certificate
• A local hosts file containing an incorrect manual entry

DNS is often blamed because it sits near the beginning of the connection process, but sometimes DNS is merely standing near the crime scene.

How to Verify That a DNS Update Worked

After clearing a cache, do not rely only on refreshing the website repeatedly. Check the actual DNS response.

Common command-line tools include:

and, on systems where it is available:

Compare the returned address with the DNS record you expect.

For deeper troubleshooting, check:

• The resolver that answered the query
• The returned record type
• The TTL
• Whether IPv4 and IPv6 records differ
• Whether another network returns a different answer
• Whether the authoritative DNS servers return the expected record

This process helps identify the actual caching layer rather than repeatedly flushing everything in sight.

A Practical DNS Cache Troubleshooting Sequence

When a domain appears to resolve incorrectly, use a structured approach:

1. Confirm the expected DNS record at the authoritative source.
2. Query the domain using a DNS lookup tool.
3. Check which resolver is answering.
4. Compare results from another device or network.
5. Flush the local operating system DNS cache.
6. Restart the affected browser or application if necessary.
7. Check whether a router or local network resolver is involved.
8. Compare results from different recursive DNS providers.
9. Wait for existing TTLs to expire when an upstream cache cannot be manually purged.

This method is usually faster than performing the traditional networking ritual of clicking Refresh 47 times and becoming increasingly suspicious of the modem.

Should You Flush DNS Cache Regularly?

For most users, no. DNS caching is designed to improve performance, and cached records normally expire according to their TTLs.

There is usually no benefit in clearing the cache every few minutes as routine maintenance. The first lookup after a flush may require fresh resolution instead of benefiting from an existing cached answer.

Flushing DNS is most useful when you have a specific reason, such as:

• A recent DNS change
• A known stale record
• A domain that resolves differently across devices
• A corrected DNS failure that may still be negatively cached
• A controlled troubleshooting or testing procedure

Practical Experiences and Lessons From DNS Cache Troubleshooting

Real-world DNS troubleshooting tends to teach one lesson very quickly: the first cache you clear is not always the cache causing the problem. The following scenario-based experiences reflect common patterns seen by website owners, developers, and network administrators.

Experience 1: The Website Migration That Looked Broken

A common situation occurs after moving a website to a new server. The DNS A record is updated correctly, and external checks show the new IP address. Yet one office computer still loads the old website.

The natural reaction is to assume the DNS change failed. In reality, the affected computer may simply have an older cached answer. Flushing its local DNS cache can force a new query, after which the domain resolves to the new server.

The useful lesson is to compare multiple devices before changing DNS records again. Editing a correct record because one computer has stale information can turn a small cache problem into an actual DNS configuration problem.

Experience 2: Flushing Windows Did Not Fix the Browser

Another frustrating scenario begins with a successful ipconfig /flushdns. The command confirms that the Windows resolver cache was cleared, but the website still behaves exactly as before.

Testing the same domain in another browser suddenly works.

That clue changes the investigation. The operating system cache was only one layer. The original browser may still have DNS-related state, active connections, secure DNS settings, or other cached networking information. Restarting the browser or reviewing its encrypted DNS configuration can be more useful than running the Windows command ten more times.

The broader lesson is that a successful cache-flush message confirms only that a particular cache was cleared. It does not certify the entire internet as freshly washed.

Experience 3: Everyone in One Office Saw the Old Address

Suppose every employee on one network receives the old DNS result, while users on mobile data see the new server. Clearing individual computers provides no lasting improvement.

That pattern suggests looking beyond each device. A shared router, corporate resolver, ISP resolver, or other upstream caching layer may still be answering with the old record.

Comparing responses from multiple resolvers helps narrow the problem. If one resolver returns the old address while another returns the new one, the evidence points toward resolver caching rather than a web server failure.

This is why troubleshooting patterns matter. One broken device suggests a local issue. An entire network seeing the same stale answer suggests a shared layer.

Experience 4: The New Subdomain That “Did Not Exist”

A developer tests a planned hostname before the DNS record has been created. The lookup fails. Ten minutes later, the record is added, but the developer still receives a nonexistent-domain response.

This can be a negative caching problem. A previous failure may be temporarily remembered by a local or recursive resolver. Clearing the appropriate local cache may help, but an upstream resolver may still need to let the negative cache entry expire.

The practical lesson is simple: unsuccessful DNS answers can be cached too. During launches and migrations, testing a hostname too early can occasionally create temporary confusion.

Experience 5: The Best Fix Was Not Flushing Anything

Sometimes every resolver returns the correct IP address and flushing every available cache changes absolutely nothing. Further investigation reveals that the server is down, the firewall is blocking traffic, or the browser is rejecting a certificate problem.

This may be the most valuable DNS troubleshooting experience of all. Verify the DNS answer before assuming the cache is guilty.

A methodical check of the current record, resolver response, network route, and application error usually beats randomly clearing caches. DNS cache flushing is a useful tool, not a universal repair button.

Conclusion

A DNS cache stores previous domain-name resolution results so websites and online services can be reached more efficiently. Records normally remain cached only for a defined period, controlled largely by TTL values and resolver behavior.

When DNS information changes, however, an old cached answer can temporarily point a device toward the wrong destination. Updating or flushing the DNS cache may help by forcing a fresh lookup, but the correct method depends on where the stale result is stored.

Windows users can clear the local resolver cache with ipconfig /flushdns or Clear-DnsClientCache. Systems using systemd-resolved can use resolvectl flush-caches. macOS and other Linux configurations may require commands appropriate to their specific resolver services. Browsers, routers, corporate networks, and public recursive resolvers may introduce additional caching layers.

The smartest approach is therefore not simply to flush everything. First identify where the incorrect DNS answer is coming from. Then clear the relevant cache, verify the new result, and remember the golden rule of network troubleshooting: when the internet acts haunted, collect evidence before calling an exorcist.