A numeric IP and a hostname do not test the same dependency chain
When a known remote numeric IP works but a domain name fails, you have created one of networking's most useful control comparisons: the successful test bypassed DNS, while the failing test required name resolution before the client could use an address.
That does not prove the entire network is healthy. It does establish that the client had enough IP connectivity for the successful numeric test, making a total link, default-gateway, or universal routing failure less compelling. The next job is to determine exactly how name resolution failed.
Do not stop at “DNS problem.” DNS failure has several distinct forms: the configured resolver may be unreachable; the resolver may answer NXDOMAIN; the name may resolve to the wrong address; an internal zone may be invisible from the selected resolver; a cache may contain old data; a search suffix may change the queried name; or DNS may already be correct and the application may be failing later.
Follow the hostname from user input to usable service address
1. Name construction
The application supplies a hostname. Short names may be expanded using a DNS search suffix, so two clients can query different full names.
2. Resolver selection
The client uses its configured resolution path, which may come from DHCP, static settings, VPN policy, or managed/application behavior.
3. DNS answer
The resolver returns records, a negative answer such as NXDOMAIN, an error such as SERVFAIL, or no usable response.
4. Address choice
The client/application chooses among returned address data such as A or AAAA records and may follow aliases.
5. IP connection
Only after an address exists can the application attempt its actual IP/transport exchange.
6. Application service
TCP/443, TLS, proxy policy, authentication, and server state can still fail after perfect DNS resolution.
Use a DNS tool to distinguish timeout, NXDOMAIN, SERVFAIL, and wrong data
| Observed DNS result | What it means | What to investigate next |
|---|---|---|
| Timeout / no response | No usable DNS reply arrived in time | Resolver address, reachability, DNS service, filtering, actual resolver path |
| NXDOMAIN | DNS answered that the queried name does not exist from that view | Spelling, suffix, zone, authoritative data, expected DNS view |
| SERVFAIL | The server could not successfully complete the query | Upstream/authoritative resolution, validation, server health/configuration |
| Expected address | Resolution worked for that query | If service still fails, move to transport/application evidence |
| Unexpected address | Resolution works but the returned data differs from expectation | Record, cache, split DNS/view, alias chain, hosts override |
Swipe horizontally to see the full table.
This distinction prevents a common troubleshooting mistake: treating every DNS-related symptom as “the DNS server is down.” NXDOMAIN is an answer. SERVFAIL is an answer indicating unsuccessful processing. A wrong address is still an answer. Silence is a different failure class.
24 DNS failure-isolation flashcards
The deck focuses on decisions rather than memorizing definitions. Filter by diagnostic split, response type, resolver configuration, cache, record type, evidence, security, or verification.
Public names working does not prove the client is using the right DNS server
Consider a school or enterprise network where fileserver.campus.example exists only in an internal DNS zone. A client manually configured to use a public resolver may resolve public sites perfectly while the internal name returns NXDOMAIN. Internet access is not the problem; resolver selection is.
Compare the failing client's DNS server addresses with a known-good peer on the same intended network. If DHCP supplies those settings, inspect the relevant scope/options rather than manually repairing dozens of clients. If only one host differs, look for a static override, VPN-provided resolver, local policy, or other client-specific setting.
This is why “some names work” is not enough to clear DNS. Ask which namespace works, which resolver answered, and whether that resolver is authoritative or able to recurse for the requested name.
The same hostname can legitimately return different answers in different network contexts
Organizations can intentionally provide different DNS answers depending on where or how the query is made. An internal client might receive a private service address while an external resolver returns a public address—or no record at all. A VPN connection can also change the resolver path or which internal zones are available.
Therefore, comparing answers requires context. “My phone on cellular gets a different IP” does not automatically prove the corporate DNS record is wrong. Compare a working client in the same network/VPN context, note which resolver answered, and determine which address the design expects.
When a user disconnects a VPN and an internal name immediately stops resolving, the VPN may have been supplying both route access and DNS configuration. Test those dependencies separately instead of assuming the DNS server itself failed.
A short hostname may not be the same query on two clients
If the fully qualified name works but the short name fails, investigate suffix/search-list behavior before changing the host's A record. A DHCP option, VPN configuration, or manual network setting can influence the suffix applied by a client.
This distinction is especially useful because users often report “DNS is broken” when only unqualified names fail. Testing the exact fully qualified domain name removes ambiguity about what name should be queried.
An incorrect answer requires a different repair from an absent answer
Suppose portal.example resolves instantly to 10.40.8.20, but the service moved to 10.40.8.60. DNS is responsive; the data path is wrong. Determine whether the authoritative record still contains the old value or whether an intermediate/client cache is retaining it.
If authoritative data is already correct, compare TTL and cache state. If the authoritative record itself is wrong, changing random client resolver settings will not solve the source of the problem. Repair the record and then verify propagation/cache expiration as appropriate.
An alias adds another layer. A CNAME can point one name to another name, which then requires additional resolution. Inspect the chain rather than assuming the first visible name directly owns the address record.
Find the stale layer before you clear the evidence
DNS answers can be cached at several places, including local resolver components, recursive resolvers, and applications. If one client gets an old address while a direct query to the expected resolver returns the new address, local state becomes more interesting. If every client using the same recursive resolver receives the old value, investigate that resolver's cache and the record's TTL/history.
Do not make “flush DNS” the first universal repair. Clearing a cache may temporarily fix the symptom while hiding why stale data persisted or which cache held it. Record the old answer, resolver used, TTL when available, and authoritative/current answer before changing state.
TTL is a caching lifetime, not a guarantee that every application behaves identically. The key troubleshooting question is whether the answer being used matches the answer that should currently be used.
Do not reduce DNS troubleshooting to “UDP port 53”
Traditional DNS commonly uses both UDP and TCP on port 53 depending on the exchange. A troubleshooting rule that tests only UDP can therefore miss legitimate TCP-dependent behavior. Modern environments can also introduce encrypted DNS mechanisms or managed resolver paths that do not look like a simple client-to-configured-server UDP/53 exchange.
For AP-level reasoning, the durable lesson is to identify the actual dependency from the evidence rather than memorize one transport assumption. If a direct DNS query fails, determine which resolver was queried and how the client is expected to reach it. If application behavior conflicts with the operating system's apparent resolver settings, investigate whether the application or policy uses another resolution path.
Correct resolution is the handoff point to transport and application troubleshooting
This output should change your hypothesis. If 10.40.8.60 is the expected address and the query is timely, continuing to change DNS settings has diminishing value. The browser must still establish the required transport connection, pass firewall/proxy policy, complete TLS where applicable, and interact with a working service.
Ping can add a control, but remember its limits: ICMP Echo and TCP/443 are separate traffic types. A server may answer one and deny the other. Use Ping Command Guide to keep that evidence boundary clear.
Turn combinations of evidence into the next best test
| Numeric IP | DNS query | Application | Best interpretation |
|---|---|---|---|
| Works | Times out | Hostname fails | Resolver path/service is a strong lead; verify configured resolver and reachability |
| Works | NXDOMAIN | Hostname fails | Resolver answered; verify name, suffix, zone, DNS view, and record existence |
| Works | Wrong IP | Fails/wrong destination | Investigate record, cache, alias chain, or split DNS |
| Works | Expected IP | Fails | Move beyond basic DNS to port/policy/TLS/service evidence |
| Fails | Times out | Fails | Do not isolate DNS yet; lower-layer/routing reachability may also be broken |
Swipe horizontally to see the full table.
Verify the original hostname workflow, not merely the control that already worked
If the repair was a DHCP DNS option, confirm the client actually receives the intended resolver configuration. Query the original hostname and verify the expected address. Then repeat the application operation that originally failed. A numeric ping succeeding again is useful as a lower-layer control, but it cannot prove the DNS repair worked because it still bypasses DNS.
Good verification also checks for collateral damage. Resolve another known-good name, confirm an intentionally nonexistent name behaves appropriately, and make sure the fix did not merely hard-code one host while leaving the resolver problem intact.
For a record correction, verify from the resolver/client context that mattered to the incident. A correct answer from an authoritative server is important, but the affected client must ultimately receive and use the correct data.
State what the control proves, classify the DNS result, and name the discriminating next step
A strong response might read: “The client successfully reaches a known remote numeric IP, so a complete loss of remote IP forwarding is less likely. A direct query to the configured DNS resolver times out, so the strongest current lead is the resolver path or resolver service rather than an NXDOMAIN condition. Compare the DNS server address with a working client and test reachability/service response from the failing client.”
For a different artifact: “The resolver returns the expected address for the hostname, so basic DNS resolution succeeds for that query. The application still fails, so changing DNS is not supported by the current evidence. Test the required transport port and inspect firewall, proxy, TLS, and server-service state.”
The goal is not to name DNS whenever a hostname appears in the symptom. The goal is to identify exactly which stage of name-to-service delivery failed.
A hostname can resolve correctly and still expose a path problem that a single numeric-IP test never exercised
A particularly important control mistake is comparing an IPv4 numeric ping with a hostname that resolves to both IPv4 and IPv6 addresses, then assuming the two operations test an identical path. They may not. The application or operating system can prefer an IPv6 address while the numeric control tested only IPv4.
If a name returns an A record and an AAAA record, inspect which address the failing operation actually uses. An IPv4 path can be healthy while IPv6 addressing, routing, firewall policy, or return reachability is broken. In that case DNS may be accurately returning both records; the failure occurs after resolution on one address family.
This is another reason to record the resolved address rather than merely saying “the name resolved.” Compare the address family and destination used by the working control with the one selected by the failing application.
The DNS server can be correct while one client still uses the wrong name-to-address mapping
Local name-resolution mechanisms can sometimes take precedence over or supplement DNS. A hosts-file entry is a classic example: one workstation can map a hostname to an obsolete address even though direct DNS queries from the network return the current address.
If only one device behaves differently, compare what the application or ordinary system resolver uses with a direct DNS query. If the direct query returns the correct address but the ordinary hostname operation uses another address, inspect local overrides, caches, application-specific resolver behavior, VPN/security software, and policy before editing the authoritative DNS zone.
The diagnostic principle is source-of-truth tracing. Determine where the wrong answer entered the chain. Fixing an authoritative record that was already correct adds risk and does nothing to remove a client-side override.