Fixing DNS Resolution Failures on Linux
Ping by IP works but hostnames don't resolve. Here's a systematic path through resolv.conf, systemd-resolved, and nsswitch.conf to find where resolution is actually breaking.
DNS resolution failing while raw IP connectivity works fine (ping 8.8.8.8 succeeds, ping google.com doesn’t) narrows the problem to name resolution specifically — this walks through the layers involved, in the order that actually makes sense to check them.
Step 1: confirm the problem is really DNS and not general connectivity
ping -c2 8.8.8.8
ping -c2 google.comIf the IP-based ping works but the hostname-based one doesn’t, the network path itself is fine and the problem is isolated to name resolution.
Step 2: check which resolver is actually configured
cat /etc/resolv.confOn modern systemd-based distributions, this file is very often a symlink managed by systemd-resolved rather than something you should edit directly:
ls -la /etc/resolv.confEditing a systemd-resolved-managed resolv.conf directly typically gets overwritten the next time the service updates it — a common source of “I fixed it and it broke again” confusion.
Step 3: check systemd-resolved’s actual status, if it’s in use
resolvectl statusThis shows which DNS servers are actually being used per-interface, and whether systemd-resolved itself considers itself healthy — a much more direct signal than inferring resolver state from resolv.conf contents alone.
Step 4: test resolution directly against a specific DNS server
dig @8.8.8.8 google.com
nslookup google.com 1.1.1.1If a query direct to a known-good public DNS server (bypassing whatever resolver is normally configured) succeeds, the problem is in the local resolver configuration or the path to your configured DNS servers — not DNS itself.
Step 5: check nsswitch.conf for how name resolution is ordered
cat /etc/nsswitch.conf | grep hostshosts: files dnsThis line controls whether /etc/hosts or DNS is consulted first (and whether both are consulted at all) — a misconfigured or out-of-order nsswitch.conf can cause resolution to fail or behave unexpectedly even when the DNS servers themselves are perfectly reachable.
Step 6: check for a stale or incorrect entry in /etc/hosts
cat /etc/hostsAn incorrect static entry for a hostname in /etc/hosts takes precedence over DNS in the default nsswitch.conf ordering — a specific hostname failing (or resolving to the wrong address) while others work normally often traces back to exactly this.
Step 7: check for a firewall blocking outbound DNS traffic
sudo iptables -L -n | grep -i "53"DNS primarily uses UDP port 53 (with TCP as fallback for larger responses) — a firewall rule blocking this port produces exactly the “IP connectivity fine, hostname resolution fails” symptom this whole troubleshooting path starts from.
Why checking systemd-resolved’s own status beats editing resolv.conf blindly
On any system where systemd-resolved manages DNS, editing /etc/resolv.conf directly is treating a generated, frequently-overwritten file as the source of truth — resolvectl status shows what’s actually configured and considered active, which is the far more reliable starting point for diagnosing resolution failures on these systems.