When a domain cutover still points to the old IP, people often jump straight to 'flush DNS and try again.' On Ubuntu, that is sometimes correct, but on a real server or agency laptop it is only one part of the check. As of Ubuntu 26.04 LTS and 24.04 LTS, most systems use systemd-resolved and the standard command is resolvectl. Some estates still run nscd or dnsmasq, and application-level caching, VPN DNS, or /etc/hosts can make a local flush look ineffective. If you are responsible for a website launch, mail migration, or API move, the job is not just clearing a cache. It is identifying the resolver that is actually answering queries, clearing the right layer, and verifying the result from the same machine or network path that matters.
The Fast Answer for Most Ubuntu Systems
On current Ubuntu releases that use systemd-resolved, the core command is:
sudo resolvectl flush-cachesUseful companion checks are:
resolvectl status
resolvectl statistics
resolvectl --cache=no query example.comresolvectl status shows which DNS servers and search domains are active. resolvectl statistics helps confirm whether the local cache is even being hit. resolvectl --cache=no query example.com forces a network lookup instead of using the local cache, which is the quickest way to tell whether the stale answer is local or upstream. On Ubuntu 26.04 LTS, resolvectl show-cache is also available if you need to inspect what is stored locally. If your team still has older 20.04-era notes that use systemd-resolve, update them when you next touch the runbook. Current Ubuntu documentation standardizes on resolvectl.
First Check Which Resolver Is Actually Caching
Current Ubuntu documentation for systemd-resolved notes that it exposes a local DNS stub on 127.0.0.53. In practice, that means many hosts are not talking directly to the upstream DNS servers you expect. Before you flush anything, confirm which component is in the path:
ls -l /etc/resolv.conf
resolvectl status
systemctl is-active systemd-resolved nscd dnsmasqIf /etc/resolv.conf points to /run/systemd/resolve/stub-resolv.conf or lists 127.0.0.53, systemd-resolved is probably your active local resolver. If nscd or dnsmasq is active, either may be the layer you need to clear instead. This matters in real operations work because a flush against the wrong service creates the false impression that DNS is still broken when the wrong cache was tested.
Flush the Right Cache
For systemd-resolved: use sudo resolvectl flush-caches. Current systemd documentation also notes that caches are normally flushed automatically when the host's network configuration changes, so manual flushing is most useful after a DNS cutover, after moving between networks or VPNs, or when you are debugging stubborn local state.
For nscd: invalidate the hosts table explicitly:
sudo nscd -i hostsThat tells nscd to forget cached host lookups, which is the layer that matters for A and AAAA record changes on a host using nscd.
For dnsmasq: its manpage states that a SIGHUP clears the cache and reloads related host data. On managed servers, use the service's documented reload path rather than improvising signals during an incident. The important point is that flushing systemd-resolved will not clear dnsmasq if dnsmasq is the cache actually answering the query.
Verify the Result Instead of Guessing
A flush is only useful if you verify from the same machine that had the problem. A practical sequence looks like this:
- Confirm the DNS record is correct in your DNS provider or the authoritative zone.
- Flush the local cache layer that is actually active on the Ubuntu host.
- Run a fresh lookup that bypasses the local cache, such as
resolvectl --cache=no query example.com. - Test the real dependency that matters, such as the site, mail flow, webhook destination, or API client.
This is the difference between a useful operational check and random command-pasting in chat. If your production app still points at the old address after a clean network query, the problem may be upstream TTL, split DNS, a container-specific resolver, or an application cache rather than Ubuntu's local DNS cache.
When Flushing Does Not Fix It
Several common issues survive a local cache flush:
/etc/hostsoverrides that force a local answer.- VPN or office network split-DNS rules.
- Browser or application-level DNS caching.
- Containers or VMs using a resolver that is different from the host.
- Authoritative DNS records or TTL expectations that have not actually caught up yet.
If you are supporting a client launch, mail migration, or infrastructure change, this is why a good runbook separates 'flush the host cache' from 'verify authoritative DNS' and 'test from the real runtime path.' It saves time, and it stops teams from treating every DNS issue as a local Ubuntu problem when it often is not.
Need Practical Help With Ops and Delivery?
If your team has inherited fragile server notes, partial runbooks, and recurring launch-day DNS confusion, I help turn that into clearer operating procedures and calmer delivery. Talk to Greg about practical technical operations support.
Need help with this kind of work?
Talk to Greg about practical technical operations support Get in touch with Greg.