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

By Greg Nowak. Updated 11 September 2026.

A website has moved, but someone still sees the old server. An API works from your laptop but fails from a background job. During a migration, these differences can leave a business owner or agency team wondering whether the change actually worked.

Flushing Ubuntu’s DNS cache can help when the machine has saved an outdated answer. The useful next step is to establish where that answer came from and test the affected service again. Here is a practical sequence you can run yourself or hand to the person managing your server.

The quick command: flush systemd-resolved

On an Ubuntu machine using systemd-resolved, run:

sudo resolvectl flush-caches

Then query the affected hostname without using that resolver’s DNS cache:

resolvectl --cache=no query example.com

Replace example.com with the exact hostname causing trouble, such as your website or API endpoint. These commands are documented in the Ubuntu 26.04 resolvectl manual. They cannot clear an answer cached by your router, company DNS server or hosting provider.

If the command is missing or the service is unavailable, identify the resolver before installing anything. A minimal server or container may have no local DNS cache to flush.

Find out which resolver the application uses

Start with these checks:

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

The service check reports states in the order listed. An active service is a clue; it does not prove the failing application uses it.

A nameserver of 127.0.0.53 points to the systemd DNS stub. There is also an easily missed distinction: /run/systemd/resolve/stub-resolv.conf directs DNS clients through resolved, while /run/systemd/resolve/resolv.conf lists upstream servers that clients reading that file can contact directly. The systemd-resolved manual explains these modes.

Check /etc/hosts for an old mapping, too. The hosts: line controls the lookup sources and order for applications using Linux’s Name Service Switch. Browsers and applications with their own resolvers can follow a different path.

Clear the relevant cache

systemd-resolved: inspect after flushing

resolvectl statistics
resolvectl show-cache

Both Ubuntu 24.04 and 26.04 provide these inspection commands; show-cache appears in the Ubuntu 24.04 manual. Background traffic can refill the cache immediately, so a non-empty cache does not mean flushing failed. Compare the returned record with the expected value.

nscd: invalidate host lookups

If nscd is involved, clear its hosts database:

sudo nscd -i hosts

This uses the documented database invalidation option, leaving its other databases alone.

dnsmasq: target the correct instance

For a resolver managed by the dnsmasq.service unit:

sudo systemctl kill --signal=HUP dnsmasq.service

Despite the command’s name, HUP tells dnsmasq to clear its cache and reload host-related files. It does not reload the main configuration. It can also invoke DHCP lease scripts, as described in the dnsmasq manual. Confirm the instance and its responsibilities first, especially when a network manager or virtualisation tool owns it.

Verify the DNS answer and the actual service

For a public website, compare the authoritative DNS answer with what the affected machine receives. Find the zone’s nameservers, then query them directly:

dig +short NS example.com
dig @ns1.example.net www.example.com A +norecurse
dig @ns1.example.net www.example.com AAAA +norecurse

Replace the domain, hostname and nameserver with real values. Use the nameservers for the zone containing the record, including any delegated subdomain. Check each authoritative server for consistency. Keep the full output so you can see the status and the aa flag indicating an authoritative answer.

Check both IPv4 (A) and IPv6 (AAAA): an unchanged IPv6 record can leave some visitors reaching the old destination. If the answer contains a CNAME, check its target too. For email routing, query MX and the addresses of the mail hosts it names.

Next, compare the local resolver and the Linux application lookup path:

resolvectl --cache=no query www.example.com
getent ahosts www.example.com

Finally, repeat the failing action from the same machine, container and network: load the website, call the API or test mail delivery. Confirm the intended deployment or backend through application output or logs. A correct address alone does not prove that TLS, routing and the application are working.

When the old answer keeps coming back

If authoritative DNS is correct but your resolver differs, an upstream cache may still hold the previous answer until its TTL expires. Lowering the TTL now does not shorten the lifetime already assigned to a cached answer. A previous “name does not exist” response can also be cached.

If only one environment fails, inspect VPN DNS routing, container settings, browser secure DNS, application caches and reused connections. Record the hostname, expected value, observed answer, resolver and test time. That gives your hosting provider or agency something concrete to investigate.

For the next migration, agree on DNS ownership, verification steps and rollback responsibility before the change. If coordinating those details is slowing your team down, talk to Greg about managing your next technical cutover.

Related on GrN.dk

• Cloudflare Service Keys Stop in September: Find Every Caller
• Cloudflare Service Keys: Audit Old Automation Before September 30
• Before You Buy a GPU: Test Your Team’s Local AI Workload

Need help with this kind of work?

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

Sources

• Ubuntu 26.04 LTS: resolvectl manual
• Ubuntu 24.04 LTS: resolvectl manual
• Ubuntu 26.04 LTS: systemd-resolved manual
• dnsmasq official manual
• Ubuntu 24.04 LTS: nscd manual