/etc/resolv.conf symlink behavior when transitioning from systemd-resolved
0 reputation · 06 Jul 2020, 19:36 UTC
0 reputation · 06 Jul 2020, 19:36 UTC
In Debian GNU/Linux, systemd-resolved provides a local DNS caching stub listener. By default, this configuration often relies on a symbolic link from /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf to ensure the system uses the local stub listener for name resolution.
When moving from this managed state to a traditional static DNS configuration, the persistence of the symlink can lead to resolution failures or the overwriting of manual edits if the service remains active or partially configured.
Given the dependency between the network manager and the systemd-resolved service, what is the recommended method to ensure a clean transition to a static /etc/resolv.conf file without causing temporary resolution outages? Does the behavior differ between the stable and testing branches regarding the default state of this symlink?
33275 reputation · 07 Jul 2020, 00:44 UTC
To transition from systemd-resolved to a static DNS configuration without causing resolution outages, you must replace the symbolic link with a physical file before disabling the service. If you disable the service while the symlink to the stub resolver (127.0.0.53) remains, all DNS queries will fail because the listener is no longer active.
/etc/resolv.conf.static) containing your desired nameservers.
nameserver 8.8.8.8
nameserver 1.1.1.1
mv ensures the transition is nearly instantaneous for the system.
sudo rm /etc/resolv.conf
sudo mv /etc/resolv.conf.static /etc/resolv.conf
systemd-resolved to prevent it from attempting to manage the network configuration or recreating the link during updates.
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo systemctl mask systemd-resolved
The following behavior is typical for Debian-based systems, though specific implementation may vary based on whether NetworkManager or resolvconf is also installed:
/run/systemd/resolve/stub-resolv.conf, the system continues to send queries to 127.0.0.53, which will now be unresponsive.systemd-resolved is active, it manages the target of the symlink. If you manually edit the symlinked file, changes are volatile and will be overwritten by the daemon.systemd-resolved may vary depending on the desktop environment selected during installation.Verify the transition with these commands:
ls -l /etc/resolv.conf (Should show a regular file, not a → link).dig google.com or getent hosts google.com.Diagnostic Detail Needed: Are you using NetworkManager to manage your interfaces? If so, you may need to set dns=none in /etc/NetworkManager/NetworkManager.conf to prevent it from overwriting your static /etc/resolv.conf.
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 07 Jul 2020, 06:41 UTC
When removing the /etc/resolv.conf symlink while systemd-resolved is still active, DNS queries may fail briefly because the stub resolver at 127.0.0.53 becomes unreachable before the static file takes effect. A critical detail is that Debian stable typically defaults to the symlink, whereas testing/unstable may vary with installer version, so always confirm the current state with readlink /etc/resolv.conf before transitioning.