How to Flush DNS Cache on Ubuntu Linux

When a domain keeps resolving to an old IP after a DNS change, the instinct is to flush the cache and move on. On Ubuntu, that is often the right first step, but not always the whole answer. Current Ubuntu releases usually rely on systemd-resolved, some servers still run nscd or dnsmasq, and stale answers can sit in more than one layer. For operations teams and agencies, the practical goal is simple: clear the right cache fast, verify the new answer, and avoid runbooks that only work on one machine.

The Short Answer for Most Ubuntu Systems

If the host uses systemd-resolved, the current command is:

sudo resolvectl flush-caches

To inspect resolver state before or after the flush, use:

resolvectl statistics
resolvectl status

If you want to test a lookup without relying on the local cache, query with cache disabled:

resolvectl query --cache=no example.com

On newer Ubuntu releases with newer systemd builds, resolvectl show-cache can also help when you need to inspect what is actually stored locally.

What Changed From Older Ubuntu Notes?

Older admin notes often use systemd-resolve instead:

systemd-resolve --statistics
systemd-resolve --flush-caches

That syntax still matters when you are supporting older scripts or legacy hosts, but it should not be the standard in new documentation. Canonical's Ubuntu manpages treat systemd-resolve as backward compatibility and deprecate it for current use. If you are updating team notes now, standardize on resolvectl.

Do You Even Need to Flush?

This is where most thin how-to posts stop too early. Ubuntu's systemd-resolved documentation notes that caches are normally flushed automatically when the host's network configuration changes. In practice, manual flushing is most useful when you suspect stale local state after a DNS cutover, after moving between networks or VPNs, or when a host keeps returning an answer that no longer matches the change you just made.

For a business website, mail migration, or API move, the better sequence is: confirm the authoritative DNS record is right, flush the local cache only on the systems that matter, and then verify lookups from the same network path your application or support team actually uses. That is a much better operational habit than repeatedly flushing caches and hoping the problem disappears.

If the Problem Survives the Flush

If resolvectl flush-caches succeeds but the wrong answer keeps appearing, check whether a different resolver is in play. On Ubuntu, the usual local candidates are systemd-resolved, nscd, and dnsmasq.

systemctl is-active systemd-resolved
systemctl is-active nscd
systemctl is-active dnsmasq

If nscd is active, invalidate the hosts cache explicitly:

sudo nscd -i hosts

If dnsmasq is active as a local caching layer, its own documentation says a SIGHUP clears the cache. On a managed server, that means using the service's reload path or sending that signal deliberately as part of a documented runbook, not as a guess during an outage.

Also check the things a cache flush will never fix:

/etc/hosts overrides
Split-DNS settings from VPN clients
Browser or application-level DNS behavior
Upstream TTL and propagation expectations
Container or VM networking that is using a different resolver than the host

A Better Ops Standard

If this is for a one-off laptop issue, a single command is enough. If this is for an agency, hosting estate, or in-house operations team, treat DNS cache flushing as a small operational procedure instead of a random snippet pasted into chat. The useful standard is straightforward:

Check which resolver is actually caching on the host.
Use resolvectl for current Ubuntu documentation and team scripts.
Keep legacy systemd-resolve only where older environments still depend on it.
Verify with a fresh lookup, not just by assuming the flush worked.
Document exceptions such as nscd, dnsmasq, VPN DNS, and containerized workloads.

That sounds small, but it is exactly the kind of small operational discipline that saves time during site launches, domain moves, certificate cutovers, and incident response.

Need Practical Help With This Kind of Work?

If your team has inherited server notes, one-off scripts, and brittle runbooks, I can help turn them into working operational processes that make sense across real environments. Talk to Greg about practical delivery and technical operations support.

Need help with this kind of work?

Need help turning inherited server notes into reliable runbooks and calmer technical operations? Get in touch with Greg.

Sources

Last modified

2026-04-24