A failure signature narrows the boundary—it does not hand you the root cause
This database is built for evidence-first diagnosis. Each signature tells you what the observation supports, what it does not prove, and which artifact should be inspected next. The goal is to stop students from mapping one symptom directly to one memorized cause.
DNS symptom-to-evidence matrix
| Observed clue | Strongest initial boundary | Best next artifact | What this proves | Do not overclaim |
|---|---|---|---|---|
| Remote IP works, hostname fails | Name-resolution branch | Direct DNS query + configured resolver | Some remote IP connectivity exists while name use fails | Does not prove which DNS component is wrong |
| DNS query times out | Resolver path/service/return path | Resolver IP, route, firewall, direct query | No usable response arrived in time | Does not prove resolver host is powered off |
| NXDOMAIN | Name/zone/authoritative data | Query spelling + authoritative data | A DNS response arrived | Not a timeout |
| SERVFAIL | Resolver/upstream/validation | Other names, alternate resolver, authoritative path | Resolver responded but could not complete resolution | Not equivalent to NXDOMAIN |
| Wrong A/AAAA returned | Record/cache/view context | Answer, TTL, authoritative source, resolver used | DNS communication succeeded | Do not blame routing before validating the mapping |
| One client fails; peers resolve | Client config/cache/local software | Resolver settings, hosts file, cache, suffix | Shared resolver path works for peers | Does not prove every client uses identical settings |
| One hostname fails; others resolve | Record/zone-specific issue | Record type, authoritative data, alternate resolver | Resolver is generally responsive | Broad resolver outage is weak fit |
| Internal names fail; public names work | Internal resolver/view/VPN path | Which resolver answered + network context | Public DNS path works | Does not prove internal namespace is reachable |
| FQDN works; short name fails | Search suffix/name construction | DNS suffix/search list + actual query generated | The FQDN itself resolves | Short and FQDN may be different queries |
| Old address persists | Cache/TTL | TTL, cache state, authoritative answer | Cached data may still be in use | Clearing cache does not fix wrong authoritative data |
| DNS succeeds; website fails | Move beyond DNS | Route, TCP/QUIC, TLS, HTTP/service evidence | Name resolution worked for the query | Does not prove the web service |
Swipe horizontally to inspect the full database.
Remote IP works, hostname fails
Interpretation: Basic tested IP reachability exists, while name resolution fails. That makes DNS a stronger branch than a total default-gateway or remote-routing failure.
DNS query times out
Interpretation: No usable DNS response arrived in time. The cause could be a wrong resolver address, route failure, DNS-specific filtering, stopped listener/service, overloaded resolver, or a broken return path.
NXDOMAIN
Interpretation: The resolver responded and reported that the queried name does not exist in the applicable DNS context. Check spelling, expected zone, delegation, and authoritative data.
SERVFAIL
Interpretation: The resolver is responding, but resolution for broken.example could not be completed. Domain-specific authoritative availability, delegation, validation, or upstream behavior becomes stronger than “the resolver is offline.”
Wrong IP address returned
Interpretation: DNS communication succeeded, but the returned mapping is operationally wrong for the expected design. Investigate authoritative data, cache state, which resolver/view answered, or split DNS.
One client fails while peers resolve normally
Interpretation: The shared DNS service is demonstrably serving peers. Client-specific resolver settings, local cache, hosts-file entries, local security software, or suffix settings deserve inspection before a broad infrastructure change.
One hostname fails while unrelated names resolve
Interpretation: A total resolver failure is a poor fit. Focus on the failed name's record type, authoritative data, delegation, alias chain, or domain-specific validation/upstream path.
Internal names fail while public names work
Interpretation: Public resolution success does not prove access to an internal namespace. Check which resolver is in use, whether internal DNS requires VPN/campus connectivity, and whether split DNS is expected.
FQDN works but short name fails
Interpretation: The fully qualified name resolves, but the short name depends on search-suffix construction. The client may be generating printer1.example.net instead of printer1.school.example.
Old address persists after a DNS change
Interpretation: Cache/TTL behavior is consistent with the observation. Clearing one client's cache can test that layer, but the recursive resolver may continue serving its cached value until refresh.
DNS succeeds but website fails
Interpretation: Basic DNS resolution succeeded. Move the investigation to the required service path: TCP/443 policy/listener, return path, TLS, or application behavior.
A and AAAA disagree operationally
Interpretation: DNS may be correctly publishing both address families while one network path is unusable. The failure is no longer “DNS returned no answer”; it is an address-family reachability problem after resolution.
CNAME chain resolves to an unexpected target
Interpretation: The alias chain resolves, but the canonical target's record does not match the intended deployment. Trace the entire chain rather than checking only the original alias.
Resolver works for small queries but fails selectively when TCP/53 is blocked
Interpretation: “DNS works sometimes” can be explained by transport-specific policy. DNS commonly uses both UDP and TCP port 53, so permitting only one transport can create selective failure.
Hosts file overrides the expected DNS answer
Interpretation: The DNS infrastructure may be correct while the client locally overrides name resolution. This is why a one-client-only failure deserves local evidence before a DNS server change.
Use “what this proves / what this does not prove”
DNS answer is correct
Proves: basic name resolution for the query.
Does not prove: route, transport, TLS, or application success.
NXDOMAIN
Proves: resolver responded with a negative name-existence answer.
Does not prove: the user queried the intended name.
One client fails
Proves: failure scope is not universal.
Does not prove: the cause is definitely client-local.
Old cached answer
Proves: a stale/older value is being served in that cache context.
Does not prove: authoritative data is still wrong.
Force the hypothesis to survive a control
| Leading hypothesis | Falsifying/control test | If the control succeeds... |
|---|---|---|
| Resolver is down | Query same resolver from another known-good client | Shift toward the failing client's config/path |
| One domain is missing | Query authoritative data / alternate resolver | Compare data source and cache/view differences |
| Routing is broken | Use numeric IP or another service to same destination/path | Total routing failure becomes weaker |
| Cache is stale | Compare authoritative answer and TTL with recursive answer | Confirm whether the discrepancy matches caching behavior |
| DNS is the only problem | Obtain correct DNS answer and retest application | If app still fails, move beyond DNS |
Swipe horizontally to use the falsifying-test table.
One changed fact should change your diagnosis
| Original evidence | Changed fact | How reasoning changes |
|---|---|---|
| One client times out | All clients now time out | Shared resolver/path/service problem becomes stronger |
| One hostname NXDOMAIN | Authoritative data now shows the record exists | Resolver cache/delegation/view inconsistency becomes relevant |
| Old address returned | TTL expired but old answer persists | Investigate resolver/authoritative configuration rather than normal cache lifetime |
| FQDN works; short name fails | Suffix list is corrected | Retest the generated short-name query and verify the intended FQDN is formed |
| DNS query succeeds; website fails | TCP/443 now succeeds | Move farther upward toward TLS/HTTP/application behavior |
Swipe horizontally to practice changed-fact diagnosis.
Use NAME → RESOLVER → RESPONSE → SCOPE → CONTROL → VERIFY
24 DNS failure-signature flashcards
These cards train students to interpret the symptom boundary, choose evidence, and avoid overclaiming.