Technical guide

IP Address Works but Hostname Doesn’t? A DNS Troubleshooting Guide

By Subnetica · Published August 24, 2026 · Updated August 24, 2026

If ping 1.1.1.1 works but ping example.com fails, name resolution is a strong suspect. It does not prove every other component is healthy: the application may use a different resolver, IPv6 may fail separately, or the name may legitimately have no usable address.

Follow the resolver path

IP works↓DNS reachable?↓Direct query?↓Correct answer?↓OS/app consumes it?

Move from the application symptom toward the DNS server, then back through the OS resolver and cache.

Start with the exact failure and record whether it is consistent, intermittent, or specific to one application. Ping is not a complete DNS or HTTPS test: it may use a different address family, and many hosts deprioritize or block ICMP.

1. Inspect configured DNS and the host resolver

cat /etc/resolv.conf
resolvectl status
getent hosts example.com
nslookup example.com

/etc/resolv.conf may list real recursive resolvers or a local stub such as 127.0.0.53. With systemd-resolved, resolvectl status shows per-link DNS servers, search domains, and routing domains; the stub forwards queries according to that state. NetworkManager, a VPN client, containers, or a manually managed file can change the effective configuration.

getent hosts asks the system’s Name Service Switch path, which is closer to what many applications use. nslookup is a convenient diagnostic client. Neither necessarily reproduces every application’s behavior: applications may use a library, proxy, DNS-over-HTTPS, container resolver, or cached result.

2. Query the resolver directly

dig example.com
dig @1.1.1.1 example.com
dig A example.com
dig AAAA example.com
dig +trace example.com

First query the configured resolver, then query a known resolver directly if policy permits. If the direct query works but the configured resolver times out, focus on local configuration, reachability, filtering, or the resolver itself. If both return an error, distinguish an authoritative DNS problem from local transport. +trace follows delegation and is not the same as asking a recursive resolver for its cached answer.

Interpret the response

NXDOMAIN: the responding DNS system says the queried name does not exist. Check spelling, search suffixes, and the zone.
SERVFAIL: the resolver could not complete the lookup; validation, upstream, delegation, or transient server problems are possibilities.
REFUSED: the server understood the request but will not answer it under its policy.
Timeout: no usable response arrived. Check path, firewall, server load, and UDP/TCP behavior.

3. Check search domains, A/AAAA, and reachability

A short name such as api may be expanded with search domains. A bad search list can make a short name fail while its fully qualified form works. Compare the exact name the application uses with the result of a fully qualified query.

Compare A and AAAA records. A host may receive a working IPv4 address and an unreachable IPv6 address, or an application may prefer IPv6. Test both families explicitly rather than assuming one ping describes all traffic.

ip route get 192.0.2.53
ping -c 3 192.0.2.53

tcpdump -ni any port 53

Firewalls, VPN policies, container NetworkPolicy, and captive portals can block DNS while allowing ordinary IP traffic. Large DNS responses may use TCP after truncation, so allowing only UDP is not always sufficient.

4. Separate caches and server roles

A recursive resolver follows delegation and caches answers. An authoritative server serves data for zones it hosts; it is not automatically a general recursive resolver. A stale local cache, negative cache entry, or VPN-specific resolver can explain different answers on different hosts. Flush caches only after recording evidence, and identify which cache you changed.

For intermittent failures, measure latency and failure rate over time, compare multiple resolvers, and look for one bad path, an overloaded resolver, packet loss, or upstream timeout. One successful dig does not clear a flaky resolver.

Kubernetes and CoreDNS

Inside a Kubernetes pod, /etc/resolv.conf commonly points at the cluster DNS Service and includes a search list for pod and service domains. CoreDNS forwards names outside the cluster according to its configuration. Check the pod resolver file, DNS Service and endpoints, CoreDNS logs, and NetworkPolicy—not only the node’s resolver. A node can resolve a name while a pod cannot because they have different network namespaces and DNS paths.

Practice a complete DNS diagnosis

Use the DNS records and resolution curriculum to connect recursive, authoritative, and client behavior. The published DNS lab gives you a place to practice service and resolver evidence. Then apply this workflow to a real host: capture the query, identify the resolver, ask it directly, compare A/AAAA and search behavior, and test the application path. Subnetica’s troubleshooting curriculum is the broader companion.