In short. There are at least five DNS caches between you and an answer, and flushing one leaves the other four untouched. That is why "I flushed DNS and still see the old site" is the normal outcome rather than a puzzle — the copy that is actually serving you is usually one you cannot flush at all.
The five caches, and which ones you control
A name is resolved through a chain, and every link may keep its own copy with its own timer. Flushing is a per-link operation.
| Cache | Who controls it | Can you flush it? | Typical lifetime |
|---|---|---|---|
| Browser's own resolver cache | You | Yes | Minutes, browser-specific |
| Operating system resolver | You | Yes | Follows the record's TTL |
| Router on your network | You, by restarting it | Usually | Follows TTL, sometimes longer |
| Recursive resolver (ISP or public) | Not you | No | Strictly the record's TTL |
| Authoritative answer itself | The domain owner | Not a cache — the source | Whatever TTL is published |
The fourth row is the one that matters and the one every guide omits. The recursive resolver holds the copy that most of your traffic actually uses, it belongs to your provider or to a public service, and no command on your machine reaches it. It will re-ask when the TTL it was given expires and not one second sooner.
Flushing your own caches changes what you see. It says nothing about what your visitors see, and it cannot accelerate a DNS change for anyone else. If you are waiting for a record to take effect worldwide, flushing is not a lever — it is a way to check on your own machine, and nothing more.
Before flushing: look at what is actually cached
Flushing destroys the evidence. Reading it first tells you whether there is anything to fix and how long it will last.
# Ask a public resolver WITHOUT making it fetch a fresh answer —
# this shows the cached copy and its remaining lifetime
dig example.com A @1.1.1.1 +norecurse +noall +answer
# example.com. 212 IN A 203.0.113.10
# ^ seconds until this resolver re-asks
# Compare against the source of truth, bypassing every cache
dig +short example.com A @$(dig +short NS example.com | head -1)Three readings and three conclusions. If the cached value matches the authoritative one, nothing is stale and flushing achieves nothing. If they differ and the number is counting down, you know exactly how long the difference lasts. If the authoritative servers disagree with each other, no amount of flushing will help — that is a zone problem, covered in the resolver disagreement guide.
Flushing each layer
Windows
ipconfig /flushdns
ipconfig /displaydns | more # inspect before flushingmacOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderLinux
# systemd-resolved (most modern distributions)
resolvectl statistics # cache size and hit rate, before
sudo resolvectl flush-caches
# dnsmasq
sudo systemctl restart dnsmasq
# nscd (older systems)
sudo systemctl restart nscdMany Linux systems run no DNS cache at all, in which case there is nothing to flush and every lookup already goes upstream. resolvectl statistics tells you whether a cache exists before you go looking for a command to clear it.
Browsers keep their own, separately
This is the most common reason a flush appears not to work. Chromium browsers maintain an internal host cache that the operating system command does not touch, plus a pool of open sockets to addresses already resolved.
# Chrome, Edge, Opera, Brave — both of these, in this order
chrome://net-internals/#dns -> Clear host cache
chrome://net-internals/#sockets -> Flush socket poolsClearing the host cache while a connection to the old address is still pooled leaves the browser using that connection. Flushing sockets is what actually forces a new one. Firefox has an equivalent under about:networking#dns; Safari relies on the system cache and a restart.
The router
Most home routers cache DNS for every device behind them, which is why one machine can be flushed and still get the old answer. A restart clears it. The signature is that every device on the network agrees on a stale value while a phone on mobile data sees the new one.
Why you still see the old site after flushing everything
Work down this list; each item is a different cache and a different owner.
- Browser socket pool. An open connection to the old address is reused regardless of DNS. Flush sockets, or restart the browser.
- Router cache. Restart it, or test from a device on a different network.
- Your recursive resolver still holds it. You cannot flush this. Confirm with
+norecurseand read the remaining TTL — that number is your answer. - The record has not actually changed. Ask an authoritative nameserver directly before blaming caching.
- Something else caches the destination. A CDN or reverse proxy serving old content is not a DNS problem at all, and no DNS flush will move it.
Point five catches people regularly. If DNS now resolves correctly and the page is still old, DNS is finished doing its job — the stale copy is in an HTTP cache. The header checker shows cache headers such as age and x-cache, which distinguishes the two in one request.
Negative answers are cached too
A "this name does not exist" answer is cached like any other, and its lifetime comes from the zone's SOA record rather than from the record you just created. Publish a name that previously did not exist and resolvers which asked during the gap will keep saying it does not exist for the duration of that negative TTL.
# The last number in the SOA is the negative caching TTL
dig +short SOA example.com
# ns1.example.com. hostmaster.example.com. 2026082301 7200 3600 1209600 3600
# ^ negative TTLThis is why a newly added subdomain sometimes appears instantly for one person and not for another: the second person's resolver asked a minute too early and is honouring the answer it was given.
What flushing is actually for
Used correctly it is a diagnostic instrument, and a good one. It answers exactly one question: is the thing I am seeing my own stale copy?
| Situation | Does flushing help? | What actually resolves it |
|---|---|---|
| You changed a record and want to verify it | Yes | Flush, then re-query |
| You want visitors to see the change sooner | No | Nothing — their resolvers honour the old TTL |
| Site loads for colleagues, not for you | Often | Flush all your layers, including the browser |
| You migrated and traffic still hits the old server | No | Wait out the previously published TTL |
| Page content is stale but the address is right | No | Purge the HTTP or CDN cache instead |
| A newly created name says it does not exist | Locally only | Wait out the negative TTL from the SOA |
Lower the TTL before a migration, never during one. Resolvers honour the lifetime they were given when they cached the record, so a value lowered after the change applies to the next change and does nothing for this one.
Checking without flushing at all
If the question is "has my change taken effect", you do not need to flush anything — you need to look at resolvers other than your own.
The propagation check queries resolvers in different regions and shows what each currently returns, which is the honest version of the question people are really asking. The DNS lookup reads records and their TTLs from outside your network, so your own caches cannot skew the result.
For records that must not change without you knowing — the address behind your main hostname, MX, the NS set — a single lookup only proves the value was right when you looked. Scheduled DNS monitoring records the answer over time and alerts on change, which catches an unauthorised edit or a failed zone transfer in minutes.
Frequently asked questions
I flushed DNS and nothing changed. Why?
Most likely the browser's own cache or a pooled connection, then the router, then your recursive resolver — which you cannot flush and which will hold the old answer until the TTL expires. Check the remaining TTL with +norecurse to see how long that is.
Does flushing speed up propagation for my visitors?
No. It affects only the machine you run it on. Every other resolver keeps its copy for the TTL it was given, and there is no mechanism to invalidate that remotely.
How long until a DNS change is visible everywhere?
At most the TTL that was published before the change. That is the number resolvers were handed when they cached the old value, which is why lowering the TTL afterwards does not help.
Do I need to restart my router?
If every device on your network sees the old value while a phone on mobile data sees the new one, yes — that pattern points squarely at the router's cache.
Is flushing DNS safe?
Yes. It discards cached answers, so the next lookups go upstream and are marginally slower until the cache refills. Nothing is lost.
The address is correct but the page is still old.
Then DNS has finished its job and something is caching the content: a CDN, a reverse proxy or the browser's HTTP cache. Look at the response headers rather than at DNS — an age or x-cache header names the culprit.
Checklist
- Read the cached value and its remaining TTL before flushing anything.
- Flush the browser's host cache and its socket pools, not just the OS.
- Restart the router when every device on the network agrees on a stale value.
- Accept that the recursive resolver is not yours to flush.
- Ask an authoritative nameserver to confirm the record actually changed.
- Check the SOA negative TTL when a newly created name reports as missing.
- Distinguish a stale address from stale content by reading cache headers.
- Lower TTLs before a migration, not during it.
- Use a propagation check rather than flushing to answer "has it taken effect".
- Monitor records that must not change silently.