DNS Troubleshooting Tips for When “The Network Is Down”
Separate DNS failures from connectivity, application and routing problems quickly.
Test by name and by address
Compare access by hostname with access to a known IP address. If the address works and the name does not, name resolution becomes a strong suspect. If neither works, DNS may be only one symptom of a broader connectivity problem.
Use the exact name the application requests. Short names, search domains, split-horizon DNS, and service-discovery names can behave differently from a public fully qualified domain name.
Ask the configured resolver directly
Query the resolver and inspect the response code, record type, answer, and TTL. Internal names may intentionally differ from public resolvers, so use an alternate resolver only when that comparison makes sense.
If the resolver times out, verify reachability and handling of both UDP and TCP port 53. Large replies, retries, and DNSSEC can use TCP even when routine queries use UDP.
Identify stale or inconsistent answers
After a record change, caches can retain older data until the TTL expires. Determine whether the wrong answer originates at the authoritative source, an intermediate cache, or the client itself.
Record the resolver used, exact query, answer, and timestamp while the failure is active. DNS problems can disappear after cache refresh, making evidence collected during the event especially valuable.