Understanding the Conflict
In modern Ubuntu versions, specifically 22.04 and later, the NetworkManager service integrates closely with systemd-resolved to handle network interfaces and DNS settings automatically. The file /etc/resolv.conf is no longer a static configuration file that users should edit directly. Instead, it is typically a symbolic link pointing to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf. This design ensures that when your network interface changes IP addresses or switches between Wi-Fi and Ethernet, the DNS servers update automatically without requiring manual intervention.
When you use sudo to write to /etc/resolv.conf, you are essentially breaking this automated chain. The system detects that the expected dynamic state has been compromised. Many applications, including package managers and web browsers, will fail to resolve hostnames because they cannot trust the stale or incorrect data in the manually edited file. This results in errors such as "Could not resolve host" or timeouts during software updates, which can be confusing if you were simply trying to add a custom nameserver for testing purposes.
Why Manual Editing Fails
The core issue lies in how systemd-resolved operates. It generates the content of the resolv.conf stub based on the current network configuration provided by NetworkManager. If you force-write to the file, you create a discrepancy between what the resolver expects and what is actually present. Furthermore, systemd-resolved may periodically overwrite or validate the file, leading to race conditions where your manual changes are either lost or cause the resolver to panic due to invalid syntax.
Additionally, some security modules or PAM configurations might flag direct modifications to critical system files like resolv.conf as suspicious, although the primary failure mode here is functional rather than security-related. The error message you see is usually a symptom of the application failing to connect to the DNS server specified in your broken configuration, rather than a complaint about the act of editing itself. However, the terminology "Sudo Complain" suggests that the user perceives the subsequent DNS failures as a direct rebuke from the system for using sudo improperly.
Proper Ways to Configure DNS
To correctly change DNS settings in Ubuntu 22.04, you should avoid touching /etc/resolv.conf entirely. Instead, use the graphical Network Manager settings or command-line tools designed for this purpose. For desktop users, open the Settings application, navigate to the Network section, and select the gear icon next to your active connection. Here, you can switch the IPv4 or IPv6 method to "Automatic (DHCP) addresses only" or "Manual," and then input your desired DNS servers in the designated field.
For server environments or headless systems, you can use the nmtui utility, which provides a text-based interface to modify network configurations safely. Alternatively, advanced users can edit the Netplan configuration files located in /etc/netplan/. By defining DNS servers within the YAML structure of your netplan configuration and applying it with sudo netplan apply, you ensure that systemd-resolved receives the correct instructions and regenerates the resolv.conf symlink properly. This approach maintains system integrity and prevents the resolution errors associated with manual edits.
Recovering from a Broken Configuration
If you have already modified /etc/resolv.conf and are experiencing DNS issues, you need to restore the default behavior. First, remove the manually created file using sudo rm /etc/resolv.conf. Then, recreate it as a symbolic link to the systemd-resolved stub by running sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf. After restoring the link, restart the systemd-resolved service with sudo systemctl restart systemd-resolved to flush any cached errors and re-read the network configuration.
In some cases, restarting the NetworkManager service may also be necessary to trigger a fresh DHCP lease and DNS assignment. You can do this by executing sudo systemctl restart NetworkManager. Once these steps are complete, verify that your DNS resolution is working by pinging a known domain, such as ping google.com. If the ping succeeds, your system has successfully recovered from the broken configuration.
It is important to note that if you are using a specific local DNS cache like dnsmasq, you might need to adjust its configuration separately. However, for most standard Ubuntu installations, relying on systemd-resolved is the recommended path. For more information on fixing interrupted system processes, you might find our guide on Sudo Interrupted: Manually Running sudo dpkg --configure after apt-get upgrade helpful, as similar recovery principles apply to service disruptions.
Frequently Asked Questions
Can I still use /etc/resolv.conf for static DNS?
No, you should not use /etc/resolv.conf for static DNS in Ubuntu 22.04. The system expects this file to be a dynamic symlink managed by systemd-resolved. Writing to it directly breaks the integration with NetworkManager and leads to resolution failures.
How do I check which DNS servers my system is currently using?
You can check the active DNS servers by running the command resolvectl status in the terminal. This tool queries systemd-resolved and displays the DNS servers assigned to each network interface, along with the current search domains.
What if I need to use a custom DNS for a single application?
If you need to override DNS for a specific application, consider using environment variables like DNS_RESOLVER_OPTIONS if supported, or configure the application to use an IP address directly. Some applications support reading from a custom hosts file via /etc/hosts for simple hostname-to-IP mappings without changing global DNS settings.
Will restoring the symlink delete my custom DNS settings?
Restoring the symlink removes your manual edits but does not erase the intended configuration. You should re-apply your desired DNS settings through the Network Manager GUI or Netplan YAML files. These methods will regenerate the appropriate content in the resolved stub, ensuring your settings persist across reboots and network changes.
Is it safe to disable systemd-resolved?
Disabling systemd-resolved is generally not recommended unless you have a specific reason, such as using a different DNS management tool like dnsmasq or unbound. If you disable it, you must manually manage /etc/resolv.conf and ensure your network manager can function without it, which can lead to complex troubleshooting scenarios.