Fix Temporary Failure in Name Resolution on Linux

Tested on RHEL 10.2 (Coughlan)
Package bind-utils 9.18.33-15.el10_2.2
NetworkManager 1.56.0-1.el10
dnsmasq 2.90-7.el10_2
Applies to Ubuntu, Debian, Kali Linux, Linux Mint, Pop!_OS, Raspberry Pi OS, elementary OS, Zorin OS, Parrot OS, MX Linux, RHEL, Rocky Linux, AlmaLinux, Oracle Linux, CentOS Stream, Fedora, Arch Linux
Privilege Normal user for lookups; sudo or root to change connection profiles, restart DNS services, and edit system resolver files
Scope Diagnose and fix hostname resolution failures when ping, curl, dnf, or apt report temporary failure in name resolution or could not resolve host. Covers connectivity checks, getent and dig, resolv.conf, and NetworkManager DNS. Does not cover BIND or full DNS server administration.
Related guides Linux hostname resolution
dig and host commands
nmcli command examples
Restart network on RHEL family
Refresh network on Ubuntu

ping google.com prints temporary failure in name resolution, or name or service not known, while ping 8.8.8.8 still reaches the internet. That split tells you routing is probably fine and the resolver is not getting answers from the DNS servers in /etc/resolv.conf.

This guide walks through that check in order: confirm L3 connectivity, test DNS directly, inspect which nameservers the system uses, fix them through NetworkManager (or your distro’s resolver service), and verify lookups again.

What the error means

Applications call the C library resolver (getaddrinfo). When every configured nameserver fails — timeout, connection refused, or no nameservers listed — the call returns an error. Tools surface it with different wording:

Tool Typical message when DNS is broken
ping temporary failure in name resolution or name or service not known
curl / wget Could not resolve host (curl error 6)
dnf / apt Couldn't resolve host name or Temporary failure resolving
dig communications error / no servers could be reached

The message is not authentication failure, a down web server, or a missing default route. It appears before TCP connects to the remote service.

IMPORTANT
This article fixes client-side DNS configuration on the host that cannot resolve names. It does not cover designing DNS zones, debugging authoritative server failures remotely, or corporate split-horizon DNS policy — only getting your Linux box back to a working resolver.

Separate routing from DNS

Start with an IP address so hostname lookup is out of the picture. Pick a well-known resolver or your gateway:

bash
ping -c2 -W3 8.8.8.8

Sample output:

output
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=18.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=17.9 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

ICMP replies mean the path to that IP works. Some networks block ping; if you see 100% loss but the route looks correct, try TCP instead with test port connectivity or curl -sI --max-time 5 https://1.1.1.1.

Confirm which interface and source address the kernel would use:

bash
ip route get 8.8.8.8

Sample output:

output
8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

A line with via and dev means a route exists. If this command prints Network is unreachable, fix routing or the default gateway first — changing DNS will not help.

When IP reachability works but every hostname fails, continue with DNS tests below.

Test DNS resolution

Use two tools: one that follows NSS (what ssh, curl, and ping use) and one that queries DNS directly.

NSS lookup with getent

getent hosts respects /etc/hosts and nsswitch.conf:

bash
getent hosts google.com

When DNS works, you get one or more address lines:

output
142.251.220.110 google.com

When DNS is broken and the name is not in /etc/hosts, getent prints nothing and exits with status 2:

bash
getent hosts google.com

No output and exit code 2 means NSS did not resolve the name. Compare with a static entry — if getent hosts succeeds for a name only in /etc/hosts but fails for public names, DNS is the gap.

Direct DNS query with dig

dig bypasses NSS and speaks to the servers listed in resolv.conf. With working nameservers you should see an answer section and which server replied:

bash
dig +time=3 +tries=1 google.com A
output
;; ANSWER SECTION:
google.com.		112	IN	A	142.251.220.110

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

The SERVER line names the resolver that answered. When that nameserver is down or firewalled, run the same command again and read the error at the bottom:

bash
dig +time=3 +tries=1 google.com A
output
;; communications error to 192.168.56.116#53: connection refused

; <<>> DiG 9.18.33 <<>> +time=3 +tries=1 google.com A
;; global options: +cmd
;; no servers could be reached

connection refused means nothing is listening on UDP 53 at that address. A timeout with no reply often means a firewall is dropping queries or the server is down.

For a quick yes/no check, use dig and host shortcuts:

bash
dig +short google.com A
output
142.251.220.110

