Clearing your DNS cache

I migrated a website to a new server once, updated the DNS A record, watched the new box light up with traffic from everywhere — except my own laptop, which stubbornly kept loading the old server for the better part of an hour. Nothing was broken. The record had changed. The internet at large had noticed. My machine simply hadn’t, because it had cached the old answer and intended to keep using it until its timer ran out. That gap — between “the record changed” and “your computer agrees” — is what flushing the DNS cache fixes, and it’s the single most common reason a site works for everyone except the one person standing in front of you.

DNS is the system that turns example.com into the numeric IP address your machine actually connects to. Doing that lookup from scratch every time would be slow and wasteful, so every layer in the chain — your operating system, often your browser, your router, your ISP’s resolver — keeps a local copy of recent answers. That copy is the cache. It’s almost always a win, right up until the cached answer is wrong, at which point it’s the thing standing between you and a working website. Knowing how to clear it is basic networking hygiene, and it’s worth understanding why it goes stale before reaching for the commands.

A little history, because it explains the behaviour

Before DNS existed, name-to-address mapping lived in a single file called HOSTS.TXT, maintained by hand at the Stanford Research Institute and copied around the early ARPANET. Every host on the network needed the whole list, and every change meant redistributing the file. By the early 1980s that obviously couldn’t scale. In 1983, Paul Mockapetris designed the Domain Name System — described in RFCs 882 and 883, later superseded by 1034 and 1035 — to distribute the lookup across a hierarchy of servers instead of one flat file.

Caching was baked in from the start, and the mechanism is a number attached to every record called the Time To Live, or TTL, measured in seconds. When a resolver hands you an answer, it also says “this is good for the next 3600 seconds.” Your machine honours that, serving the cached answer until the TTL expires rather than asking again. This is why the laptop in my migration story kept loading the old server: the old A record had a one-hour TTL, and my machine was dutifully respecting it. The lesson every admin learns once: lower the TTL on a record a day or two before you plan to change it, so the world’s caches expire quickly when the change lands. I forgot to, and paid for it in confused refreshing.

Why you’d actually clear it

Three real reasons, in rough order of how often they come up:

1. A site moved and you’re still hitting the old address. Exactly the migration case above. The authoritative record is correct; your local cache is stale. Flushing forces a fresh lookup and you immediately get the new address.
2. You changed something and want to confirm it. If you’ve just edited a record — repointed a subdomain, added a service — clearing the cache lets you test the new state without waiting out the TTL. This is half of what flushing is for, in practice: it’s a development and debugging tool as much as a fix.
3. Something poisoned the cache. Less common on a well-run machine, but malware and certain adware can inject bogus entries to redirect you to lookalike sites. Flushing removes them. It’s not a substitute for actually cleaning the infection, but it clears the immediate redirection.

There’s a privacy angle too — the cache is a record of domains you’ve resolved recently — but it’s a weak one. The cache is short-lived and local; if you care about query privacy, the real answer is encrypting your DNS, which I cover in running your own DoH resolver at home. Flushing the cache is troubleshooting, not protection.

The cache you forgot about: your browser

Here’s the trap that wastes more time than any other. You flush the operating-system cache, run dig, see the correct address — and the site still loads the old server in Chrome or Firefox. The reason is that modern browsers keep their own internal DNS cache, entirely separate from the OS. Your ipconfig /flushdns never touched it.

Chrome exposes its cache at chrome://net-internals/#dns, where there’s a “Clear host cache” button; the same page exists in other Chromium-based browsers. Firefox doesn’t surface a button, but restarting the browser clears it, and for the impatient there’s a connection-settings toggle. The practical rule: if the OS cache is clean and dig is correct but one specific browser is wrong, the browser is the culprit, not your network. I have watched experienced people lose half an hour to this because they never suspected the browser was caching independently. It is, and it does.

There’s a third layer worth knowing about on top of these two. Long-running applications — a mail client, a database connection pool, anything that resolved a hostname once at startup and held the connection open — won’t re-resolve just because you flushed every cache on the machine. They cached the address in their own memory. For those, the only reliable flush is restarting the process. No ipconfig command reaches inside a running application’s connection pool.

The honest downside

