Fix Linux: Can Ping IP but Not Hostname

ping 192.168.56.220 gets replies, but ping google.com dies with Name or service not known. Routing and link-layer reachability are fine — the gap is almost always DNS: the system cannot map the hostname to an IP before it sends the first packet.

The checks below confirm that split, find which nameserver or NSS step fails, and put a working resolver back in place.

Why IP works but hostname does not

Ping and most network tools need an IP address before they open a socket. When you type a hostname, the application asks the resolver first. When you pass a literal IP, that step is skipped.

If both IP ping and hostname ping fail, start with network is unreachable instead. If the hostname error mentions temporary failure in name resolution, see temporary failure in name resolution for the same resolver path with different tool wording.

Confirm IP connectivity

Pick an IP you care about — a LAN peer, your gateway, or a public resolver. Skip hostnames entirely:

ping -c2 -W2 192.168.56.220

PING 192.168.56.220 (192.168.56.220) 56(84) bytes of data.
64 bytes from 192.168.56.220: icmp_seq=1 ttl=64 time=3.14 ms
64 bytes from 192.168.56.220: icmp_seq=2 ttl=64 time=2.98 ms

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

Replies mean L3 to that address works. Some networks block ICMP to the internet; if public IPs show 100% loss but ip route get still prints a gateway, treat routing as OK and keep focusing on DNS.

Confirm the kernel would route a remote address:

ip route get 8.8.8.8

8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

A via and dev line means a route exists. RTNETLINK answers: Network is unreachable means fix routing first — hostname tests will not help until that is cleared.

Now reproduce the hostname failure:

ping -c1 -W3 google.com

ping: google.com: Name or service not known

IP works, name does not — stay on DNS for the rest of this guide.

Test DNS with dig and getent

Use two tools: getent follows NSS (what ping uses) and dig talks to DNS servers directly.

Ask NSS for the name:

getent hosts google.com

When DNS is broken, there is no output and the exit status is 2:

getent hosts google.com

No output means NSS did not resolve the name through files or dns.

Query the nameservers listed in resolv.conf:

dig +time=2 +tries=1 google.com A

;; communications error to 192.168.56.99#53: timed out

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

timed out or connection refused on the SERVER address points at a dead or wrong nameserver in resolv.conf.

To see whether public DNS is reachable while local resolv.conf is wrong, query a resolver directly:

dig +short @8.8.8.8 google.com A

142.251.220.110

When dig @8.8.8.8 works but getent and ping fail, the network path to DNS is fine and the nameservers configured on the host are the problem. For more dig flags, see dig and host commands.

Check /etc/resolv.conf

Applications read the nameserver list NetworkManager or systemd-resolved wrote here:

cat /etc/resolv.conf

Broken example — a single unreachable address on the lab subnet:

# Generated by NetworkManager
search lab.example
nameserver 192.168.56.99

The nameserver lines are what matter for internet names. The search line appends those domains to short hostnames (server1 becomes server1.lab.example).

If every nameserver is wrong or down, every public hostname fails while IP ping still works. Hand-editing this file on NetworkManager hosts usually does not last — change DNS on the connection profile instead.

Check NetworkManager and systemd-resolved DNS

On NetworkManager systems, see which DNS addresses an interface advertises — replace enp0s8 with yours from nmcli device status:

nmcli dev show enp0s8 | grep IP4.DNS

IP4.DNS[1]:                             192.168.56.99

That should match the nameserver entries in resolv.conf for that profile. Multiple active connections can merge several DNS lines; one bad forwarder in the list can break resolution even when another profile has valid servers.

Inspect the connection profile:

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

ipv4.dns:                               192.168.56.99
ipv4.ignore-auto-dns:                   yes

ipv4.ignore-auto-dns: yes means only manual servers apply — DHCP cannot override a broken entry.

On Ubuntu and Debian where resolvectl status shows Current DNS Server and resolv.conf lists 127.0.0.53, change upstream DNS through Netplan, nmcli, or resolvectl — not by overwriting the stub file. Steps live in refresh network on Ubuntu.

Check NSS resolution order

NSS decides whether to read /etc/hosts before querying DNS. Read the hosts: line:

grep '^hosts:' /etc/nsswitch.conf

hosts:      files  dns myhostname

files before dns means local static names win. Test a name that exists only in hosts when DNS is down:

getent hosts vm2.lab.example

192.168.56.117  vm2.lab.example vm2

If that succeeds but getent hosts google.com does not, DNS alone is broken — not NSS order. If short names fail but getent hosts server1.lab.example works, check the search line in resolv.conf and whether the full FQDN is required.

Full NSS and search-domain detail is in Linux hostname resolution.

Fix the DNS problem

Point the active connection at reachable resolvers. Replace enp0s8 and the gateway-side DNS addresses with values from your network — public resolvers are shown as an example:

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:

sudo nmcli connection up enp0s8

Confirm the file updated:

cat /etc/resolv.conf

# Generated by NetworkManager
search lab.example
nameserver 8.8.8.8
nameserver 1.1.1.1

When your site uses an internal forwarder (for example dnsmasq on the gateway), set that IP instead of public DNS and make sure the forwarder service is running on the target host.

If several connections merge bad DNS, fix or disconnect unused profiles, or set ipv4.ignore-auto-dns yes only on the profile that should own resolver settings. After changes, restart or reload network only if nmcli connection up did not refresh resolv.conf.

Verify hostname resolution

Re-run the same lookups that failed.

NSS path:

getent hosts google.com

142.251.220.110 google.com

Direct DNS:

dig +short google.com A

142.251.220.110

Application-style check:

ping -c1 -W3 google.com

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.2 ms

When getent, dig, and ping all resolve the same name, package managers and curl should work again for that host.

Troubleshooting

References

• resolver(5) — resolver configuration and search list
• resolv.conf(5) — nameserver file format
• nsswitch.conf(5) — NSS source order
• dig(1) — DNS lookup utility
• NetworkManager IPv4 settings — dns and ignore-auto-dns properties

Summary

When you can ping an IP but not a hostname, routing is usually fine and the resolver is not. The quick proof is side by side: ping 192.168.56.220 succeeds, ping google.com prints Name or service not known, and ip route get still shows a valid path to remote addresses.

Walk DNS in order — getent for what applications use, dig for whether your listed nameservers answer, resolv.conf and nmcli for where those servers came from, and nsswitch.conf when only some names fail. The common fix on NetworkManager hosts is setting ipv4.dns to reachable resolvers on the active connection profile, not chasing gateway or interface problems that IP ping already ruled out.

If dig @8.8.8.8 works while getent does not, you do not have an internet outage — you have the wrong nameservers configured locally. Point resolv.conf at DNS that answers, verify with ping to a hostname, and move on. For deeper NSS and search-domain behavior, continue with Linux hostname resolution.