ipconfig /flushdns: What It Fixes, and What It Definitely Does Not

Q: What is the difference between ipconfig /flushdns and /release /renew?

They solve unrelated problems. /flushdns clears cached DNS lookups. /release and /renew drop and re-request your DHCP lease, which is about your own IP address, not name resolution. They get recommended together as a ritual, but if your problem is a stale DNS record, only the flush is relevant.

Q: How long does DNS propagation actually take?

As long as the TTL on the record, which you can read with dig example.com +noall +answer. That is the real number - the commonly repeated twenty-four to forty-eight hours is a worst case reflecting high TTLs and resolvers that ignore them. If you lower the TTL to 300 seconds a day before a migration, propagation takes about five minutes. The waiting is decided in advance, not after.

ipconfig /flushdns in an elevated Command Prompt clears the DNS resolver cache on your Windows machine, so the next lookup for any hostname goes out fresh instead of using a stored answer. It takes a second and it genuinely fixes one problem: you changed a DNS record, and your own computer is still using the old one. What it does not do - and this is the part that matters if you just moved a domain - is affect anyone else. Not your users, not their ISPs, not the resolvers in between. Flushing your local cache changes exactly one machine’s view of the world: yours.

Every result for this command is an IT helpdesk page telling an end user to run it. Useful advice for one laptop. Actively misleading if you are the person who just repointed an A record and is wondering why half your users still hit the old server.

The commands, on every platform
What the cache actually is
The thing nobody tells you: it does nothing for your users
When flushing actually helps
Diagnosing properly instead of flushing hopefully
How this fits the rest of the stack
FAQ

The commands, on every platform

# Windows - run as Administrator
ipconfig /flushdns

# Verify what is cached now
ipconfig /displaydns

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
sudo resolvectl flush-caches
resolvectl statistics

# Linux with nscd
sudo systemctl restart nscd

On Windows you need an elevated prompt - without it you get an access-denied message that people mistake for the command not existing.

Two related commands worth knowing, because they solve a different problem:

ipconfig /release
ipconfig /renew

These drop and re-request your DHCP lease - an IP address operation, nothing to do with DNS. They are bundled into the same helpdesk advice so often that people run all four as a ritual without knowing which one did anything.

What the cache actually is

When your machine resolves example.com, it stores the answer along with a TTL - a number of seconds the record is considered valid. Until the TTL expires, your machine answers from memory without asking anyone.

That is a feature. Without it, every request would trigger a DNS lookup and everything would be slower and noisier. The cache is why the web feels fast.

The cost is staleness. If the record changes during the TTL window, your machine keeps using the old answer until the TTL runs out. Flushing is you saying: forget what you know, ask again.

Critically, your machine is not the only cache in the chain:

Your browser has its own internal DNS cache, separate from the OS.
Your operating system has the resolver cache - the one flushdns clears.
Your router often caches too.
Your ISP’s resolver caches, and this one serves thousands of people.
Any public resolver in the path caches as well.

ipconfig /flushdns clears exactly item 2. Items 1 and 3 through 5 do not care that you ran it.

The thing nobody tells you: it does nothing for your users

This is the whole reason this article exists. You update a DNS record, you flush your cache, you see the new server, and you conclude the change has propagated. It has not. You have only changed what you see.

Your users’ machines still hold the old answer for as long as their TTL says. Their ISPs’ resolvers hold it too, and some of them ignore your TTL and keep records longer than they should. There is no command you can run to flush someone else’s cache. There is no button. Propagation is not a thing you trigger; it is a thing you wait for.

Which makes the TTL the only real control you have, and it works ahead of time:

Before a planned migration, drop the TTL to 300 seconds and wait for the old TTL to expire. Now every resolver refreshes every five minutes.
Make the change. Propagation now takes minutes rather than a day.
Afterwards, put the TTL back up to something sensible - 3600 or more - so you are not paying for constant lookups.

