How to Fix Temporary failure in name resolution (Linux, SSH)

Updated: 12 October 2026 · Applies to: Ubuntu 26.04 and 24.04 (OpenSSH 10.2p1 and 9.6p1), Debian 13, AlmaLinux 10.2 and 9.8 (same on Rocky Linux and RHEL 9 and 10)

Temporary failure in name resolution means the machine asked for a name such as example.com and no DNS server answered. The domain is usually fine: the machine has no working DNS server, the firewall blocks DNS, or the network itself is down. Run these three checks first:

ping -c 3 1.1.1.1              # does the network work without DNS?
dig @1.1.1.1 example.com +short  # does a public DNS server answer?
cat /etc/resolv.conf             # which DNS servers does the system use?

If the public server answers but normal lookups fail, set working DNS servers (section 3). If nothing answers, check the network and the firewall (sections 2 and 4).

1. The SSH error: ssh: Could not resolve hostname

When the error appears as soon as you run ssh, it comes from the computer you are typing on, not from the server. ssh must turn the name into an IP address before it can connect, so the server never saw the attempt. Real output from our Ubuntu 26.04 lab with a broken resolver:

$ ssh root@example.com
ssh: Could not resolve hostname example.com: Temporary failure in name resolution

1. Check which name ssh really looks up. If you use an alias from ~/.ssh/config, ssh resolves its HostName, and the error shows that name. Print the settings ssh will use:

   $ ssh -G myvps | grep -E '^(hostname|user|port) '
   user root
   hostname vps.example.com
   port 2222

2. Connect by IP address to get in while DNS is broken: ssh -p 2222 root@203.0.113.10. Give the port with -p; ssh root@203.0.113.10:2222 is treated as a host name and fails with Could not resolve hostname 203.0.113.10:2222: Name or service not known. More in how to connect to SSH on a different port.
3. Temporary workaround: add the name to /etc/hosts on your computer, for example 203.0.113.10 vps.example.com. In our test ssh then used that IP even with DNS down. Remove the line once DNS works, or it will break when the IP changes.
4. Fix DNS on your computer. On a Linux desktop the steps below apply. On Windows or macOS, see hostname could not be found or resolved.

If SSH login works but commands on the server fail (apt, dnf, curl, git, ssh to another host), the server's own DNS is broken: continue below.

2. Find out what is broken

The same fault looks like this in other tools (Ubuntu 26.04 and AlmaLinux 10.2 lab output):

$ ping -c1 example.com
ping: example.com: Temporary failure in name resolution
$ curl https://example.com
curl: (6) Could not resolve host: example.com
$ apt-get update
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/resolute-security/InRelease  Temporary failure resolving 'security.ubuntu.com'
$ dnf makecache
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: Curl error (6): Could not resolve hostname for https://mirrors.almalinux.org/mirrorlist/10/appstream [Could not resolve host: mirrors.almalinux.org]

1. Test the network without DNS: ping -c 3 1.1.1.1. If it prints connect: Network is unreachable, the server has no route to the internet and DNS is not the cause. Check ip addr and ip route.
2. Test a lookup the way programs do it: getent hosts example.com. No output (exit code 2) means the lookup failed.
3. Ask a public DNS server directly: dig @1.1.1.1 example.com +short (package bind-utils on AlmaLinux, Rocky and RHEL, bind9-dnsutils on Ubuntu and Debian). IP addresses in the answer mean the network and port 53 work, so the server's DNS settings are wrong. ;; no servers could be reached means DNS traffic does not get out.
4. Note how fast it fails. In our tests a DNS server address that does not respond made every lookup wait 10 seconds before the error. An instant error means nothing answers on the configured address, for example 127.0.0.1 or 127.0.0.53 with the local resolver stopped, or an empty /etc/resolv.conf (glibc then tries 127.0.0.1). If only the first of several servers is down, see how to change the timeout before falling back to the secondary DNS server.

AlmaLinux, Rocky Linux and RHEL show a different message. Their default hosts: line in /etc/nsswitch.conf is files dns myhostname. In our AlmaLinux 10.2 and 9.8 tests the same DNS outage therefore printed Name or service not known instead of Temporary failure in name resolution. So on these systems do not assume the domain is missing: run the dig @1.1.1.1 test first.

3. Set working DNS servers

Do not just edit /etc/resolv.conf: on most servers a network service rewrites it. Change the setting where it comes from.

AlmaLinux, Rocky Linux and RHEL (NetworkManager)

1. Find the connection name in the NAME column (often eth0 or System eth0): nmcli connection show
2. Set the DNS servers and ignore the ones from DHCP, then apply:

   nmcli connection modify "System eth0" ipv4.dns "1.1.1.1 8.8.8.8" ipv4.ignore-auto-dns yes
   nmcli device reapply eth0

   We checked these property names with NetworkManager 1.56 on AlmaLinux 10.2; it saved them as dns=1.1.1.1;8.8.8.8; and ignore-auto-dns=true.
3. Check: cat /etc/resolv.conf now lists the new servers.

Ubuntu 24.04 and 26.04 (netplan and systemd-resolved)

1. On Ubuntu, /etc/resolv.conf lists nameserver 127.0.0.53, the local systemd-resolved service. That is correct. See the real upstream servers with resolvectl status.
2. Add the DNS servers to your interface in the netplan file in /etc/netplan/ (format from the Netplan documentation):

   network:
     ethernets:
       eth0:
         nameservers:
           addresses: [1.1.1.1, 8.8.8.8]

   If the interface uses DHCP and its DNS servers are the broken ones, also add dhcp4-overrides: with use-dns: false under eth0; according to Netplan, DHCP DNS servers otherwise take precedence.
3. Apply and test: netplan apply, then resolvectl query example.com.
4. If /etc/resolv.conf was replaced or deleted, restore the link that systemd-resolved recommends, then restart it:

   ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
   systemctl restart systemd-resolved

   If systemctl status systemd-resolved shows it stopped, every lookup to 127.0.0.53 fails instantly.

Debian 13

With the classic /etc/network/interfaces setup and the resolvconf package, add dns-nameservers 1.1.1.1 8.8.8.8 to the interface. If nothing manages /etc/resolv.conf, write the servers into it directly:

nameserver 1.1.1.1
nameserver 8.8.8.8

More examples, including Windows, are in how to change your DNS server on Windows, Ubuntu and Linux.

4. Allow DNS through the firewall

The server must be allowed to send outgoing traffic to port 53 over UDP and TCP (when DNS uses TCP or UDP). Most firewalls allow all outgoing traffic; check the ones that restrict it:

• CSF (common on cPanel servers): port 53 must be in TCP_OUT and UDP_OUT in /etc/csf/csf.conf. Run csf -r after a change.
• UFW: if outgoing traffic is denied by default, allow DNS with ufw allow out 53.
• firewalld allows outgoing traffic unless you added your own policies.

5. Other causes

• resolv.conf points to 127.0.0.1: then a resolving DNS service must run on the server, such as BIND (systemctl status named) or Unbound. The PowerDNS service on cPanel servers only answers for the domains hosted there, so point such servers to external resolvers.
• Lookup order: the hosts: line in /etc/nsswitch.conf must include dns. When we removed it, lookups failed with Name or service not known even though DNS worked.
• The file cannot be changed: if edits to /etc/resolv.conf fail even as root, check lsattr /etc/resolv.conf for the i flag and remove it with chattr -i /etc/resolv.conf.
• sudo: unable to resolve host: the server cannot find its own host name. Add it to /etc/hosts as shown in hostname could not be found or resolved.

Official documentation: systemd-resolved and /etc/resolv.conf and Netplan YAML reference.