VPS DNS Resolution Failing (2026): systemd-resolved, resolvectl, and resolv.conf Troubleshooting Checklist

Don't guess on the first step; run a comparison test directly.

First ping an IP:

ping -c 3 1.1.1.1

Then ping a domain name:

ping -c 3 example.com

If the IP works but the domain name doesn't, it's very likely a DNS resolution problem.

Then compare with curl:

curl -I https://1.1.1.1
curl -I https://example.com

https://1.1.1.1 may report a TLS error due to a certificate domain mismatch, but as long as it can connect to the other side, the network layer is roughly intact. What really matters is whether domain name resolution fails.

If dig is installed, it's more intuitive:

dig example.com

If the system default DNS can't resolve, then specify a public DNS:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

If dig @1.1.1.1 example.com can resolve but dig example.com can't, the public DNS service is fine and the problem is in this VPS's local resolution configuration.

On systems like Ubuntu 20.04/22.04/24.04, the common component is systemd-resolved. First check the status:

resolvectl status

Focus on a few parts:

• Whether Global has DNS Servers
• Whether the current network interface has DNS Servers
• Whether DNSSEC is yes, no, or allow-downgrade
• Whether DNSOverTLS is enabled
• Which interface is the current DefaultRoute

You can also query a domain name directly:

resolvectl query example.com

If this fails but dig @1.1.1.1 example.com succeeds, the problem is concentrated in the local resolver or interface DNS configuration.

Then check the service status:

systemctl status systemd-resolved --no-pager

Check recent logs:

journalctl -u systemd-resolved --since "30 minutes ago" --no-pager

If you're troubleshooting a live incident, you can watch in real time:

journalctl -u systemd-resolved -f

Ubuntu's DNSSEC troubleshooting documentation also uses combinations of resolvectl, dig, and journalctl to locate resolution problems; this set of commands is far more reliable than "try rebooting."

Many people, the first time they see only this line in /etc/resolv.conf, think DNS has been broken:

nameserver 127.0.0.53

Actually this is usually systemd-resolved's local stub resolver. Applications send DNS requests to 127.0.0.53, and systemd-resolved then forwards them to the real upstream DNS.

First check what /etc/resolv.conf actually is:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

One common normal case is that it points to:

/run/systemd/resolve/stub-resolv.conf

which contains:

nameserver 127.0.0.53

Some systems point directly to:

/run/systemd/resolve/resolv.conf

which contains the real upstream DNS. Both modes can be normal; the key is that it matches your system's network management approach.

What's truly dangerous is:

• /etc/resolv.conf being hardcoded by hand and then overwritten after a reboot
• The file pointing to a nonexistent path
• nameserver set to an unreachable internal address
• Only IPv6 DNS, but the VPS IPv6 route doesn't work
• Panels, VPNs, Docker, and cloud-init all racing to change DNS

Don't run just one command for DNS failures. You can follow this sequence:

dig example.com
dig @127.0.0.53 example.com
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

A few results are easy to judge:

Some VPS providers or corporate networks block UDP 53; you can also try TCP:

dig +tcp @1.1.1.1 example.com

If UDP fails but TCP succeeds, suspect a firewall, carrier policy, or local rules.

When a live service is throwing errors, the goal is to restore resolution first, then slowly find the root cause.

If you know the interface name, such as eth0, you can set it temporarily:

sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl domain eth0 '~.'

Then test:

resolvectl query example.com
dig example.com
curl -I https://example.com

If the interface isn't called eth0, first check:

ip link
resolvectl status

This kind of resolvectl dns setting is more runtime-oriented and suitable for emergencies. To make it permanent, you still need to handle it in netplan, NetworkManager, cloud-init, or the system network configuration.

If you want to undo the temporary setting on the interface:

sudo resolvectl revert eth0

Sometimes the DNS configuration isn't completely wrong; rather, the cache or server feature probe state is abnormal.

You can clear the DNS cache:

sudo resolvectl flush-caches

Then reset DNS server feature probing:

sudo resolvectl reset-server-features

Then query again:

resolvectl query example.com

The official resolvectl manual includes operations like flush caches, reset server features, setting DNS per interface, and reverting interface configuration. During troubleshooting, use these bounded commands first; don't start by deleting configuration files at random.

If systemd-resolved is in an abnormal state, you can restart it:

sudo systemctl restart systemd-resolved

Then immediately check:

systemctl status systemd-resolved --no-pager
resolvectl status
resolvectl query example.com

It's not recommended to make reboot your first reaction. Rebooting the whole VPS interrupts business, and if /etc/resolv.conf or the netplan configuration was already wrong, the problem remains after the reboot.

If it's fixed after restarting the service, also keep asking: why did it break? Was it the cache, upstream DNS, DHCP-provided DNS, DNSSEC, or some tool that changed the configuration?

Many tutorials teach you to do this:

sudo nano /etc/resolv.conf

and then write:

nameserver 8.8.8.8
nameserver 1.1.1.1

