How to Flush the DNS Cache on Linux: systemd-resolved, nscd, dnsmasq and BIND

CodexFuse Team · 2026-11-04T10:59:54.821Z · 11 min read min read

Linux has no single DNS cache — detect your resolver stack first, then flush systemd-resolved, nscd, dnsmasq or BIND with the right command and verify it worked.

Learning how to flush the DNS cache on Linux starts with a surprise: unlike Windows or macOS, Linux has no single system-wide DNS cache to flush. Whether resolvectl flush-caches works, does nothing, or errors with "command not found" depends entirely on which DNS caching service — systemd-resolved, nscd, dnsmasq, or BIND — your distribution actually runs. This guide shows you how to detect your resolver stack first, then run the exact flush command for each one, and finally verify the flush really worked. Every command below is sourced from guides and man pages fetched this week, and the "nothing to flush" case was confirmed on a live Ubuntu 24.04 box during this session. If you administer servers, you may also want the companion VPS hosting guide — DNS cache flushes are one of the routine housekeeping tasks of running a virtual server.

What is the fastest way to flush DNS on Linux?

Detect your resolver first, then flush it. Run sudo lsof -i :53 -S to see which process owns DNS port 53; on most modern desktops and servers that will be systemd-resolved, and the flush is a single command:

1. Detect: run sudo lsof -i :53 -S. If the process column says systemd-resolved, step 2 applies. If it says dnsmasq, nscd, or named, jump to the matching section below.
2. Flush: run sudo resolvectl flush-caches. The command prints no output on success — that is normal.
3. Verify: run sudo resolvectl statistics and check that "Current Cache Size" reads 0.
4. Browser check: if the page still resolves to the old address, clear the browser's own DNS cache too (see the Chrome steps below) — the system flush does not touch it.

The rest of this guide covers the full picture: the systems where there is nothing to flush at all, the nscd and dnsmasq and BIND paths, and how to prove the flush worked instead of trusting silence. For inspecting records before and after a flush, the dig and dog comparison shows the two lookup tools side by side.

Do you even have a DNS cache on Linux?

Probably not at the OS level. The fresh linuxize guide (updated 2026-10-08) states it plainly: on Linux there is no OS-level DNS caching unless a caching service such as systemd-resolved, dnsmasq, or nscd is installed and running. The dnsrobot guide (late-October 2026) adds the corollary: some Linux systems — Debian by default, minimal installs — do not cache at all.

If no caching service runs, there is nothing to flush at the system level: every lookup already goes straight to the DNS server, and your troubleshooting belongs in the browser cache instead (dnsrobot). This was verified live during this session on a minimal Ubuntu 24.04.5 LTS container: resolvectl returned "command not found", none of systemd-resolve, nscd, dnsmasq or rndc were installed, systemd-resolved was inactive, and sudo lsof -i :53 -S printed nothing. That box is the textbook "nothing to flush" case.

How do you find out which resolver your Linux box uses?

Check which process listens on DNS port 53 before you flush anything. phoenixnap's guide (published 2025-12-16) recommends sudo lsof -i :53 -S, which shows all the services listening on port 53 — the server port reserved for DNS — including the DNS resolver service.

How do you flush the systemd-resolved cache?

Run sudo resolvectl flush-caches. This is the flush for Ubuntu 22.04 and newer, Fedora 33 and newer, and most other modern distributions — phoenixnap notes that Ubuntu has used resolvectl since 22.04, replacing systemd-resolve, and that Ubuntu has defaulted to systemd-resolved since 18.04.

The resolvectl(1) man page (freedesktop, fetched fresh) describes the command verbatim: flush-caches "flushes all DNS resource record caches the service maintains locally. This is mostly equivalent to sending the SIGUSR2 to the systemd-resolved service." The man page also notes the command was added in systemd v239 — which is why older guides use the old name.

