“DNS failure” is a symptom family, not a diagnosis
A resolver that never answers, a resolver that returns NXDOMAIN, a resolver that returns the wrong address, and an application that fails after receiving the correct address are four different incidents. They should not receive the same repair.
Use AP Networking DNS Resolution Practice Test to test the resolution path behind the symptom. The sets compare direct authority queries with ordinary recursion, separate NXDOMAIN from NODATA and timeouts, and require the resolver and query context before choosing a correction.
The fastest DNS troubleshooting begins by recording the exact query, resolver, response status, returned records, and client context before changing configuration. A timeout says no usable response arrived. NXDOMAIN says DNS answered negatively. SERVFAIL says the server could not successfully complete the query. An unexpected IP says resolution happened, but the data or DNS view may not match the intended service.
This evidence-first approach prevents destructive troubleshooting. Rebooting routers, flushing every cache, or replacing DNS server addresses can erase clues without identifying which stage failed.
Use numeric-IP reachability to decide whether DNS deserves to be the first branch
If a client reaches a known remote numeric IP but cannot use a hostname, the successful test bypassed DNS and provides a valuable control. It supports enough IP connectivity for that specific exchange and makes a universal link, gateway, or routing outage less likely.
If the numeric IP fails too, do not force the incident into a DNS-only explanation. Check the client's addressing, prefix, default gateway, local link, routing, security policy, and upstream reachability. DNS can fail at the same time as a broader outage.
The dedicated Can Ping IP but Not Domain Name guide develops this control comparison in detail. Here, the important point is sequencing: establish whether name resolution is the added dependency that separates working from failing behavior.
Identify who the client asks before you judge the answer
Client configuration
DNS server addresses can come from DHCP, static settings, VPN software, enterprise policy, or other resolver mechanisms.
Recursive resolver
The client commonly asks a resolver that can answer from cache or perform additional DNS resolution on the client's behalf.
Authoritative data
Authoritative DNS is the source for records in its zones. A correct authoritative record can still be hidden temporarily by stale cached data elsewhere.
Always record which resolver answered. Two clients can query the same name and receive different results because they use different resolvers, different DNS views, or different network/VPN contexts. “It works on my phone” is weak evidence unless you know the phone is asking the same DNS system under comparable conditions.
Timeout, NXDOMAIN, SERVFAIL, and wrong data point in different directions
| Result | What the evidence says | High-value next check |
|---|---|---|
| Timeout / no usable response | The expected DNS reply did not arrive in time | Configured resolver, path to resolver, DNS service, filtering, actual resolver method |
| NXDOMAIN | The DNS system answered that the queried name does not exist from that view | Exact spelling/FQDN, suffix, zone, record existence, internal/external view |
| SERVFAIL | The server could not successfully complete the query | Resolver/authoritative resolution, validation, upstream dependencies, server state |
| Expected record | Resolution succeeded for this query | If app fails, test transport/policy/TLS/service |
| Unexpected record | DNS answered, but data differs from expectation | Authoritative record, cache, CNAME chain, split DNS, local override |
Swipe horizontally to see the full table.
Control the resolver variable with an explicit query
A DNS-specific tool is more informative than relying on a browser error or ping alone because it can show the resolver and returned DNS data. If 10.20.0.53 is the intended resolver and 10.40.8.60 is the expected address, basic resolution succeeded for this query.
Now imagine the same client is configured for 10.20.0.99, while every working peer uses 10.20.0.53. That difference is more actionable than the generic statement “websites do not load.” Determine whether the wrong setting came from DHCP, a static override, VPN configuration, or policy.
Use the nslookup Command Guide to practice reading resolver and answer evidence.
24 DNS troubleshooting flashcards
These cards test failure isolation and next-step decisions. Filter by triage, resolver, responses, records, cache, DNS views, suffixes, transport, IPv6, application handoff, evidence, or verification.
A negative answer proves the resolver participated—it does not prove the user typed the intended FQDN
NXDOMAIN is fundamentally different from a timeout because DNS answered. Before creating a missing record, verify the exact queried name. A user may type a short hostname that depends on a search suffix. Two clients with different suffix lists can therefore turn the same visible input into different DNS queries.
If the fully qualified name works while the short name fails, investigate search-domain configuration rather than changing the valid A/AAAA record. If an internal-only name returns NXDOMAIN from a public resolver, compare the resolver selection with a working internal client.
Successful DNS can still direct traffic to the wrong endpoint
An A record can return an obsolete IPv4 address; an AAAA record can return an IPv6 address for a path that is not actually usable; a CNAME can lead through an alias chain to unexpected data. The resolver is responsive in all of these cases, so “restart DNS” is not a diagnosis.
Compare the returned records with the intended service design and determine where the wrong value originates. If authoritative DNS contains the old address, repair the source record. If authoritative data is correct but one resolver or client returns the old value, caching or a local override becomes more likely.
Record type matters. A client may receive both A and AAAA records. A successful IPv4 numeric test does not prove the IPv6 path selected by an application works. If the hostname operation fails over IPv6 while IPv4 succeeds, DNS can be perfectly accurate while IPv6 routing, filtering, or return reachability is broken.
Find the stale layer before you flush it
DNS data can be cached by clients, applications, recursive resolvers, and other local components. TTL helps explain how long a record is intended to remain cacheable, but the diagnostic goal is to identify which layer is serving the stale answer.
If one endpoint returns an old IP while peers using the same resolver receive the current IP, inspect client/application cache or local overrides. If every client using one recursive resolver receives the old value while another resolver returns the new one, the shared resolver's cache becomes more interesting.
Capture the stale address, resolver, TTL when available, and comparison result before clearing state. A blind cache flush may make the symptom disappear while eliminating the evidence needed to understand why it occurred.
Different answers can be intentional, so compare clients in the same DNS context
Split DNS can present different records depending on whether the query comes from an internal or external context. An internal user may receive a private address while an external user receives a public address. A VPN can change both resolver selection and access to internal DNS zones.
Therefore, two different answers do not automatically mean one server is corrupt. Ask which resolver answered, whether each client was internal/external/on VPN, and what the design expects. A meaningful control is a known-good client in the same network context as the failing client.
This also explains a common pattern: public names resolve normally while one internal namespace fails. If the client is using a public resolver, the public resolver may be functioning exactly as designed—it simply has no access to the organization's private DNS view.
One client can bypass correct DNS data with local state
A hosts-file entry or other local name-resolution override can make a single machine use an obsolete address even when the DNS server returns the correct value. This is why direct DNS evidence and actual application behavior can appear contradictory.
If a direct query to the intended resolver returns the expected address but the system/application consistently uses another address, inspect local caches, hosts entries, application-specific resolution, VPN/security software, and policy. Do not edit authoritative DNS merely to make it match one misconfigured endpoint.
The key question is where the wrong mapping entered the resolution chain. Trace the answer back to its source rather than changing the first DNS component you can access.
A resolver address in the configuration does not prove the client can successfully query it
Traditional DNS commonly uses UDP and TCP on port 53 depending on the exchange. Troubleshooting that assumes “DNS is only UDP” can miss valid TCP-dependent behavior. Modern environments can also use encrypted DNS or managed resolver mechanisms, so identify the actual expected resolver path when observations conflict with simple interface settings.
When queries time out, test whether the client can reach the resolver's network address and whether DNS service traffic is permitted. But keep protocol boundaries clear: a resolver answering ping does not prove its DNS service is listening or allowed, just as a DNS service can be available on a host that blocks ICMP Echo.
This is where Network Command-Line Tools should be used as a coordinated evidence set rather than a collection of isolated commands.
Once the expected address is returned, DNS may have finished its job
If 10.40.8.60 is the expected service address and the query completes normally, repeated DNS changes are poorly supported. The application still needs a route to that address, the required transport port, firewall/proxy permission, TLS behavior where applicable, and a functioning server process.
Use a service-specific test next. A successful ping would add ICMP reachability evidence, but it still would not prove TCP/443 is permitted. Conversely, failed ping does not prove HTTPS is unavailable because ICMP can be filtered independently.
One client, one VLAN, one resolver, or everyone? Scope often reveals the failing layer
One client
Compare static settings, cache, hosts overrides, VPN state, local policy, and resolver selection with a working peer.
Many DHCP clients
Inspect shared DHCP DNS options, the distributed resolver addresses, and whether affected leases/configuration changed together.
One internal zone
Compare DNS view, delegation/authoritative data, suffix behavior, and whether the selected resolver can resolve that namespace.
All names through one resolver
Investigate that resolver's service, network reachability, upstream dependencies, configuration, and policy.
Scope is a high-information variable because shared failures often point toward shared dependencies. Avoid repairing individual endpoints when every affected endpoint inherited the same bad resolver setting.
Verify the repaired stage and the user's original operation
| Repair | Immediate verification | End-to-end verification |
|---|---|---|
| Corrected DHCP DNS option | Client receives intended resolver address | Original hostname resolves and application succeeds |
| Corrected authoritative record | Authoritative/expected resolver returns intended data | Affected client eventually receives/uses correct address |
| Removed stale local override | System resolver uses expected DNS answer | Original application reaches intended service |
| Restored resolver service/path | Direct queries receive valid responses | Multiple expected names and original workflow succeed |
Swipe horizontally to see the full table.
Add a negative control when useful. An intentionally nonexistent name should not mysteriously resolve to the repaired service, and a known-good unrelated name should continue working. Verification should prove both that the targeted failure is fixed and that the repair did not simply mask the symptom.
Write the diagnosis as a chain of evidence, not a label
Example: “The client reaches a known remote numeric IP, so complete remote IP failure is less likely. A direct query to the configured resolver times out, while a working peer on the same network uses a different DNS server. The strongest current hypothesis is incorrect resolver configuration on the failing client. Compare how the DNS setting was assigned and correct the source of that configuration before retesting the hostname.”
Another example: “The resolver returns the expected A record immediately, so basic DNS resolution succeeds for the query. The HTTPS application still fails. DNS changes are not supported by the current evidence; test TCP/443 reachability, policy, TLS, and server state.”
This format—observation, inference, limitation, next discriminating test—turns DNS troubleshooting into defensible network analysis.
Build the DNS troubleshooting chain around related evidence tools
Related troubleshooting deep dive
For a narrower evidence-based scenario, use DNS Problem or Routing Problem? How to Tell from the Evidence. It includes a free interactive reasoning activity and step-by-step diagnostic evidence.