systemd‑resolved’s DNS Cache Stale After a Router Update: My One‑Command Fix

I was staring at a blinking screen of a freshly flashed router when I realized the whole LAN had lost its DNS mojo. I could ping 192.168.1.1 fine, but curl example.com slammed back with “Could not resolve host”. No amount of dig or nslookup helped until I dug into systemd‑resolved.

Why systemd‑resolved Holds on to Old DNS

systemd‑resolved is the default resolver on most recent distros. It keeps a cache of answers to cut down on DNS traffic and speed things up. The cache is keyed by the DNS server that answered and the TTL that server advertised. When a router’s firmware changes, its DHCP server may hand out a new DNS IP or a new list of servers. systemd‑resolved will keep the old server in memory until it gets a fresh lease or the cache expires. If the new server is unreachable, all lookups die.

The cache never refreshes automatically on a DHCP renewal, which is why you often see “stale after router update” symptoms.

Spotting the Problem

The first thing I do is check which servers systemd‑resolved is actually using.

$ systemd-resolve --status | grep -A4 'DNS Servers'
DNS Servers: 192.168.1.1
DNS Servers: 192.168.1.2

If those IPs no longer belong to your router, you’re looking at stale state. A quick ping tells you if the server is reachable.

$ ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

A timeout confirms the server is dead.

One‑Command Fix

The simplest way to get back online is to restart the resolver. It wipes the cache, re‑reads /etc/systemd/resolved.conf, and, if your interface is managed by systemd-networkd, it triggers a DHCP renewal to fetch the latest DNS servers.

sudo systemctl restart systemd-resolved

That single line does the heavy lifting:

Flushes the cache – all stored answers are discarded.
Re‑initializes the service – it re‑reads /etc/systemd/resolved.conf and any runtime settings.
Triggers a DHCP renewal – if the interface is managed by systemd-networkd, the service will request a new lease, pulling the latest DNS servers from the router.

After the restart, a quick systemd-resolve --status shows the updated DNS servers, and curl works again.

Alternatives and Trade‑offs

Method	Command	When to use	Caveats
Flush cache only	`systemd-resolve --flush-caches`	You know the DNS servers are correct but the cache is stale.	Does not update the server list if DHCP changed.
Restart network manager	`sudo systemctl restart NetworkManager`	If you’re using NetworkManager instead of `systemd-networkd`.	May reset VPNs or other connections.
Renew DHCP lease	`sudo dhclient -r && sudo dhclient`	You want a fresh lease without touching the resolver.	Requires `dhclient` and may interfere with other DHCP clients.

Restarting systemd-resolved is the most reliable one‑stop fix because it covers both cache and server list changes.

Security Angle

systemd‑resolved supports DNS over TLS (DoT) and DNS over HTTPS (DoH). When you restart the service, it also re‑establishes any encrypted connections. If you’re using DoT, make sure /etc/systemd/resolved.conf contains:

[Resolve]
DNS=1.1.1.1
FallbackDNS=1.0.0.1
DNSOverTLS=yes

Restarting the service will pick up the new TLS settings. This is a good moment to audit your resolver configuration for unwanted upstreams or insecure defaults.

Automating the Fix

If router firmware updates happen often, you can let systemd handle it automatically.

Drop‑in for `systemd-networkd`

Create /etc/systemd/networkd.conf.d/10-dns-reload.conf:

[Match]
Name=eth0

[Network]
DHCP

This tells systemd-networkd to request a new lease whenever the network interface comes up, which in turn forces systemd-resolved to refresh its DNS list.