How to Flush DNS Cache (All Platforms)

What DNS Cache Actually Is

Every time your OS resolves example.com to an IP address, it stores that answer locally for as long as the record's TTL (time to live) says it's valid — anywhere from 60 seconds to 24 hours or more. This avoids repeating a full DNS lookup for every request to the same domain.

The problem: if the record changes at the authoritative nameserver (new hosting IP, migrated DNS provider, corrected typo) before your local TTL expires, your machine keeps serving the old, cached answer. Flushing the cache deletes those stored entries immediately, forcing a fresh lookup on the next request instead of waiting out the TTL.

This matters most right after infrastructure changes: moving a site to a new host, switching CDN providers, or fixing a misconfigured record. Without a flush, you could keep hitting the old server for hours purely because your own machine hasn't asked again yet — even though every other visitor whose resolver has already expired its cache sees the change instantly.

There isn't one DNS cache — there are several, stacked on top of each other, and flushing one doesn't touch the others:

1. Browser cache — Chrome and Firefox keep their own internal DNS cache, separate from the OS.
2. OS resolver cache — Windows, macOS, and Linux each cache lookups at the system level.
3. Router cache — many home/office routers cache DNS answers for connected devices.
4. ISP / public resolver cache — your ISP's resolver (or 8.8.8.8, 1.1.1.1 if you use one) caches the record independently until its own copy of the TTL expires.

You can only flush the first two locally. The router and upstream resolver caches expire on their own schedule — see Why Flushing Didn't Fix It below.

Each cache layer stores the record for its own copy of the TTL, independently. That means at any given moment, your browser, your OS, your router, and your ISP's resolver can each be holding a different cached answer for the same domain — the browser might have refreshed 30 seconds ago while the router is still serving an answer from 20 minutes ago. This is why "I flushed DNS and it's still wrong" is almost always a layer problem, not a flush-command problem.

Where DNS Cache Lives on Each Platform

Understanding what's actually being cleared makes the commands below easier to remember instead of just copy-pasting them.

• Windows runs a dedicated DNS Client service (Dnscache), which holds resolved records in memory and serves them to any application on the machine without a fresh lookup.
• macOS resolves through mDNSResponder, a background daemon that also handles Bonjour/mDNS discovery; dscacheutil is a separate directory-services cache that sits in front of it.
• Linux has no single built-in cache — whether anything is cached depends entirely on which resolver daemon the distro ships: systemd-resolved (most modern distros), nscd, dnsmasq, or nothing at all (some minimal server images resolve directly via /etc/resolv.conf with no caching layer).
• Chrome and Firefox maintain their own internal DNS cache in the browser process, independent of whatever the OS is doing — this is a deliberate performance optimization that predates most OS-level DNS caching improvements.

Flush DNS Cache on Windows

Works on Windows 10, 11, and Server 2016–2025.

# Open Command Prompt or PowerShell (admin not required in most configurations)
ipconfig /flushdns

Expected output: Successfully flushed the DNS Resolver Cache. Per Microsoft Learn's ipconfig reference, this clears the DNS Client (Dnscache) service's local cache only — it does not release or renew your IP address.

Common mistake: ipconfig /release and ipconfig /renew are for DHCP leases, not DNS cache. They don't clear cached DNS records. If the command fails with an access-denied error, some managed/corporate machines restrict the DNS Client service to admin accounts — re-run the prompt as Administrator.

To inspect what's currently cached before flushing:

ipconfig /displaydns

Flush DNS Cache on macOS

The command changed across macOS versions — using the wrong one silently does nothing.

Run both parts of the Big Sur+ command — dscacheutil -flushcache clears the directory service cache, but mDNSResponder keeps its own separate cache that needs the killall -HUP signal to reload. Running only one half is the most common reason a Mac flush "doesn't work."

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

There's no confirmation message on success — no output means it worked.

Flush DNS Cache on Linux

Linux has no single universal DNS cache — the correct command depends on which resolver/caching service the distro actually runs. Many minimal installs (Alpine, some Debian netinst configs) don't cache DNS at all, so there's nothing to flush.

systemd-resolved (Ubuntu 18.04+, Fedora, most modern distros with systemd ≥ 239):

sudo resolvectl flush-caches

Older systemd releases (before the 239 rename) use the deprecated systemd-resolve --flush-caches — check with resolvectl --version; if the binary isn't found, your systemd predates the rename.

nscd (Name Service Cache Daemon — some enterprise/RHEL-family setups):

sudo systemctl restart nscd

dnsmasq (common on routers and lightweight Linux DNS setups):

sudo systemctl restart dnsmasq

Confirm which service is actually running before picking a command:

systemctl status systemd-resolved nscd dnsmasq 2>/dev/null | grep -B2 "Active:"

If none of the three services is active, your distro likely resolves DNS directly through glibc's resolver with no caching layer at all — there's nothing local to flush, and stale results are coming from your router or upstream resolver instead.

Older systemd (pre-239) fallback, if resolvectl isn't found:

