How to Flush the DNS Cache on Ubuntu—and Verify the Fix

By Greg Nowak. Updated 11 August 2026.

When a website, mail service or API still points to its old address after a DNS change, flushing the cache is a sensible troubleshooting step. It is not, however, a universal fix. The stale answer may be held by Ubuntu, a VPN, a company resolver, a container, a browser or the application itself.

The reliable approach is to identify which resolver is answering, clear only the relevant cache and then test the service from the environment where the problem occurred.

The quick command for most current Ubuntu systems

Many Ubuntu 24.04 LTS and 26.04 LTS installations use systemd-resolved. If yours does, flush its local DNS resource-record cache with:

sudo resolvectl flush-caches

You can then force a query past that local cache:

resolvectl --cache=no query example.com

Replace example.com with the affected hostname. This bypasses the cache maintained by systemd-resolved; it cannot clear an old answer held by your router, VPN, company DNS server, ISP or another upstream resolver.

First confirm which resolver is in the path

Before restarting or signalling services on a production machine, inspect the local resolution setup:

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

If /etc/resolv.conf points to /run/systemd/resolve/stub-resolv.conf, or lists 127.0.0.53, DNS traffic is normally passing through systemd-resolved. Its status output shows the DNS servers and routing domains assigned globally and to each interface. This matters when a VPN provides different DNS servers for an internal domain.

The hosts: line in /etc/nsswitch.conf shows the lookup order used by normal Linux applications. Also inspect /etc/hosts: a local mapping can override DNS, and flushing a DNS cache will not remove it.

What you find	Likely source	Best next step
`127.0.0.53` or the systemd stub file	`systemd-resolved`	Use `resolvectl flush-caches`
`nscd` is active	nscd hosts cache	Invalidate its `hosts` table
`dnsmasq` is active and clients use it	dnsmasq cache	Send its documented HUP signal
Linux returns the new address but the application does not	Browser, application, proxy or container	Test and clear that specific layer
Several independent networks return the old address	Authoritative DNS or upstream caching	Check the zone, delegation and TTL

A practical decision matrix for finding the cache that is actually affecting the service.

Flush the resolver you actually found

systemd-resolved

sudo resolvectl flush-caches
resolvectl statistics

systemd-resolved normally clears its cache when network configuration changes, so routine scheduled flushing is unnecessary. Manual flushing is most useful while diagnosing a fault or immediately after a controlled DNS cutover. On Ubuntu 24.04 and 26.04, you can inspect its current cache with:

resolvectl show-cache

nscd

If the Name Service Cache Daemon is installed and active, invalidate its hosts database:

sudo nscd -i hosts

dnsmasq

A SIGHUP makes dnsmasq clear its cache and reload host-related files. For a systemd-managed service:

sudo systemctl kill --signal=HUP dnsmasq

Use the approved service procedure on a managed server. The signal does not reload dnsmasq’s main configuration file, and dnsmasq may also be handling DHCP. That makes an unplanned restart a poor substitute during an incident.

Verify the cutover rather than trusting the command

A successful cache flush only proves that a command ran. It does not prove that customers, background jobs or integrations are reaching the intended destination. Use this short verification sequence:

Check the authoritative answer. Find the domain’s nameservers, then query one directly. Replace the example nameserver with a real result from the first command.
```
dig +short NS example.com
dig @ns1.example.net example.com A +noall +answer
```
Query through systemd-resolved without its cache.
```
resolvectl --cache=no query example.com
```
Test the normal Linux application path.
```
getent ahosts example.com
```
Exercise the real dependency. Load the website, call the API, run the webhook or test mail delivery from the same machine, container and network where the failure appeared.

If the authoritative server has the new record but another resolver still returns the old one, the previous answer may remain cached until its TTL expires. Clearing the Ubuntu host cannot force that external resolver to refresh early.

When flushing still does not solve it

Look for split DNS from a VPN, a resolver inside a container or virtual machine, browser DNS caching, long-lived application connections and proxies that resolve hostnames independently. Run diagnostics inside the affected runtime whenever possible. A correct answer on the host is reassuring but irrelevant if the failing workload uses different DNS settings.

For planned migrations, record the old and new values, expected TTL, authoritative nameserver, application test, rollback owner and decision time before making the change. This turns “try flushing DNS” into an operational check that a colleague or agency partner can repeat under pressure.

Make the next cutover easier to manage

If DNS problems are exposing unclear ownership, incomplete runbooks or gaps between suppliers, talk to Greg about practical technical project support. The aim is not more process—it is a change that can be verified, explained and rolled back without guesswork.

Related on GrN.dk

Need help with this kind of work?

Talk to Greg about your next cutover Get in touch with Greg.

Sources

Last modified

2026-08-12