How to Flush the DNS Cache on Ubuntu Linux

By Greg Nowak. Last updated 2026-07-10.

When a website, mail service, or API still resolves to its old address after a cutover, “flush DNS” is the familiar advice. It may be the right move, but only if the stale answer is coming from the Ubuntu machine’s local cache.

On standard Ubuntu 24.04 LTS and 26.04 LTS installations using systemd-resolved, clearing that cache takes one command. Agency laptops, inherited servers, containers, VPNs, and customised environments may have another resolver in the path. The practical job is therefore to identify the component answering the query, clear the appropriate cache, and verify the result from the runtime that matters.

The quick command for current Ubuntu systems

If the machine uses systemd-resolved, run:

sudo resolvectl flush-caches

Then request a fresh network lookup that does not use the local DNS resource-record cache:

resolvectl --cache=no query example.com

Replace example.com with the affected hostname. This bypasses the cache maintained by systemd-resolved; it does not bypass a cache at your router, VPN, company DNS server, ISP, or other upstream resolver.

Confirm which resolver is actually in use

Before changing services on a production host, inspect the resolution path:

readlink -f /etc/resolv.conf
resolvectl status
systemctl is-active systemd-resolved nscd dnsmasq
grep '^hosts:' /etc/nsswitch.conf

If /etc/resolv.conf resolves to /run/systemd/resolve/stub-resolv.conf, or contains 127.0.0.53, local DNS requests are normally passing through systemd-resolved. Its status output also shows the DNS servers and routing domains assigned globally and to each network interface. That is particularly useful when a VPN supplies DNS for only part of your namespace.

The hosts: entry in /etc/nsswitch.conf shows how normal application lookups are ordered. Remember that /etc/hosts can override an upstream DNS answer; clearing a DNS cache will not remove that mapping.

What you find	Likely answering layer	Next action
127.0.0.53 or the systemd stub file	systemd-resolved	Flush with resolvectl
nscd is active	nscd hosts cache	Invalidate the hosts table
dnsmasq is active and clients use it	dnsmasq	Send its documented HUP signal
A fresh host lookup is correct but the application is stale	Application, browser, container, or proxy	Test and clear that layer
Fresh lookups are stale across several networks	Authoritative or upstream DNS	Check the zone, TTL, and resolver path

A compact decision matrix for choosing the cache to investigate.

Flush the resolver you found

systemd-resolved:

sudo resolvectl flush-caches
resolvectl statistics

Current Ubuntu documentation notes that systemd-resolved already clears its caches when network configuration changes. Manual flushing is mainly useful during troubleshooting or immediately after a controlled DNS change. On supported 24.04 and 26.04 installations, you can also inspect locally cached records with:

resolvectl show-cache

nscd: if the Name Service Cache Daemon is installed, invalidate its hosts database:

sudo nscd -i hosts

dnsmasq: its documented SIGHUP handling clears the cache and reloads host-related files. For a systemd-managed instance, the signal can be sent with:

sudo systemctl kill --signal=HUP dnsmasq

Use your approved service procedure on a managed server. A HUP does not reload the main dnsmasq configuration file, and dnsmasq may also be providing DHCP, so do not substitute an unplanned restart during an incident.

Verify the cutover, not just the command

A successful command produces little business value unless the affected service now reaches the intended destination. Use a short verification sequence:

Check the authoritative answer. If dig is installed, identify the domain’s nameservers and query one directly:
```
dig +short NS example.com
dig @AUTHORITATIVE_NAMESERVER example.com A +noall +answer
```
Bypass the local resolved cache.
```
resolvectl --cache=no query example.com
```
Test the normal application lookup path.
```
getent ahosts example.com
```
Test the real dependency. Open the website, run the API client, exercise the webhook, or test mail delivery from the machine and network where the failure occurred.

If the authoritative answer is correct but an upstream resolver returns the old value, the previous record may remain cached until its TTL expires. Flushing the Ubuntu host cannot force that external cache to refresh early.

When flushing does not solve the problem

Check for an /etc/hosts override, split DNS supplied by a VPN, a different resolver inside a container or virtual machine, browser or application caching, and proxies that resolve names independently. Run the diagnostic from inside the affected container or application environment when possible; testing only from the host can produce a reassuring but irrelevant result.

For client launches and infrastructure changes, record the authoritative value, expected TTL, active resolver, verification commands, and rollback owner in the runbook before the change begins. That turns “try flushing DNS” into a repeatable operational check.

Make the next cutover calmer

If DNS troubleshooting is exposing incomplete runbooks, unclear ownership, or fragile delivery processes, talk to Greg about practical technical operations support.