About that old name: you may still see systemd-resolve --flush-caches in older tutorials. The linuxize guide warns that this command was removed in newer systemd releases, and on Ubuntu 26.04 it fails with "command not found". The dnsrobot guide pins the old form to "older systemd (before version 239, e.g. Ubuntu 18.04)". If you are stuck on a transitional system, the signal equivalent still works: sudo killall -USR2 systemd-resolved flushes the cache, which you can confirm in the logs with sudo journalctl -r -u systemd-resolved (idroot).

sudo resolvectl flush-caches
sudo resolvectl statistics

The flush itself prints nothing. The verify step is resolvectl statistics: idroot's example output shows "Current Cache Size: 0" after the flush while "Cache Hits: 76" and "Cache Misses: 51" remain populated. linuxize confirms the semantics: after a flush, Current Cache Size drops to 0, while the Hits and Misses counters are not reset. One quirk from the linuxize troubleshooting notes: on some systems resolvectl statistics needs root privileges — if you see an InteractiveAuthenticationRequired error, rerun it with sudo.

How do you clear the nscd cache?

Invalidate the hosts table with sudo nscd -i hosts, or restart the service to clear every table. The linuxize guide's quick reference gives the single-table form: nscd -i hosts, noting that the -i option invalidates a single cache table, in this case hosts.

sudo nscd -i hosts
sudo systemctl restart nscd
sudo nscd -g

Restarting the service (sudo systemctl restart nscd, or sudo service nscd restart on SysVinit systems, or sudo /etc/init.d/nscd restart on legacy ones — linuxize, phoenixnap, idroot) clears all nscd caches at once. To check the state afterwards, idroot suggests sudo nscd -g, which displays the current statistics of the nscd caches. nscd belongs to older RHEL-based systems — linuxize describes it as "a caching daemon found on older RHEL-based systems and some other distributions", and phoenixnap calls it standard in "older or more traditional Linux distributions like RHEL, CentOS, and OpenSUSE". Confirm it is the active service with systemctl status nscd before flushing.

How do you flush dnsmasq's cache?

Send a HUP signal: sudo killall -HUP dnsmasq. Per the linuxize guide, when dnsmasq receives the HUP signal it empties its cache and rereads /etc/hosts — no restart required. A full sudo systemctl restart dnsmasq also clears the cache; both do the job, the HUP form just avoids restarting the process.

sudo killall -HUP dnsmasq
sudo systemctl restart dnsmasq

The HUP form has one useful edge case, also from linuxize: on desktops where NetworkManager runs its own dnsmasq instance (dns=dnsmasq in NetworkManager.conf), there is no dnsmasq.service to restart — but killall -HUP dnsmasq still clears the cache. To watch it happen, idroot suggests sudo journalctl -u dnsmasq or grepping /var/log/syslog. A sense of scale from the dnsrobot guide (late-October 2026): many home routers run dnsmasq, which caches 150 names by default, while OpenWrt raises that to 1,000 — so on router-adjacent boxes the flush is a bigger event than on a laptop.

How do you flush a BIND server's cache?

Run sudo rndc flush. This was verified against the official BIND 9 9.20.8 man pages (fetched fresh this session), whose rndc section reads verbatim: "flush — This command flushes the server's cache." The same man pages document a surgical alternative: "flushname name [view] — This command flushes the given name from the view's DNS cache", used as sudo rndc flushname phoenixnap.com (phoenixnap).

sudo rndc flush
sudo rndc flushname example.com

Detect the service first with systemctl status named or systemctl status bind9 (idroot) — the service name differs between RHEL-family and Debian-family distributions. And one warning worth one sentence: some guides show sudo rndc flushall, but the BIND 9.20.8 man pages list only flush, flushname and flushtree — flushall is not a real rndc command.

How do you verify the DNS cache was actually flushed?

