Fix 'Temporary Failure in Name Resolution' on a VPS

You SSH into your VPS, run apt update or curl https://example.com, and get hit with "Temporary failure in name resolution". The server is up, you can ping IP addresses, yet nothing with a hostname works. Updates fail, WordPress can't reach the plugin repo, and your mail server can't look up MX records. Let's sort it out.

Symptom: what you'll actually see

The wording changes by tool, but it all means the same thing: the server can't turn a name into an IP.

• ping: google.com: Temporary failure in name resolution
• curl: (6) Could not resolve host: example.com
• W: Failed to fetch ... Temporary failure resolving 'archive.ubuntu.com'
• dnf: Curl error (6): Couldn't resolve host name
• WordPress Site Health: "cURL error 6: Could not resolve host"

First, confirm it's really DNS and not a dead network:

ping -c 3 1.1.1.1
ping -c 3 google.com

If the first works and the second fails, the network is fine and resolution is broken. If both fail, you have a connectivity problem instead, which is a different fix (check netplan or your network config).

Cause: why a VPS loses DNS resolution

Linux looks up names through the resolver config in /etc/resolv.conf. That file lists the nameservers your server asks. Things go wrong when:

1. The file is empty or missing. A bad cloud-init run, a manual edit, or a script that overwrote it.
2. It points at a resolver that isn't running. On Ubuntu it's usually 127.0.0.53 (systemd-resolved). If that service is stopped, every lookup fails.
3. The DNS servers listed are unreachable. An old provider resolver, or a firewall dropping outbound port 53.
4. A broken symlink. /etc/resolv.conf is normally a symlink; if its target is gone, you get nothing.
5. Something rewrites it. NetworkManager, dhclient or cloud-init can overwrite your manual changes on reboot.

Fix: step by step

1. Look at what the server is using

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

A healthy Ubuntu box shows a symlink to /run/systemd/resolve/stub-resolv.conf and a line like nameserver 127.0.0.53. A healthy AlmaLinux or Rocky box usually lists real nameserver IPs.

2. Test with a known-good resolver

dig @1.1.1.1 skyserver.in +short
dig @8.8.8.8 skyserver.in +short

If these answer, outbound DNS is open and your local config is the problem. If they time out, a firewall is blocking port 53; check UFW/CSF rules for outbound UDP/TCP 53.

One more check worth doing at this stage: run getent hosts skyserver.in. It uses the same lookup path as most applications, so if dig works but getent fails, the problem sits in /etc/nsswitch.conf or the local resolver rather than in your upstream DNS.

3. Ubuntu/Debian: restart systemd-resolved

systemctl status systemd-resolved
sudo systemctl enable --now systemd-resolved
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
resolvectl status

To set resolvers properly rather than hacking the file, add them in netplan (/etc/netplan/*.yaml):

nameservers:
  addresses: [1.1.1.1, 8.8.8.8]

Then run sudo netplan apply.

4. AlmaLinux/Rocky/CentOS: set DNS via NetworkManager

nmcli con show
sudo nmcli con mod "System eth0" ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con mod "System eth0" ipv4.ignore-auto-dns yes
sudo nmcli con up "System eth0"

Swap the connection name for whatever nmcli con show prints on your server.

5. Quick emergency fix

If you just need the server talking right now, write the file directly:

sudo rm -f /etc/resolv.conf
echo -e "nameserver 1.1.1.1\nnameserver 8.8.8.8" | sudo tee /etc/resolv.conf

This works instantly, but it may get overwritten at the next reboot. Treat it as a bandage and apply step 3 or 4 afterwards.

6. cPanel/WHM servers

On a cPanel VPS, also check WHM → Networking Setup → Resolver Configuration. Put two working resolvers there. cPanel's own DNS checks, AutoSSL and update jobs all depend on it, so a bad entry here causes strange failures elsewhere.

Quick reference

Prevention

• Configure DNS through netplan or NetworkManager so it survives reboots.
• List at least two resolvers, from different providers.
• Keep outbound port 53 (UDP and TCP) open when you tighten firewall rules.
• After editing network files, test with dig skyserver.in before you log out. Don't lock yourself out of a working fix.
• Monitor with a simple cron job that runs dig +short and emails you when it returns nothing.

If you've worked through these steps and lookups still fail, open a ticket with SkyServer support and include the output of cat /etc/resolv.conf and resolvectl status. It saves a round trip.

Frequently Asked Questions

Why does ping to an IP work but not to a domain?

Ping to an IP skips DNS entirely. A domain needs a lookup first, so if the resolver is broken only names fail.

Is it safe to use 1.1.1.1 and 8.8.8.8 on my VPS?

Yes. They're reliable public resolvers. For heavy mail servers, a local caching resolver such as Unbound can reduce lookup delays and avoid public resolver rate limits.

My resolv.conf keeps reverting after a reboot. Why?

Something is managing it, usually systemd-resolved, NetworkManager or cloud-init. Set the DNS in that tool's own config and the change will stick.

Could this be my domain's DNS and not my server?

If other sites resolve fine from the server but one domain doesn't, the problem is that domain's DNS records or nameservers, not the VPS resolver. Test it with dig yourdomain.com @1.1.1.1.