A DNS record was changed (a server moved, a website was repointed, a new host was added), and one computer still goes to the old address, or says the name does not exist. You want to clear whatever that computer has remembered, and be sure the answer you get afterwards is the right one.
Flushing the cache is one step. The other half of the job is testing: seeing what the machine resolves, which server answered, and whether that server has the right answer. Without that, you cannot tell a stale cache from a DNS server that is simply wrong.
Applies to: Windows 10, Windows 11 and Windows Server (Command Prompt or PowerShell), macOS, and Linux. Where a command needs an elevated prompt or sudo, the text says so. The Linux sections assume systemd-resolved, which is the default on many but not all distributions.
What is going on
Looking up a name is rarely a single question to a single server. A name can be answered from several places, in roughly this order:
- The hosts file on the machine. An entry there wins over DNS on Windows, macOS and Linux (on Linux the order is set in
/etc/nsswitch.conf). - The local resolver cache. Windows (the DNS Client service), macOS (mDNSResponder) and some Linux setups (systemd-resolved, nscd, dnsmasq, unbound) remember answers for the record’s TTL, the number of seconds the DNS server said the answer may be kept.
- The application’s own cache. Browsers keep their own DNS cache, and may skip the operating system entirely if DNS over HTTPS is on.
- The DNS server the machine is configured to use, which has its own cache and may have the old answer too.
- The authoritative server for the domain, which is the source of truth.
Failures are cached as well. A lookup for a name that did not exist, or had no record of the type requested, can be remembered too. That is called negative caching. Microsoft’s ipconfig page says /flushdns discards negative entries as well as dynamically added ones, which is why a name that was missing a minute ago can keep failing after you create the record.
Many Linux systems cache nothing by default. A plain glibc system with no caching daemon asks the DNS server every time, so there is nothing to flush locally. On the test machine used for this article (Arch Linux with systemd-resolved) the cache was active and held entries, but on a server without systemd-resolved, nscd, dnsmasq or unbound there is no local cache and “flush the DNS cache” is not a step you need.
Diagnosis
1. Find out what the machine resolves now
Windows, PowerShell. Resolve-DnsName asks DNS using the machine’s configured servers and shows the TTL of each record:
Resolve-DnsName www.example.com
Resolve-DnsName www.example.com -Type AWindows, Command Prompt or PowerShell:
nslookup www.example.comThe first lines of the nslookup output name the DNS server that answered (“Server:” and “Address:”). That is the quickest way to see which server the machine is really using. If it is a server you did not expect (an old DNS server, a VPN’s resolver, a router), you have found a different problem from a stale cache.
macOS and Linux. dig is the usual tool where it is installed, and getent shows what an ordinary program would get, because it goes through the same resolver library and hosts-file order as applications do:
getent hosts www.example.com
getent ahosts www.example.com
dig www.example.comOn Linux with systemd-resolved, resolvectl query also tells you where the answer came from. In the test, the first query printed -- Data from: cache, and the same query with the cache switched off for that one lookup printed -- Data from: network:
resolvectl query example.com
resolvectl --cache=no query example.comThe man page describes --cache=BOOL as: if false, lookups are routed to the network instead, regardless of whether the answer is already in the local cache. That is a read-only way to prove the cache is the problem without flushing anything.
2. Look at the cache itself
Windows shows the cache with PowerShell or ipconfig. The entries have a TimeToLive in seconds, a Status (Success, NotExist or NoRecords) and the record Data, so you can see whether a name is cached as a failure:
Get-DnsClientCache | Where-Object Entry -like '*example.com*'
Get-DnsClientCache -Status NotExist
ipconfig /displaydnsMicrosoft documents ipconfig /displaydns as showing the DNS client resolver cache, including entries preloaded from the local hosts file and recently obtained records. On a busy machine the list is long, so filter it.
Linux with systemd-resolved shows counters, not the records. In the test, resolvectl statistics printed the current cache size, cache hits and cache misses (here 2 entries, 1404 hits, 2698 misses). Use it to confirm a cache is in use and whether the hits are rising. It does not list names.
resolvectl statisticsmacOS has no supported command to list the resolver cache. [UNCONFIRMED: Apple’s published documentation does not describe a command to display the mDNSResponder cache.]
3. Rule out the hosts file
If a name resolves to a fixed address no matter what DNS says, look for an entry in the hosts file. The paths:
| OS | Hosts file |
|---|---|
| Windows | C:\Windows\System32\drivers\etc\hosts |
| macOS, Linux | /etc/hosts |
On Windows, Resolve-DnsName has -NoHostsFile (“skips the hosts file when resolving this query”) and -DnsOnly (“resolves this query using only the DNS protocol”). Run the same name both ways. If the answers differ, the hosts file, not the cache, is overriding DNS. Flushing the cache does not remove a hosts entry; you have to edit the file.
Resolve-DnsName www.example.com
Resolve-DnsName www.example.com -NoHostsFile -DnsOnlyOn the Linux test machine /etc/nsswitch.conf had hosts: mymachines mdns_minimal [NOTFOUND=return] resolve files myhostname dns. Order matters there: systemd-resolved (resolve) is asked before files, so check cat /etc/nsswitch.conf on your system rather than assuming the hosts file always wins.
4. Check the browser
If the command line gives the right address but one browser still goes to the old one, the browser has its own cache and possibly its own resolver. Browsers can be set to use DNS over HTTPS (often labelled “secure DNS”), which sends lookups straight to a DNS provider and ignores the operating system’s cache, hosts file and DNS server settings. The menu path and the default differ between browsers and versions, so look for “Secure DNS” or “DNS over HTTPS” in the browser’s privacy or security settings. Closing and reopening the browser clears its in-memory cache. [UNCONFIRMED: the exact menu names and the behaviour of each browser’s internal DNS cache vary by browser and version and were not checked against each vendor’s documentation.]
5. Ask a specific DNS server directly
To see what a particular server says, bypassing the one the machine is configured to use, name the server in the query. Use the server you suspect (your internal DNS server) and compare it with a known good one (the domain’s authoritative server, or a public resolver such as 8.8.8.8):
# Windows, PowerShell
Resolve-DnsName www.example.com -Server 10.0.0.1
# Windows, Command Prompt or PowerShell (second argument is the DNS server)
nslookup www.example.com 10.0.0.1
# macOS and Linux
dig @10.0.0.1 www.example.comThese forms are straight from Microsoft’s nslookup and Resolve-DnsName pages: the second nslookup parameter is the DNS name server, and -Server takes the IP addresses or host names of the DNS servers to query. The bare nslookup lines also show the server that answered, which is the evidence you want when two servers disagree. [UNCONFIRMED: Microsoft’s pages do not say whether nslookup consults the local hosts file or the DNS client cache. It is commonly described as sending its own queries to the named server; confirm on your system with a name that is in the hosts file.]
To see the TTL, read the number next to each record. In Resolve-DnsName output it is the TTL column. In dig it is the second column of the answer section. If you query the same recursive server twice and the TTL counts down, the answer is coming from that server’s cache, and it will stay stale until the TTL reaches zero.
Root cause
One of the layers above is holding an old answer (a cache, or a hosts entry), or the DNS server you are using has not yet got the new one. Flushing the local cache only clears the first of those. If the server you asked still gives the old answer when you query it directly, the client is fine and flushing it changes nothing: wait for the server’s cached copy to reach the end of its TTL, fix the record, or point the machine at a server that has the right data.
The fix
Before you start: flushing the cache is safe, and the machine simply refills it as names are looked up. It is not a fix for a wrong record, a wrong DNS server setting, a hosts file entry or a browser using DNS over HTTPS. Do the diagnosis above first so you know a flush is what is needed.
Windows
Either command clears the DNS client resolver cache. Microsoft states that Clear-DnsClientCache is equivalent to ipconfig /flushdns. [UNCONFIRMED: Microsoft Learn does not say whether either command needs an elevated prompt. If it fails with a permissions error or “Function failed during execution”, repeat it from an elevated prompt.]
ipconfig /flushdns
# or, in PowerShell
Clear-DnsClientCacheTo clear the cache on another machine you manage, the cmdlet takes -CimSession. Test it on one machine first.
macOS
These need an administrator account and ask for your password. The right command depends on the macOS version, and Apple’s own page on this is archived and has not been updated.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderApple’s archived support article lists sudo killall -HUP mDNSResponder for OS X Yosemite 10.10.4 and later, sudo discoveryutil mdnsflushcache for 10.10 to 10.10.3, and sudo dscacheutil -flushcache alone for Snow Leopard 10.6. It also says restarting the Mac refreshes cached DNS information. Running both commands in sequence on a current macOS is common practice and harmless, but Apple does not document that. [UNCONFIRMED: Apple’s documentation for current macOS releases (Sonoma, Sequoia and later) does not state which command is required; both are listed here because the archived page names mDNSResponder and the older dscacheutil step.] The commands print nothing when they work.
Linux
First find out whether there is a cache at all. On a systemd system:
systemctl is-active systemd-resolved
resolvectl statusIf systemd-resolved is running, flush it. The resolvectl man page describes flush-caches as flushing all DNS resource record caches the service maintains locally, mostly equivalent to sending SIGUSR2 to systemd-resolved. [UNCONFIRMED: flush-caches was not run here, by design, so whether it asks for sudo or a polkit password on your distribution was not tested.]
sudo resolvectl flush-caches
resolvectl statisticsIf you run a different caching resolver, use its own method. These were checked against each project’s manual, not run:
- nscd: the manual shows
nscd -i <database>to invalidate a database’s cache, sosudo nscd -i hoststargets the hosts cache. Only relevant if nscd is installed and running. [UNCONFIRMED: the manual page does not say in so many words that the hosts database should be named “hosts”.] - dnsmasq: the manual says that on SIGHUP, dnsmasq clears its cache and re-loads /etc/hosts and /etc/ethers. SIGHUP does not re-read its configuration file. Send it with
sudo kill -HUP <pid-of-dnsmasq>or, where it runs as a service,sudo systemctl reload dnsmasq. [UNCONFIRMED: whether the reload action sends SIGHUP depends on how your distribution’s service file is written.] - unbound:
unbound-control flush <name>removes one name,flush_zone <name>removes everything at or below a name (slow, it walks the whole cache), andflush_negativeremoves all negative data (NXDOMAIN, NODATA, SERVFAIL).
If none of those is running, there is nothing to flush. On a Linux system without a caching resolver, a name that is still wrong is wrong at the DNS server, in /etc/hosts, or in /etc/resolv.conf pointing at the wrong server.
If the server is the one with the wrong answer
If querying the server directly (diagnosis step 5) still returns the old address, nothing on the client will fix it. Correct the record on the authoritative DNS server, then wait. The old answer stays on the other resolvers that hold it until its TTL runs out, so lower the TTL on a record before a planned change, not after. On a DNS server you manage, clear its own cache with that server’s tools (for example the DNS Server role on Windows Server has its own cache, separate from the client cache). [UNCONFIRMED: the server-side commands were not covered or checked in this article.]
Verification
Repeat the lookup that failed, once with the system resolver and once against the server you trust, and compare:
# Windows
Resolve-DnsName www.example.com
Resolve-DnsName www.example.com -Server 8.8.8.8
Get-DnsClientCache | Where-Object Entry -like '*example.com*'
# macOS and Linux
getent hosts www.example.com
dig @8.8.8.8 www.example.comThe two answers should now match, and a cached entry (if present) should show the new address with a fresh TTL. Then try the application that was failing. If it still uses the old address while the command line is right, go back to the browser or application cache, and restart it. On Linux, resolvectl statistics should show hits and misses changing as you test.
Notes
- Do not flush as a first reflex. If the server returns the wrong answer, a flush costs you nothing but achieves nothing, and hides the real problem.
- Ping is not a DNS test. It uses the full resolver path (hosts file, cache, then DNS) and then tests reachability. Use
Resolve-DnsName,nslookupordigto test DNS alone. - Short names and search suffixes.
nslookup server1may append a DNS suffix before querying (Microsoft documents that a name without a trailing period gets the default DNS domain appended). Type the fully qualified name, with a trailing dot if you want to be sure no suffix is added. - Negative answers are cached too. A “name does not exist” can outlive the moment you create the record. Microsoft says
ipconfig /flushdnsdiscards negative cache entries as well. Unbound hasflush_negativefor the same reason. - Two answers can both be right. A name with several A records, or one that returns different addresses by location or load balancer, will legitimately change between lookups.
- VPNs and split DNS. A VPN client often installs its own resolver for some domains. If an internal name fails only off the VPN (or the reverse), compare the server shown by nslookup in each state before touching any cache.
- Sources: Microsoft Learn: ipconfig, Clear-DnsClientCache, Get-DnsClientCache, Resolve-DnsName, nslookup. Apple: Reset the DNS cache in macOS (archived). systemd: resolvectl. Others: nscd(8), dnsmasq manual, unbound-control.
Still resolving to the wrong place? Post the output of nslookup or dig against both your server and a public one (hide anything private) in The Patch Panel and we will work through it. The best answer earns points on Top of the Stack.