sudo systemd-resolve --flush-caches

Quick Reference: Command by Platform

Router and ISP resolver caches aren't in this table because they can't be flushed remotely — they clear only when the record's own TTL expires at that resolver.

Flush DNS Cache in Chrome and Firefox

Browsers cache DNS lookups independently of the OS — flushing the OS cache does not clear the browser's copy, and vice versa.

Chrome / Edge:

1. Go to chrome://net-internals/#dns (Edge: edge://net-internals/#dns)
2. Click Clear host cache
3. Optionally go to the #sockets tab and click Flush socket pools to drop pooled connections too

Firefox: Firefox doesn't persist its DNS cache to disk, so a full browser restart clears it. To clear it without restarting, go to about:networking#dns and click Clear DNS Cache.

When Flushing DNS Cache Is the Right Move

Flush DNS cache when you've just changed a DNS record — a new hosting IP after a server migration, a corrected typo in an A record, a nameserver switch — and you want your own machine to see the new value immediately instead of waiting for your local TTL to expire naturally. It's also worth trying as a first step when a browser throws DNS_PROBE_FINISHED_NXDOMAIN or a similar resolution error, since a corrupted or stuck local cache entry is a common, easy-to-rule-out cause.

It is not a fix for problems that live upstream of your machine. If the domain doesn't resolve anywhere — not just on your device — flushing changes nothing, because there's no local stale entry to clear; the record itself is missing or broken at the authoritative nameserver. Confirm what's actually being published before assuming a flush will help.

Why Flushing Didn't Fix It

If a site still resolves to the old server after flushing every local cache above, the stale answer is being served from a layer you can't flush directly. Check in this order:

1. Browser cache — clear it first (see above); it's checked before the OS cache on most requests.
2. OS resolver cache — flush per your platform above.
3. Router cache — reboot the router, or bypass it: point your machine's DNS temporarily at 8.8.8.8 or 1.1.1.1 to test with a query that skips your router's cache entirely.
4. ISP / public resolver cache — this one isn't yours to flush. It expires only when the record's TTL runs out at that specific resolver. Run the domain through the DNS Propagation Checker to see, per region and resolver, whether the new record has actually landed yet.

A 300-second TTL clears from most resolvers within 5–10 minutes of the record change. An 86400-second (24-hour) TTL can take up to 24–72 hours for every independent resolver worldwide to expire its own cached copy — no amount of local flushing speeds that up. If you're planning a DNS change, see DNS Propagation Taking Too Long and DNS TTL Explained for how to lower TTL in advance of a migration.

If the record itself looks wrong at the authoritative level (not just cached stale), confirm what the nameservers are actually publishing with the DNS Lookup and NS Lookup tools — a flush can't fix a record that's genuinely misconfigured upstream.

How to Verify the Flush Worked

Don't guess — check the resolved IP before and after.

# Before flushing, note the current cached answer
nslookup example.com

# Windows: check what's cached
ipconfig /displaydns | findstr example.com

# After flushing, query again and compare the returned IP
nslookup example.com

If the IP address changes between the two queries, the flush worked and your machine is now pulling a fresh answer. If it's identical, either nothing was cached for that domain, or the resolver you're querying against still has its own cached copy — cross-check with the Reverse DNS Lookup tool or an external resolver to isolate where the stale answer is coming from.

For a more reliable check, query an external public resolver directly instead of relying on whatever your system defaults to — this bypasses your OS cache entirely and shows you what's actually being published right now:

# Query Google's public resolver directly, bypassing local cache
nslookup example.com 8.8.8.8

# Or with dig, showing the TTL Google's resolver currently has cached
dig example.com @8.8.8.8

If the record returned by 8.8.8.8 already matches what you expect but your browser or OS still shows the old value, the problem is confirmed to be local — repeat the flush steps for your platform above. If 8.8.8.8 also returns the old value, the authoritative nameserver hasn't finished propagating the change yet, and no local flush will fix that; wait out the TTL or check progress with the DNS Propagation Checker.

Verify DNS changes without repeated manual checks. DNSnexus Monitor watches your DNS records and alerts you when propagation completes or a record drifts from what you expect. Free tier covers one domain.

Frequently Asked Questions

Key Takeaways

• ✓ ipconfig /flushdns (Windows), dscacheutil -flushcache && killall -HUP mDNSResponder (macOS Big Sur+), and resolvectl flush-caches (Linux/systemd-resolved) are the three primary commands.
• ✓ Browser DNS cache is separate from OS cache — clear both when troubleshooting.
• ✓ A local flush can't override a router or ISP resolver's own cached copy of a record — that only clears when the record's TTL expires.
• ✓ Verify a flush worked with nslookup before/after, not by assumption.

Related Guides

• What Is DNS Cache? How Browser and OS Caching Works
• DNS TTL Explained
• DNS Propagation Taking Too Long
• DNS Hijacking and Spoofing Defense
• Fix DNS Server Not Responding (All Devices)