Linux DNS Troubleshooting: Prove It Is DNS Before Changing Resolvers
If IP connectivity works but names do not resolve, DNS is a strong suspect. Prove that boundary before editing resolver files or hard-coding a public DNS service.
Short answer
A Linux DNS problem is likely when network routing works by IP address but hostnames fail to resolve. Prove that separation first. Then identify which component owns DNS configuration, such as NetworkManager, systemd-resolved, a VPN client or a manually configured resolver, before editing files.
Separate DNS from general connectivity
| Test result | Likely interpretation | Next step |
|---|---|---|
| No address on interface | Not a DNS problem yet. | Fix link/connection/DHCP state first. |
| Address exists but no default route | Routing problem. | Inspect connection and gateway. |
| Known reachable IP works; hostname fails | DNS becomes likely. | Inspect resolver configuration and query behavior. |
| Hostname resolves but application still fails | DNS succeeded. | Inspect port, firewall, proxy, TLS or application state. |
Know who owns resolv.conf
On many modern systems, /etc/resolv.conf may be generated or linked to a resolver service. Editing it manually can be temporary or conflict with NetworkManager, systemd-resolved, a VPN or DHCP. Inspect the system’s configured network stack and make the change through the owning component.
Use a temporary comparison as a diagnostic, not a permanent cure
Testing another DNS server can tell you whether the current resolver path is involved, but permanently hard-coding a public resolver can bypass split-DNS, VPN, local-domain or privacy requirements. Once the test isolates the problem, repair the intended resolver configuration.
DNS caches can hide changes
Applications, local resolver services and upstream resolvers can cache answers. After changing a record or resolver configuration, distinguish a stale cached answer from a connectivity failure. Use the resolver’s supported query and cache controls rather than deleting arbitrary files.
Useful gear for this task
Official references
For current behavior and version-specific details, use the relevant upstream documentation alongside this guide.
Frequently asked questions
How do I know whether a Linux network problem is DNS?
If the system can reach an IP address but cannot resolve a hostname, DNS becomes a strong suspect. Confirm the route and basic connectivity first so a general network failure is not mislabeled as DNS.
Should I permanently set a public DNS server as the first fix?
No. A temporary resolver test can help isolate the problem, but permanent changes should respect NetworkManager, systemd-resolved, a VPN client or another component that actually owns resolver configuration.