Check which DNS servers are configured

On NetworkManager systems, DNS may come from more than one connection profile (for example a lab NIC plus a NAT interface). List what each active device advertises:

bash
nmcli dev show | grep -E 'GENERAL.CONNECTION|IP4.DNS'

Sample output:

output
GENERAL.CONNECTION:                     enp0s8
IP4.DNS[1]:                             8.8.8.8
IP4.DNS[2]:                             1.1.1.1
GENERAL.CONNECTION:                     enp0s3
IP4.DNS[1]:                             192.168.0.1

NetworkManager merges nameservers from all contributing connections into /etc/resolv.conf. If one profile points at a dead local forwarder, it can break resolution even when another profile has valid public DNS.

Inspect the profile tied to the interface you care about — replace enp0s8 with yours from nmcli device status:

bash
nmcli -f ipv4.dns,ipv4.ignore-auto-dns,ipv4.method connection show enp0s8

Sample output:

output
ipv4.dns:                               192.168.56.116
ipv4.ignore-auto-dns:                   yes
ipv4.method:                            auto

ipv4.ignore-auto-dns: yes means only the servers you set manually are used for that profile. no allows DHCP-provided DNS to merge in.

Check /etc/resolv.conf

Applications read the nameservers NetworkManager (or systemd-resolved) wrote here:

bash
cat /etc/resolv.conf

Sample output when DNS is misconfigured toward a local forwarder that is down:

output
# Generated by NetworkManager
search lab.example
nameserver 192.168.56.116

The search line appends those domains to short hostnames. The nameserver lines are what matter for external names like google.com.

See whether the file is a symlink to NetworkManager or systemd-resolved:

bash
ls -l /etc/resolv.conf

On this RHEL host the file is a regular file regenerated by NetworkManager:

output
-rw-r--r--. 1 root root 87 Aug 22 08:28 /etc/resolv.conf

On many Ubuntu and Debian installs, resolv.conf points at 127.0.0.53 and systemd-resolved owns upstream servers — see refresh network on Ubuntu before editing that file by hand.

NOTE
Hand-editing resolv.conf on a NetworkManager host usually does not stick. Change DNS on the connection profile instead so the file regenerates correctly on reconnect.

NetworkManager and systemd-resolved

Fix DNS with nmcli (RHEL, Fedora, NetworkManager desktops)

Identify the active connection name for your interface:

bash
nmcli device status

Set explicit DNS servers and stop DHCP from overriding them — replace enp0s8 with your connection name:

bash
sudo nmcli connection modify enp0s8 ipv4.dns '8.8.8.8,1.1.1.1' ipv4.ignore-auto-dns yes

Apply the profile so resolv.conf regenerates:

bash
sudo nmcli connection up enp0s8

Confirm the file picked up the new servers:

bash
cat /etc/resolv.conf
output
# Generated by NetworkManager
search lab.example
nameserver 8.8.8.8
nameserver 1.1.1.1

If a local DNS forwarder (for example dnsmasq on a gateway or hypervisor) should be used, point at its listening address and make sure the service is running:

bash
sudo systemctl is-active dnsmasq

active means the forwarder is up; inactive or failed explains connection refused from dig when resolv.conf lists that address.

When several connections pollute DNS, either fix each profile or disconnect unused interfaces. After profile changes, restart or reload network only if nmcli connection up did not refresh DNS.

systemd-resolved on Debian and Ubuntu

When resolvectl status shows Current DNS Server and /etc/resolv.conf lists 127.0.0.53, change DNS through resolvectl, Netplan, or NetworkManager — not by overwriting the stub file. Restart the resolver after upstream changes:

bash
sudo systemctl restart systemd-resolved

Full Ubuntu-specific steps live in refresh network on Ubuntu.

Verify name resolution

Re-run the same checks you used while diagnosing.

NSS path:

bash
getent hosts google.com
output
142.251.220.110 google.com

Direct DNS:

bash
dig +short google.com A
output
142.251.220.110

Application-level check — ping should resolve the name in the first line:

bash
ping -c1 -W3 google.com
output
PING google.com (142.251.220.110) 56(84) bytes of data.
64 bytes from 142.251.220.110: icmp_seq=1 ttl=117 time=19.1 ms

If getent and dig succeed but one application still fails, compare the exact hostname it uses (FQDN vs short name) and read the hosts: line in /etc/nsswitch.conf — see Linux hostname resolution for NSS order and search domains.