Check the cache-size counter, then confirm the lookup returns the new record. For systemd-resolved, sudo resolvectl statistics after the flush should show "Current Cache Size: 0" while the Hits and Misses counters keep their old values (idroot's annotated example: Cache Hits 76, Cache Misses 51, Current Cache Size 0). If the counter still shows entries, you flushed the wrong service — go back to the detection step.

Then do a live before-and-after: run dig on the record you expect to have changed, flush, run dig again, and compare. (dig and nslookup are both present even on minimal installs — they were the only DNS tools on the test box this session.) The dig and dog side-by-side guide covers the exact syntax if you want the modern alternative.

The cache is empty but the site still shows the old address — now what?

Clear the browser's own DNS cache next, because the system flush never touches it. The linuxize guide notes that Chrome keeps its own DNS cache, separate from the operating system: open chrome://net-internals/#dns and click "Clear host cache", then open chrome://net-internals/#sockets and click "Flush socket pools". The third step matters, because Chrome reuses open connections — without it the browser can keep talking to the old IP address until those connections close, even though the host cache is empty. In Firefox the equivalent is about:networking#dns and its "Clear DNS Cache" button.

If the browser cache is also clean and the record is still stale, you are waiting on propagation, not your own cache. Records you changed recently still sit inside their DNS TTL window on every resolver between you and the authoritative server — no amount of local flushing can shorten that. Re-check the record after the TTL you set has elapsed.

Sources

Facts in this guide were fetched 2026-11-04 from: the linuxize guide "How to Flush DNS Cache on Linux, Windows, macOS, and Chrome" (updated 2026-10-08); the dnsrobot guide "How to Flush DNS: Windows, Mac, Linux, Fedora & Chrome" (late-October 2026); the phoenixnap knowledge base article "How to Flush DNS Cache in macOS, Windows, & Linux" (published 2025-12-16); the idroot guide "How To Clear DNS Cache on Linux" (crawled 2026-11-04); the resolvectl(1) man page at freedesktop.org; and the BIND 9 9.20.8 rndc man pages at bind9.readthedocs.io. The "nothing to flush" case was verified on this session's Ubuntu 24.04.5 LTS box with live command output.

Frequently Asked Questions

Is there a DNS cache on Ubuntu by default?

On a standard Ubuntu desktop or server install, yes: systemd-resolved has been the default resolver since Ubuntu 18.04 (phoenixnap), and it maintains a cache you flush with sudo resolvectl flush-caches. On minimal installs — including many Docker containers and trimmed server images — the systemd-resolved service may be absent entirely, in which case there is no local cache to flush (verified on an Ubuntu 24.04.5 minimal box this session: resolvectl was not even installed).

Why does "systemd-resolve --flush-caches" say command not found?

Because systemd-resolve is the pre-v239 command name and was removed in newer systemd releases — on Ubuntu 26.04 it fails with exactly that error (linuxize). The current command is sudo resolvectl flush-caches (phoenixnap notes Ubuntu made the switch in 22.04). If your system is too old for resolvectl, the signal form sudo killall -USR2 systemd-resolved is the man-page-equivalent fallback.

Does flushing the DNS cache delete my browsing history?

No. Flushing deletes only the stored answers for names your machine looked up recently, so the next visit asks DNS again and gets the current address (dnsrobot). History, cookies, saved logins and cached page files are untouched. If you want the browser's stored data gone too, that is a separate "clear browsing data" step.

Do I need to restart the browser after flushing DNS?

A restart is not required if you clear the browser's own DNS cache properly. In Chrome, clear the host cache at chrome://net-internals/#dns and then flush the socket pools at chrome://net-internals/#sockets — linuxize specifically warns that without the second step, reused connections can keep talking to the old IP address.

How often should I flush the DNS cache on Linux?

Rarely. Flushes are only useful when a DNS record changed and your machine still holds the old answer inside its TTL window. If your system has no caching service at all — common on Debian-by-default and minimal installs (dnsrobot) — there is nothing to flush and flushing on a schedule is pointless. The one legitimate trigger is after you change a zone and need the new records immediately; pair the flush with the resolvectl statistics verify step so you know it took effect.