It may work for a short time, but it's often overwritten by NetworkManager, netplan, systemd-resolved, cloud-init, or the DHCP client.

If it's just an emergency, you can write it temporarily, but know that it may not persist. A more stable approach is to find out who is managing the network.

On Ubuntu it's commonly netplan:

ls /etc/netplan/

Check the configuration:

sudo cat /etc/netplan/*.yaml

If it's netplan, you can configure nameservers under the corresponding interface, for example:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

After editing, check first and then apply:

sudo netplan try
sudo netplan apply

Be very careful when changing netplan on a remote VPS. netplan try gives you a chance to roll back; don't kick yourself offline directly.

Many VPS instances have their network configuration written by cloud-init on first boot. If you manually changed netplan and it gets overwritten after a while following a reboot or rebuild, check cloud-init.

Common files:

ls /etc/cloud/cloud.cfg.d/

If you explicitly don't want cloud-init to manage the network, some systems use a configuration like:

network: {config: disabled}

But don't copy it blindly. Cloud provider templates differ, and disabling cloud-init network management may affect later IP changes, NIC swaps, or instance rebuilds. Before touching this on a production machine, confirm the cloud provider's documentation and the current network configuration.

For ordinary users, the safer approach is: first find out whether DNS comes from DHCP, netplan, NetworkManager, or cloud-init, then decide where to change it.

If only individual domains fail to resolve and public DNS results are inconsistent, you can suspect DNSSEC, authoritative DNS, or cache issues.

Check resolved status:

resolvectl status

Check DNSSEC-related logs:

journalctl -u systemd-resolved --since "30 minutes ago" --no-pager

Use dig to view DNSSEC information:

dig example.com +dnssec

Then specify different upstreams:

dig @1.1.1.1 example.com +dnssec
dig @8.8.8.8 example.com +dnssec

If it only fails when DNSSEC validation is enabled, the domain's DNSSEC configuration may be broken, or the intermediate network or upstream DNS may have incomplete support.

It's not recommended to disable all DNSSEC long-term for the sake of one domain. A better approach is to first confirm whether it's a problem with the domain's authoritative DNS, then decide whether to temporarily downgrade.

Just because the host can resolve doesn't mean the container can.

Enter the container to test:

docker exec -it 容器名 sh
nslookup example.com
cat /etc/resolv.conf

Docker generates its own /etc/resolv.conf for containers by default. If the container doesn't keep up after the host DNS changes, or the Docker daemon is configured with the wrong DNS, applications inside the container will report Could not resolve host.

You can check the Docker daemon configuration:

sudo cat /etc/docker/daemon.json

If you want to fix DNS for Docker, a common approach is:

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

After editing, you need to restart Docker:

sudo systemctl restart docker

Note: restarting Docker affects containers, so schedule a window in production.

BT Panel, 1Panel, VPN clients, proxy tools, and intranet penetration tools can all change DNS or routes.

When troubleshooting, check recent changes:

stat /etc/resolv.conf
ls -lt /etc/netplan/
journalctl --since "2 hours ago" --no-pager | grep -i dns

If the failure happened after you installed a VPN, changed a security group, installed a panel, or adjusted the Docker network, look back at that change first. DNS problems often aren't "suddenly broken"; rather, some tool changed the network configuration for you.

When production is down, follow this order:

1. ping -c 3 1.1.1.1 to see whether the IP works
2. ping -c 3 example.com to see whether domain resolution fails
3. dig @1.1.1.1 example.com to verify whether public DNS can resolve
4. resolvectl status to see the current DNS and interface
5. readlink -f /etc/resolv.conf to see what resolv.conf points to
6. journalctl -u systemd-resolved --since "30 minutes ago" to check logs
7. sudo resolvectl flush-caches to clear the cache
8. sudo resolvectl reset-server-features to reset probe state
9. sudo resolvectl dns eth0 1.1.1.1 8.8.8.8 to temporarily specify DNS
10. resolvectl query example.com to verify recovery
11. Then go back and fix the persistent configuration in netplan / NetworkManager / cloud-init

The point of this procedure is to layer things first: whether the network works, whether the local resolver is good, whether upstream DNS can resolve, and whether the configuration will be overwritten.

• IP works but domain doesn't, confirming it's a DNS direction
• dig @1.1.1.1 example.com can verify public DNS
• resolvectl status shows the current interface DNS
• systemd-resolved service status is normal
• /etc/resolv.conf points to something reasonable, with no broken links
• 127.0.0.53 is a stub resolver, not inherently an error
• Cache cleared and server features reset
• Resolution restored after temporary DNS settings
• Persistent configuration handled back in netplan / NetworkManager / cloud-init
• DNS inside Docker containers also tested separately
• reboot not used to mask the root cause

DNS failures look mysterious, but they break down into just a few layers: who the application asks, who systemd-resolved forwards to, whether upstream DNS responds, and whether the configuration gets overwritten by other tools. As long as IPs work, don't rush to suspect the whole VPS is broken; check the resolution chain layer by layer first.