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-cachesThen query the affected hostname without using that resolver’s DNS cache:
resolvectl --cache=no query example.comReplace 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.confThe 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.
| What you find | What to do next |
|---|---|
| The affected lookup uses systemd-resolved | Flush with resolvectl, then query again. |
| nscd caches the application’s host lookups | Invalidate its hosts database. |
| The application queries a dnsmasq instance | Send HUP to that specific instance. |
| Ubuntu returns the expected address; the application differs | Inspect its resolver, proxy, cache and existing connections. |
| The authoritative nameservers return the wrong record | Correct the DNS configuration before repeating local flushes. |
Clear the relevant cache
systemd-resolved: inspect after flushing
resolvectl statistics
resolvectl show-cacheBoth 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 hostsThis 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.serviceDespite 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 +norecurseReplace 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.comFinally, 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.
