Fix "Too Many Nameservers in resolv.conf" Warning (2026)

The systemd-resolved service is failing to update resolv.conf because it’s detecting too many nameservers, which it interprets as a sign of manual configuration or a conflict.

Here are the common causes and their fixes:

Cause 1: Manual resolv.conf Edits

You or another process manually edited /etc/resolv.conf, adding nameservers that systemd-resolved doesn’t recognize as being managed by it. systemd-resolved expects to be the sole manager of /etc/resolv.conf.

Diagnosis:
```
cat /etc/resolv.conf
```
Look for lines like nameserver 1.1.1.1 or nameserver 8.8.8.8 that were not added by systemd-resolved. Also, check if /etc/resolv.conf is a regular file instead of a symbolic link to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf.
```
ls -l /etc/resolv.conf
```
Fix: Remove the manual entries from /etc/resolv.conf and ensure it’s a symlink managed by systemd-resolved. If it’s a regular file, you’ll need to remove it and recreate the symlink.
```
sudo rm /etc/resolv.conf
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
```
This works because systemd-resolved will then take over management of the symlink, ensuring its own dynamic entries are used and that no conflicting manual entries exist.

Cause 2: NetworkManager Interference

NetworkManager, another common network configuration tool, might be configured to manage /etc/resolv.conf directly, leading to conflicts with systemd-resolved.

Diagnosis: Check the NetworkManager configuration for dns settings.
```
grep 'dns=' /etc/NetworkManager/NetworkManager.conf
```
Also, check if NetworkManager is actively managing /etc/resolv.conf.
```
ls -l /etc/resolv.conf
```
If /etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf (not stub-resolv.conf) and NetworkManager is configured to manage DNS, this is a likely conflict.
Fix: Configure NetworkManager to let systemd-resolved handle DNS. Edit /etc/NetworkManager/NetworkManager.conf:
```
[main]
plugins=ifupdown,keyfile
# Uncomment the following line if it exists and is set to 'yes'
# dns=default
```
Change it to:
```
[main]
plugins=ifupdown,keyfile
dns=none
```
Then, restart NetworkManager and systemd-resolved:
```
sudo systemctl restart NetworkManager
sudo systemctl restart systemd-resolved
```
Setting dns=none in NetworkManager tells it not to touch /etc/resolv.conf, allowing systemd-resolved to manage it exclusively via its stub-resolv.conf or resolv.conf symlink.

Cause 3: DHCP Client Overrides

Your DHCP client (e.g., dhclient, dhcpcd) might be configured to write nameservers directly into /etc/resolv.conf after receiving them from the DHCP server, ignoring systemd-resolved.

Diagnosis: Examine the configuration of your DHCP client. For dhclient:
```
grep 'prepend domain-name-servers' /etc/dhcp/dhclient.conf
```
If you find lines that instruct dhclient to modify resolv.conf, that’s the issue.
Fix: Configure the DHCP client to not update /etc/resolv.conf. For dhclient, edit /etc/dhcp/dhclient.conf and comment out or remove lines that instruct it to modify resolv.conf. Specifically, look for and remove or comment out:
```
prepend domain-name-servers ...;
```
And ensure it’s not set to update resolv.conf by default. The resolvconf=NO option is often used to prevent this.
```
sudo systemctl restart networking # or your network service
sudo systemctl restart systemd-resolved
```
By preventing the DHCP client from directly writing to resolv.conf, you allow systemd-resolved to manage the file, integrating the DHCP-provided nameservers correctly.

Cause 4: Static IP Configuration with Manual DNS

If you’ve configured a static IP address on an interface, you might have also manually specified DNS servers in the interface configuration file, which can conflict with systemd-resolved.

Diagnosis: Check your network interface configuration files. For example, on Debian/Ubuntu systems:
```
cat /etc/network/interfaces
```
Or for Netplan:
```
cat /etc/netplan/*.yaml
```
Look for dns-nameservers or similar directives within interface stanzas.
Fix: Remove the manual dns-nameservers entries from your static interface configuration and rely on systemd-resolved to provide DNS. For Netplan, modify the YAML file:
```
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses: [192.168.1.100/24]
      # Remove or comment out the 'nameservers' section:
      # nameservers:
      #   addresses: [8.8.8.8, 8.8.4.4]
      routes:
        - to: default
          via: 192.168.1.1
```
Then apply the Netplan configuration:
```
sudo netplan apply
sudo systemctl restart systemd-resolved
```
By centralizing DNS management with systemd-resolved and removing explicit DNS server definitions from static interface configurations, you avoid duplicate or conflicting entries.

Cause 5: Multiple DNS Resolvers Configured in systemd-resolved

While less common, it’s possible that systemd-resolved itself is configured to use multiple upstream DNS servers in a way that triggers this warning, perhaps through complex resolved.conf settings or by picking up too many from different sources.

Diagnosis: Check systemd-resolved’s own configuration.
```
cat /etc/systemd/resolved.conf
```
Look for DNS= and FallbackDNS= entries. Also, check the status of systemd-resolved for any clues.
```
sudo systemctl status systemd-resolved
```
Fix: Simplify systemd-resolved’s configuration. Ensure that DNS= and FallbackDNS= in /etc/systemd/resolved.conf are either commented out (to let DHCP/network management provide them) or contain a clean, minimal set of addresses. For example, to rely solely on DHCP/network manager:
```
[Resolve]
#DNS=
#FallbackDNS=
```
Or, to set specific servers:
```
[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9
```
Then restart the service:
```
sudo systemctl restart systemd-resolved
```
This ensures that systemd-resolved isn’t being fed an excessive number of servers by its own configuration or by misinterpreting network-provided settings.

Cause 6: Systemd-resolved is not running properly or is in a bad state

Sometimes, the service might be in a transitional or error state, leading it to misinterpret the DNS configuration.

Diagnosis:

sudo systemctl status systemd-resolved
journalctl -u systemd-resolved --since "1 hour ago"

Look for any errors or unusual states.

Fix: A simple restart might clear a transient issue. If that doesn’t work, try resetting the configuration.

sudo systemctl stop systemd-resolved
sudo rm /etc/resolv.conf # If it's a symlink, this is fine. If it's a file, be cautious.
sudo rm /run/systemd/resolve/* # Be careful with this if other services depend on these files directly.
sudo systemctl start systemd-resolved
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf # Recreate the symlink

This forces systemd-resolved to re-initialize its state and rebuild its resolv.conf from scratch.

After applying the correct fix for your situation, the next warning you might encounter is related to DNS resolution itself, such as "DNS resolution failed" if the configured nameservers are unreachable or misconfigured.