Troubleshooting

Symptom Likely cause Fix
ping 8.8.8.8 works; hostname fails Wrong or dead nameservers in resolv.conf Set working DNS with nmcli connection modify … ipv4.dns; verify with dig
dig shows connection refused Nothing listening on UDP 53 at listed IP Start local forwarder (dnsmasq, router DNS) or point at a reachable resolver
dig times out Firewall DROP on UDP 53 or server unreachable Open outbound 53 or fix routing to the DNS host
dig @8.8.8.8 works; getent fails NSS or /etc/hosts order; different resolver path Check nsswitch.conf; align resolv.conf nameservers with a server that answers
getent works for some names only Name exists in /etc/hosts; DNS still broken for others Fix DNS; do not assume hosts file covers internet names
Edits to resolv.conf revert NetworkManager or systemd-resolved regenerates the file Change DNS on the connection profile or resolved config
Multiple nameserver lines; one is bad Several NM profiles merge DNS nmcli dev show; fix or ignore-auto-dns on each profile
Error right after VPN connect VPN pushed broken DNS Split DNS on VPN profile or set ipv4.ignore-auto-dns and corporate resolvers
Temporary failure resolving in apt only Same root cause as ping/curl Fix system resolver; then sudo apt update

References

Summary

Temporary failure in name resolution means your applications could not turn a hostname into an IP address. The fastest split is IP ping works, name ping fails — that points at DNS, not cables or default routes.

Walk the resolver stack in order: getent for what NSS sees, dig for what your listed nameservers answer, then resolv.conf and NetworkManager profiles for where those servers came from. A dead local forwarder, an unreachable corporate resolver, or a bad DHCP DNS entry all produce the same user-visible errors with different dig hints (connection refused vs timeout).

Fix DNS on the owning layer — nmcli on NetworkManager hosts, systemd-resolved or Netplan on many Debian-family systems — and verify with getent, dig, and the application that originally failed. Keep static lab names in /etc/hosts in mind: they can still resolve while public DNS is broken, which is a useful clue that only the DNS leg needs work.

For how NSS, search domains, and dig vs getent fit together long term, continue with Linux hostname resolution.

Frequently Asked Questions

1. What causes temporary failure in name resolution on Linux?

The libc resolver could not get a usable DNS answer in time. Common causes are unreachable or wrong nameservers in resolv.conf, a stopped local DNS forwarder, outbound UDP port 53 blocked by a firewall, or NetworkManager merging DNS from several connection profiles.

2. Why does ping show the error but dig works?

ping and most applications use NSS and the libc resolver, which follows resolv.conf and nsswitch.conf. dig talks to DNS servers directly and can succeed when getent or ping fail, especially if you query a different server with dig @server.

3. Should I edit /etc/resolv.conf by hand?

On NetworkManager-managed hosts, manual edits are usually overwritten on the next connection event. Change DNS on the connection profile with nmcli or your desktop network settings instead.

4. Is temporary failure in name resolution the same as could not resolve host?

Both mean hostname lookup failed before the application opened a network connection. curl and dnf often print could not resolve host, while ping may print temporary failure in name resolution or name or service not known depending on glibc version and whether the nameserver timed out or refused immediately.

5. Can /etc/hosts still work when DNS is broken?

Yes. When nsswitch.conf lists files before dns, getent and applications resolve names that exist in /etc/hosts even when every configured nameserver is down. That pattern confirms DNS is the broken layer, not the whole network stack.
Deepak Prasad

R&D Engineer

Founder of GoLinuxCloud with more than 15 years of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, AWS, Networking, and Security. With extensive experience, he excels across development, DevOps, networking, and security, delivering robust and efficient solutions for diverse projects.

Expertise
  • Go (programming language)
  • Python (programming language)
  • DevOps
  • Computer Security
  • Cloud Computing
  • Kubernetes
  • Linux
  • Ansible (software)

Related Articles

linux

Fix Linux: Can Ping IP but Not Hostname

Fix Linux hosts that ping IP addresses but not hostnames by confirming routing, testing DNS with getent and …

8 min readlinux

Troubleshoot Default Routes in Linux

Troubleshoot Linux default route problems by reading ip route show default and ip route get, understanding …

9 min readlinux

Fix NetworkManager Device Unmanaged on Linux

Fix NetworkManager device unmanaged on Linux by reading nmcli device state and reason codes, checking …

8 min read