Fixing DNS Resolution Failures on Linux

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.com

If 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.conf

On 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.conf

Editing 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 status

This 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.1

If 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 hosts

hosts: files dns

This 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/hosts

An 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.

Step 8: check for a DNSSEC validation failure specifically

resolvectl query google.com

If resolvectl query reports something like “authenticated: no” alongside an outright failure, or the query fails while dig +short against the same name succeeds when bypassing the local resolver, systemd-resolved’s DNSSEC validation may be rejecting a response the upstream server considers perfectly valid — a distinct failure mode from every cause covered above, since it isn’t about reachability or configuration ordering but about a cryptographic signature check failing. resolvectl status shows the current DNSSEC setting per link; temporarily testing with DNSSEC=no in /etc/systemd/resolved.conf isolates whether validation itself is the actual cause before deciding whether to leave it disabled or investigate the specific zone’s DNSSEC configuration further.

Step 9: query per-protocol detail when a name resolves inconsistently

resolvectl query --legend=yes myhost.local

A name resolving over one path but not another — succeeding via a specific interface’s DNS server but not another, or resolving via mDNS/.local but not unicast DNS — is easier to diagnose with resolvectl query’s per-protocol breakdown than with dig alone, since resolvectl shows exactly which mechanism (classic DNS, mDNS, LLMNR) actually produced the answer, rather than only the final result.

Related:

Sources: