By Greg Nowak. Updated 12 November 2026.
A website has moved, but a colleague still reaches the old server. An API works from your laptop and fails from a background job. During a migration, those differences make it difficult to know whether the change is ready to sign off.
Flushing Ubuntu’s DNS cache helps when the machine has stored an outdated answer. It is one step in a useful troubleshooting sequence: identify the resolver, clear the relevant cache, then test the affected service. Here is what to run and what to ask your hosting provider or agency to verify.
Flush Ubuntu’s DNS cache with resolvectl
If the machine uses systemd-resolved, run:
sudo resolvectl flush-caches
resolvectl --cache=no query www.example.comReplace www.example.com with the affected hostname. The first command clears resolved’s local DNS caches; the second queries without using that cache. It can still receive a cached answer from an upstream resolver.
No reboot is needed. A successful flush normally produces no output. For inspection, use:
resolvectl statistics
resolvectl show-cacheshow-cache requires systemd 254 or later; check man resolvectl on older installations. Background traffic can refill the cache immediately. The important check is the returned answer, rather than keeping the cache empty. These commands are documented in the Ubuntu resolvectl manual.
Check which resolver the application actually uses
If the command is missing or the service is unavailable, investigate before installing anything. Minimal servers and containers may have no local DNS cache.
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status
systemctl is-active systemd-resolved nscd dnsmasq
grep '^hosts:' /etc/nsswitch.confThe service check reports states in the order listed. An active service is a clue, not proof that the failing application uses it.
A nameserver of 127.0.0.53 points to resolved’s local DNS stub. An /etc/resolv.conf symlink to /run/systemd/resolve/stub-resolv.conf sends DNS clients through it. A link to /run/systemd/resolve/resolv.conf instead exposes upstream servers, allowing clients reading that file to bypass resolved. The systemd-resolved manual explains the distinction.
Inspect /etc/hosts for an old address too: flushing DNS does not remove a static mapping. The hosts: line shows lookup sources and order for applications using Linux’s Name Service Switch. An application with its own resolver may follow another path.
| What you observe | Next action |
|---|---|
| The lookup uses systemd-resolved | Flush its cache and compare the answer. |
| nscd or dnsmasq serves the lookup | Clear that cache using the relevant command below. |
| System lookups are correct; one application differs | Inspect its DNS settings, cache, proxy and open connections. |
| Authoritative DNS returns the wrong record | Correct the record at the DNS provider. |
| Public DNS works; VPN users differ | Check the intended internal DNS view and routing. |
If the cache belongs to nscd or dnsmasq
Run these commands only when the relevant service handles the affected lookup.
nscd
sudo nscd -i hostsThis invalidates the hosts database while leaving its other databases alone, using the documented nscd invalidation option.
dnsmasq
For the instance managed by dnsmasq.service:
sudo systemctl kill --signal=HUP dnsmasq.serviceHUP clears its cache and reloads host-related files; it does not reload the main configuration. It can also invoke DHCP lease scripts. Confirm which instance you are targeting, especially where networking or virtualisation tools manage it. See the dnsmasq manual for the signal’s effects.
Verify the DNS answer, then the service
For a public hostname, compare the authoritative answer—the record published by the DNS provider—with the affected machine’s answer:
dig +short NS example.com
dig @ns1.example.net www.example.com A +norecurse
dig @ns1.example.net www.example.com AAAA +norecurseReplace all placeholders. Use the authoritative nameservers for the zone containing the record, including any delegated subdomain, and check each server. Keep the full response to inspect its status and the aa flag indicating an authoritative answer. The ISC dig manual documents server selection and query options.
Check IPv4 (A) and IPv6 (AAAA): a leftover IPv6 record can send some visitors to the old destination. Follow any CNAME target too. For email routing, query MX and check the addresses of the mail hosts it names.
Compare resolved with the system lookup path:
resolvectl --cache=no query www.example.com
getent ahosts www.example.comgetent exercises Name Service Switch; it does not reproduce every application’s behaviour. Repeat the failing action from the same machine, container and network. Check application output or logs to confirm the intended backend. Correct DNS alone does not establish that TLS, routing or mail delivery works.
When flushing does not fix it
An upstream resolver may retain the previous answer until its TTL expires. Lowering the published TTL now does not shorten a lifetime already assigned to a cached answer. A previous “name does not exist” response can also be cached.
If only one environment fails, check VPN DNS routing, container settings, browser secure DNS, application caches and reused connections. For private hostnames, compare against the intended internal resolver rather than public DNS.
Before escalating, record the hostname, expected value, observed answer, resolver, environment and test time. For a migration, agree who owns the DNS change, who verifies the service and who can roll it back.
If your team needs help coordinating those responsibilities, talk to Greg about managing your next technical cutover.
Related on GrN.dk
- Can’t Publish in WordPress? Fix the Invalid JSON Response Without Guesswork
- Cloudflare Service Keys: Audit Old Automation Before September 30
- NGINX 1.30 and upstream connection reuse: what to check before upgrading
Need help with this kind of work?
Talk to Greg about your next technical cutover Get in touch with Greg.
