Fix "Temporary failure in name resolution" on Linux

ping -c 2 1.1.1.1            # network works?
resolvectl status            # which DNS servers are in use?
sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManager

You will see the message from many programs, for example:

ping: archive.ubuntu.com: Temporary failure in name resolution
ssh: Could not resolve hostname server: Temporary failure in name resolution
Temporary failure resolving 'deb.debian.org'
curl: (6) Could not resolve host: example.com

What the error means

Programs ask the C library (getaddrinfo) to turn a name into an IP address. "Temporary failure" (EAI_AGAIN) means no DNS server gave an answer, as opposed to "Name or service not known", which means DNS answered that the name does not exist. So the question is always: is there no network, no DNS server, or a DNS server that does not respond?

ping -c 2 1.1.1.1         # IP connectivity
getent hosts debian.org   # resolution through the system resolver
cat /etc/resolv.conf      # what the resolver uses

If pinging an IP fails too, you have no network at all; fix the connection first (Wi-Fi not working, Ubuntu Wi-Fi fixes). If the IP works but names do not, it is DNS; keep reading.

Cause 1: systemd-resolved is stopped or has no upstream servers

Ubuntu, Fedora and many others point /etc/resolv.conf at a local stub resolver, nameserver 127.0.0.53, run by systemd-resolved. If the service is stopped, every lookup fails. If it runs but has no upstream server, lookups fail too.

systemctl status systemd-resolved
resolvectl status

Example output (broken: no DNS server on the link):

Link 2 (wlp3s0)
    Current Scopes: none
         Protocols: -DefaultRoute ...

A healthy link shows Current DNS Server: and DNS Servers: lines. Fix it by restarting the service and the connection, or set DNS servers on the connection:

sudo systemctl enable --now systemd-resolved
nmcli connection show            # find the connection name
sudo nmcli connection modify "Home Wi-Fi" ipv4.dns "1.1.1.1 9.9.9.9" ipv4.ignore-auto-dns yes
sudo nmcli connection up "Home Wi-Fi"

Cause 2: /etc/resolv.conf is missing, empty or a broken link

Upgrades, VPN clients and manual edits often leave /etc/resolv.conf pointing at a file that no longer exists.

ls -l /etc/resolv.conf

Example output:

lrwxrwxrwx 1 root root 39 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

If the link is shown in red (target missing) or the file has no nameserver line, restore it. With systemd-resolved:

sudo ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Without systemd-resolved (Debian's default, and Arch unless you enabled it), NetworkManager writes /etc/resolv.conf itself as a regular file; restarting NetworkManager regenerates it. On a minimal server with no network manager, a static file works:

printf 'nameserver 1.1.1.1\nnameserver 9.9.9.9\n' | sudo tee /etc/resolv.conf

Only do that when nothing else manages the file, or it will be overwritten.

Cause 3: the DNS server you were given does not work

Routers and captive portals sometimes hand out a DNS server that is down, filtered or only reachable on another network. Test the configured server and a public one directly:

resolvectl query debian.org
dig @1.1.1.1 debian.org +short     # needs dnsutils / bind-utils / bind
dig @192.168.1.1 debian.org +short

If public DNS answers but your router does not, set DNS on the connection as shown under cause 1, or fix the router. Some networks block outside DNS (port 53); then you must use the network's server.

Cause 4: VPN left DNS behind

VPN clients often push their own DNS server and route all queries to it. After disconnecting uncleanly, queries still go to a server you can no longer reach. Disconnect fully, then restart the network stack:

sudo systemctl restart NetworkManager
resolvectl flush-caches

Check for leftover tun or wg interfaces with ip -brief link.

Cause 5: containers and WSL

Docker: containers copy the host's resolver settings, but cannot use 127.0.0.53, so Docker substitutes the upstream servers or falls back to public ones. If containers cannot resolve names while the host can, set servers in /etc/docker/daemon.json ({"dns": ["1.1.1.1"]}) and restart Docker. See Docker on Linux.

WSL: /etc/resolv.conf is generated from Windows on each start. If it breaks, especially with a Windows VPN, enable DNS tunneling in .wslconfig (current WSL versions), or put this in /etc/wsl.conf, run wsl --shutdown from Windows, and create your own resolv.conf:

[network]
generateResolvConf = false

Distro notes

• Ubuntu, Mint: systemd-resolved with the 127.0.0.53 stub; servers set by NetworkManager (desktop) or netplan (server). On servers, set DNS under nameservers: in /etc/netplan/*.yaml and run sudo netplan apply.
• Debian 13: NetworkManager (desktop) or ifupdown (server) writes /etc/resolv.conf directly; systemd-resolved is optional.
• Fedora: systemd-resolved plus NetworkManager; use resolvectl and nmcli.
• Arch: whatever you set up. If you installed systemd-resolved, create the stub symlink yourself; it is not done automatically.
• openSUSE: NetworkManager on desktops; netconfig may manage /etc/resolv.conf, so change DNS through NetworkManager or YaST.

How to prevent it

• Change DNS through NetworkManager, netplan or YaST, not by editing the generated /etc/resolv.conf.
• Configure two DNS servers so one outage does not break everything.
• Use your VPN client's disconnect function rather than killing it.

Once DNS works, rerun the command that failed. For apt or dnf, failed lookups also caused Unable to locate package or Failed to download metadata; a fresh sudo apt update or sudo dnf makecache clears them. The networking basics guide explains resolvectl, nmcli and ip in more detail.

Frequently asked questions