The mistake is lowering the TTL at the same time as making the change. The old TTL is still in effect for everyone who cached it, so your new low TTL is itself stuck behind the old high one. Lower it a day early. This is the single most useful thing on this page.

When flushing actually helps

It is a legitimate tool for a narrow set of problems:

You changed a record and want to verify it yourself. The main honest use.
You edited your hosts file and the machine is still using the cached DNS answer.
You switched VPN or network and are resolving internal names against the wrong resolver.
A site moved and you are getting the old server while colleagues are fine.

In every case the scope is your machine. That is fine - just do not mistake it for a fix that reaches anyone else.

One caveat: your browser has its own cache and often ignores the OS flush entirely. If Chrome still shows the old site after a flush, clear its internal cache at chrome://net-internals/#dns, or just use a private window. This is why flushing sometimes appears not to work.

Diagnosing properly instead of flushing hopefully

If you want to know what a record actually resolves to right now, ask a resolver directly and bypass every cache in between.

# Ask a public resolver, ignoring your local cache entirely.
nslookup example.com 8.8.8.8

# Better tool if you have it.
dig @8.8.8.8 example.com

# What is the TTL? This is the number that governs propagation.
dig example.com +noall +answer

The TTL in that output tells you how long anyone who cached the record will keep it. That is your actual propagation window - not a guess, not the vague twenty-four to forty-eight hours everyone repeats.

Querying several public resolvers is how you check propagation honestly. If 8.8.8.8 and 1.1.1.1 both return the new value, the change is live and any remaining stale views are downstream caches waiting out their TTL. There is nothing to do at that point except wait, which is an unsatisfying answer but a true one.

How this fits the rest of the stack

DNS is the layer where a five-second change takes a day to be true everywhere, and the only lever that helps is one you had to pull yesterday. It is also, notably, a layer most teams should not be hand-managing at all - the records, the certificates that depend on them, and the renewals are undifferentiated work. If you are weighing what a managed setup is worth, the RunxBuild hosting calculator puts the service, the domain, the bandwidth, and the database side by side so the trade is a number. The RunxBuild dashboard is where the team sees the domains and traffic together.

Useful related references:

FAQ

What does ipconfig /flushdns actually do?

It clears the DNS resolver cache on your Windows machine, discarding stored hostname-to-IP answers so the next lookup goes out fresh. It affects only that one computer. It does not touch your browser’s separate internal cache, your router, your ISP’s resolver, or any other machine - which is why it fixes your view of a DNS change and nothing else.

Does flushing DNS help my users see a DNS change faster?

No. It only clears your own machine’s cache. Your users’ computers and their ISPs’ resolvers hold the old record until its TTL expires, and there is no way to flush a cache you do not control. The only real lever is the TTL, and it has to be lowered before the change - typically a day ahead, so the old TTL has expired and resolvers are refreshing frequently by the time you switch.

Why is the site still showing the old server after flushing DNS?

Most likely your browser’s own DNS cache, which is separate from the operating system’s and is not cleared by ipconfig /flushdns. Try a private window, or clear it at chrome://net-internals/#dns. If that does not help, the answer may still be cached upstream at your router or ISP resolver - check with dig @8.8.8.8 example.com to see what a public resolver actually returns.

What is the difference between ipconfig /flushdns and /release /renew?

They solve unrelated problems. /flushdns clears cached DNS lookups. /release and /renew drop and re-request your DHCP lease, which is about your own IP address, not name resolution. They get recommended together as a ritual, but if your problem is a stale DNS record, only the flush is relevant.

How long does DNS propagation actually take?

As long as the TTL on the record, which you can read with dig example.com +noall +answer. That is the real number - the commonly repeated twenty-four to forty-eight hours is a worst case reflecting high TTLs and resolvers that ignore them. If you lower the TTL to 300 seconds a day before a migration, propagation takes about five minutes. The waiting is decided in advance, not after.