Fixing systemd-resolved Conflicts With Manually Configured DNS
Why editing /etc/resolv.conf directly often silently fails to change actual DNS behavior on systemd-resolved systems, and the correct way to override DNS settings that actually persists.
The most common systemd-resolved complaint isn’t a bug — it’s that /etc/resolv.conf on a resolved-managed system is frequently a symlink to a resolved-generated stub file, and directly editing it (or a tool overwriting it, or a script assuming it’s a plain static file) either has no lasting effect, gets silently reverted, or produces confusing, inconsistent DNS behavior depending on exactly which resolution path a given piece of software actually uses.
Confirming resolved is actually in the picture
Before troubleshooting further, confirm whether systemd-resolved is actually managing DNS on this system at all — not every distribution enables it by default, and its presence changes the entire troubleshooting approach:
systemctl status systemd-resolved
readlink -f /etc/resolv.confIf /etc/resolv.conf resolves to something under /run/systemd/resolve/, resolved is actively managing it, and directly editing that file is pointless — it’s regenerated by resolved itself and any manual edits will be overwritten on the next regeneration, which happens routinely (network state changes, resolved restarts, and so on).
Why “it looked like it worked at first” happens
A common, confusing pattern: someone edits /etc/resolv.conf directly, DNS resolution appears to change immediately (because some caching layer or the specific command they tested happened to pick up the edit), and then hours or days later DNS behavior silently reverts with no obvious trigger — because resolved regenerated the file during some routine event, silently discarding the manual edit. This looks like an intermittent, unexplainable DNS bug when it’s actually completely deterministic: the manual edit was never a durable configuration change in the first place, just a temporary state that lasted until the next regeneration.
The correct way to override DNS servers persistently
resolved’s actual configuration lives in /etc/systemd/resolved.conf (plus drop-in files under /etc/systemd/resolved.conf.d/), and changes there survive regeneration because they are the source resolved regenerates from, rather than being downstream of it:
# /etc/systemd/resolved.conf.d/override.conf
[Resolve]
DNS=1.1.1.1 9.9.9.9
DNSSEC=yes
Domains=~.DNS= sets the actual upstream resolvers resolved will query. Domains=~. (the tilde-dot syntax) marks these servers as the default route for all DNS queries, which matters specifically when multiple network interfaces each have their own DNS configuration and you want one set of servers to take priority globally rather than being scoped to just one interface.
After editing, restart the service for the change to take effect:
systemctl restart systemd-resolvedPer-interface DNS conflicts: when DHCP keeps overwriting your settings
A distinct but related common problem: a DHCP client (NetworkManager, systemd-networkd, or a distribution’s own DHCP handling) is pushing DNS servers from the DHCP lease into resolved per-interface, and those DHCP-supplied servers keep taking effect even after you’ve configured different servers globally, because per-interface DNS settings can take precedence over global configuration depending on how resolved is combining them.
resolvectl statusThis command is the actual diagnostic tool for this class of problem — it shows, per network interface, exactly which DNS servers resolved currently has configured for that interface, distinct from the global configuration in resolved.conf. If an interface shows DHCP-supplied DNS servers you didn’t want, the fix depends on which network management tool is actually supplying them: for NetworkManager-managed interfaces, setting ignore-auto-dns=yes on that specific connection profile prevents NetworkManager from pushing DHCP-supplied DNS into resolved for it, letting your global resolved.conf settings actually take effect uncontested.
Checking whether resolution is actually going through resolved at all
Some applications and libraries bypass resolved/NSS entirely and perform DNS resolution using their own bundled resolver logic, hardcoded servers, or a different resolution path altogether — meaning resolved being correctly configured doesn’t guarantee every piece of software on the system is actually using it. Confirming that ordinary system-level resolution (via getent, which goes through the standard NSS/glibc resolution path most software actually uses) reflects your resolved configuration is a useful sanity check before assuming a resolved config change should have fixed a specific application’s DNS behavior:
getent hosts example.com
resolvectl query example.comIf resolvectl query (talking directly to resolved) returns correct results but getent (going through the standard NSS chain) doesn’t, that points at an NSS configuration issue (/etc/nsswitch.conf’s hosts: line not actually routing through resolved at all) rather than a resolved configuration problem per se.
The general principle
The recurring theme across all of these scenarios is the same: on a resolved-managed system, /etc/resolv.conf is downstream output, not configuration input — treating it as editable configuration is the root cause of most confusing, seemingly-intermittent DNS behavior on these systems. resolved.conf (and per-connection settings in whatever network manager is supplying interface-level DNS) is the actual configuration surface, and resolvectl status is the tool that shows what resolved is actually doing right now, rather than inferring it indirectly from a file that’s just a generated artifact.