Flushing isn’t free. Every cached answer you throw away is a lookup your machine now has to repeat, so the first visit to each site afterwards is marginally slower while the cache refills. On a single machine you’ll never notice. If you got into the habit of flushing the cache on every reboot across a fleet, you’d be adding a small, pointless tax to network traffic for no benefit. Flush when you have a reason — a stale answer, a change to verify, a suspected poison — not on a reflex.

The commands, per platform

The mechanics differ by operating system because the thing doing the caching differs.

Windows 10 and 11

The OS resolver cache is managed by the DNS Client service. Open a Command Prompt or PowerShell (Win + R, type cmd, Enter) and run:

1

ipconfig /flushdns

You’ll get Successfully flushed the DNS Resolver Cache. Want to see what’s in there first? ipconfig /displaydns dumps the current cache, which is genuinely useful when you’re trying to confirm whether a stale entry is the culprit before you nuke it.

macOS

macOS caches via mDNSResponder. The flush is two commands chained together — clear the directory-service cache and signal the responder to drop its own:

1

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

It runs silently and asks for your admin password. There’s no success message; no error means it worked. This incantation has been stable across recent macOS releases, but Apple has changed the exact daemon name in the past, so if killall reports “no matching processes,” check what’s actually running with ps -ax | grep mDNS.

Linux

Linux is the awkward one, because there’s no single answer — it depends entirely on which caching resolver, if any, your distribution runs. Many minimal Linux installs don’t cache DNS at all; the lookup goes straight out and there’s nothing to flush. When a cache is present, identify the service first:

1
2
3

# Which resolver is in play?
resolvectl status            # systemd-resolved
systemctl status systemd-resolved dnsmasq nscd unbound 2>/dev/null

Then flush the one you’ve got:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# systemd-resolved (default on modern Ubuntu, Fedora, Debian)
sudo resolvectl flush-caches          # the older command is: systemd-resolve --flush-caches

# dnsmasq — restart the service
sudo systemctl restart dnsmasq

# nscd (Name Service Cache Daemon)
sudo systemctl restart nscd           # or: nscd -i hosts

# unbound
sudo unbound-control reload

Note resolvectl flush-caches — the older systemd-resolve --flush-caches form still works on many systems but has been deprecated in favour of resolvectl. If you run a network-wide resolver rather than a per-machine cache, flushing the right box matters: clearing your laptop does nothing if the stale answer is being served by your Pi-hole and Unbound setup upstream. In that case it’s the resolver on the network you flush, not the client — and if you’ve gone a step further and use DNS to block known-bad destinations, as in sinkholing malware domains at the network level, remember that your sinkhole’s own cache can hold a record after you’ve changed a blocklist. The general principle: the cache that matters is the last one in the chain that answered your query, and on a network with a central resolver that’s usually not the machine you’re sitting at. Flush from the outside in if you’re unsure, and re-test after each layer.

Verify it actually worked

This is the step most guides skip, and it’s the one that turns “I ran a command” into “I confirmed the fix.” After flushing, query the name directly and look at the answer:

1
2

dig +short example.com         # Linux/macOS — shows the resolved address
nslookup example.com           # cross-platform, including Windows

If the address now matches the new record, you’re done. If it’s still the old one, the staleness is upstream of you — your router or ISP resolver is still serving the cached answer, and flushing your own machine won’t help until theirs expires too. dig will also show you the TTL countdown on the answer, which tells you exactly how long an upstream cache has left before it gives up the stale value. That single number ends a surprising number of “why is it still broken” arguments. Even better, pointing dig at a specific public resolver — dig @<public-resolver> example.com, using your provider of choice’s well-known address — queries it directly, bypassing every cache between you and it. Compare that answer with your local one and you can pinpoint exactly which layer is holding the stale record. When the public resolver is already correct but yours is not, the problem is definitively local, and you’ve just saved yourself an argument with the hosting provider.

Is it worth knowing?

For anyone who runs services, edits DNS records, or troubleshoots “it works for me but not for them,” yes — unreservedly. It costs nothing to learn, takes one command to do, and resolves a class of problem that otherwise sends people down hour-long rabbit holes blaming the server, the browser, and eventually the moon. It is not a routine-maintenance task; you don’t need a monthly cron job flushing caches on a healthy machine. It’s a precision tool for a specific symptom: the address your computer remembers is no longer the right one. Reach for it then, verify with dig, and move on. If you find yourself flushing constantly, the real problem is elsewhere — likely a TTL you set too high, or a record you keep changing — and that’s worth fixing properly instead of papering over with repeated flushes.