systemd-resolved stub resolver vs NetworkManager direct resolv.conf management
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?
redhat