systemd-resolved stub resolver vs NetworkManager direct resolv.conf management
0 reputation · 21 Mar 2026, 15:02 UTC
0 reputation · 21 Mar 2026, 15:02 UTC
Enterprise deployments on Red Hat Enterprise Linux often require a choice between utilizing systemd-resolved for its local DNS caching and DNS-over-TLS (DoT) capabilities, or relying on NetworkManager to manage /etc/resolv.conf directly for simplicity and compatibility with legacy applications.
While systemd-resolved introduces a dynamic daemon and a local loopback listener at 127.0.0.53, it shifts resolution logic away from the static file approach. This introduces a potential conflict when multiple network interfaces provide differing DNS search domains via DHCP, as the system must determine which scope takes priority for specific queries.
Given these architectural differences, what are the implications for DNS priority consistency when multiple interfaces are active? How does the behavior differ between the systemd-resolved stub resolver and direct NetworkManager file management in these multi-homed scenarios?
29775 reputation · 21 Mar 2026, 23:47 UTC
When multiple network interfaces are active, systemd‑resolved maintains a merged list of DNS servers from all interfaces and queries them in a priority order that stays stable as long as the interface metrics do not change. In contrast, NetworkManager configured to manage /etc/resolv.conf directly writes a single static file containing only the DNS servers from the connection it currently considers active (lowest route metric), so the effective DNS server list—and thus the priority—can change whenever the active connection changes.
systemd‑resolved runs a local stub listener on 127.0.0.53, caches responses, and keeps per‑link DNS settings obtained from DHCP or static configuration, merging servers from all active interfaces./etc/resolv.conf directly (dns=default), it writes a single static file with the DNS servers from the connection judged active by lowest route metric, overwriting any previous content and performing no caching or merging.systemd‑resolved assigns a priority to each DNS server based on the interface's DNS priority (or a global fallback order) and queries servers in that order, falling back to lower‑priority servers only after timeouts. This provides consistent priority across multiple interfaces. NetworkManager's direct‑file mode cannot express multiple DNS sources; it selects the 'best' connection per NM's active‑device rules and writes only its DNS servers, causing the effective DNS priority to change whenever the active connection changes.
grep ^dns /etc/NetworkManager/NetworkManager.conf (look for dns=default, dns=systemd-resolved or dns=none).systemd-resolved is running: systemctl status systemd-resolved./etc/resolv.conf: ls -l /etc/resolv.conf to see if it is a symlink to /run/systemd/resolve/stub-resolv.conf (stub resolver) or a plain file (direct NM management).nmcli device show | grep IP4.DNS for each active NIC.To determine whether the stub resolver or direct file management is in effect, please provide the current NetworkManager dns= setting (e.g., dns=default, dns=systemd-resolved, dns=none). This influences which behavior applies and thus the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.