One nslookup result can answer four different questions—if you read the fields separately
A DNS test is most useful when you separate who was asked, what name and record type were requested, what response came back, and whether that response matches the network's intended DNS design. Collapsing all four into “DNS works” or “DNS is broken” throws away information.
That last step is crucial. A public resolver returning NXDOMAIN for a private organizational hostname may be behaving perfectly. The client may simply be using the wrong resolver.
Start by identifying the resolver actually queried, not the resolver you assume the client uses
C:\> nslookup portal.campus.example Server: dns1.campus.example Address: 10.30.2.53 Name: portal.campus.example Address: 10.60.20.15
The Server and server Address identify the resolver used for this lookup. The lower Name/Address pair is the answer for the queried hostname. Those are different roles. Students often see two addresses and treat them as interchangeable.
Compare the resolver with ipconfig /all or the intended DHCP/static configuration. A client can receive a perfectly valid DNS answer from the wrong resolver and still fail later on private names that resolver does not know.
A correct DNS answer proves name-resolution evidence—not TCP, TLS, authentication, or application health
Suppose nslookup app.campus.example returns 10.60.20.15, exactly as expected. That supports the conclusion that the queried resolver supplied the expected DNS data for that query. It does not prove that 10.60.20.15 is reachable, that TCP/443 is permitted, that a web server is listening, that TLS negotiation succeeds, or that the application accepts the user's request.
This boundary prevents a common troubleshooting loop: repeatedly flushing DNS after DNS has already produced the expected current answer. Once the DNS dependency is supported, move to the next unresolved layer. The Network CLI Output Practice page trains that cross-command transition.
A timeout and NXDOMAIN describe fundamentally different events
Timeout
DNS request timed out. timeout was 2 seconds.
No usable response arrived in time. Possible branches include resolver reachability, resolver service, DNS filtering, routing, packet loss, or an incorrect server address.
NXDOMAIN
*** dns1 can't find lab.campus.example: Non-existent domain
A DNS exchange completed far enough to return a negative answer indicating the queried name does not exist in that DNS context.
Do not troubleshoot these identically. A clean NXDOMAIN makes cable replacement or generic “Internet outage” reasoning weak. Check spelling, exact namespace, search-suffix assumptions, zone/record existence, and whether this client is asking the correct resolver.
A name can exist even when the requested record type has no data
DNS reasoning is richer than “address or NXDOMAIN.” A name may exist while a particular record type is absent. For example, a host can have an A record but no AAAA record. That is different from saying the hostname itself does not exist.
When a question specifies a record type, preserve that detail in your conclusion: “The resolver returned no AAAA data for this name” is more precise than “DNS failed.” Precision matters because applications can have different IPv4/IPv6 behavior.
Specifying a resolver turns nslookup into an A/B test
C:\> nslookup files.campus.example 10.30.2.53 Name: files.campus.example Address: 10.80.4.20 C:\> nslookup files.campus.example 8.8.8.8 *** can't find files.campus.example: Non-existent domain
If 10.30.2.53 is the organization's intended internal resolver and the second address represents a public resolver, these results can be completely consistent with split/internal DNS. The comparison does not show that the public resolver is defective; it shows that the two resolvers have different DNS knowledge.
If the failing client is configured to use the public resolver, you now have a mechanism that explains why public sites can resolve while the private hostname fails. See Wrong DNS Server Symptoms for that failure pattern.
Two intended resolvers returning different answers can expose cache, replication, or change-timing problems
Resolver 10.30.2.53 → app.example = 192.0.2.40 Resolver 10.30.2.54 → app.example = 192.0.2.90
Do not immediately label one answer “bad.” First establish the expected current record and when it changed. If .90 is the new address, .40 may reflect cached data whose TTL has not expired, a resolver that has not refreshed, or another intentional view. If both resolvers are supposed to serve the same current view after the relevant cache interval, the inconsistency becomes more suspicious.
The information gain comes from preserving which resolver returned which value and when. “DNS sometimes gives the wrong IP” loses the evidence needed to isolate the source.
Interpret the record in the context of the service instead of treating every DNS answer as an IP address
| Record | What it represents | Useful question | Common overclaim |
|---|---|---|---|
| A | Name → IPv4 address | Which IPv4 endpoint is returned? | “The website works.” |
| AAAA | Name → IPv6 address | Which IPv6 endpoint is returned? | “IPv4 and IPv6 both work.” |
| CNAME | Alias → canonical name | Where does the alias chain lead? | “This alias itself is the final server address.” |
| MX | Mail exchanger + preference | Which hosts receive mail for the domain? | “The web server is this MX host.” |
| NS | Authoritative name-server information | Which servers are authoritative for the zone/delegation? | “This must be the client's recursive resolver.” |
| TXT | Text data used by many mechanisms | Does the expected text record exist? | “TXT always means one specific service.” |
Swipe horizontally to see the full table.
A CNAME can make the first answer only one step in the resolution path
portal.example canonical name = edge.example.net Name: edge.example.net Address: 203.0.113.25
The alias and final address are distinct pieces of evidence. If an expected alias points somewhere unexpected, investigate the record chain. If the alias is correct but the final address is stale, the relevant record/cache may be farther down the chain.
For exam reasoning, identify which name owns which record instead of summarizing the entire output as “DNS gave 203.0.113.25.”
A stale answer can persist after an authoritative change without proving the resolver is permanently misconfigured
DNS TTL tells caches how long record data may be retained before refresh, subject to resolver and client behavior. After a record change, different caches can temporarily hold different generations of the answer. That makes time an important troubleshooting dimension.
Record the resolver, returned value, query time, expected current value, and relevant TTL/change timing. Flushing a client cache before capturing the old answer can erase exactly the evidence needed to show where stale data lived.
“Works on campus, fails at home” can be a DNS-design clue rather than random intermittency
An internal hostname may intentionally resolve only through organizational DNS. On campus, DHCP or another configuration mechanism points the client to a resolver that knows the private zone. At home, a public or home-router resolver may return NXDOMAIN.
The discriminating test is not simply “try again.” Record the resolver used in each location and query the exact same name. If the resolver context changes with the symptom, that correlation can explain the location-dependent behavior.
A short hostname and a fully qualified domain name are not always equivalent tests
A user may type printer7 while the intended full name is printer7.lab.campus.example. Operating systems can apply DNS search suffixes to short names. A direct nslookup test using a different form can therefore ask a different question than the application did.
When troubleshooting ambiguous names, record the exact name the application uses, the client's suffix configuration, and the fully qualified name. This avoids declaring a zone broken when the real issue is name construction.
A known-good query can tell you whether the resolver is broadly responsive while one target name fails
If the target returns NXDOMAIN but a known-good name receives an expected answer from the same resolver, the resolver is capable of answering at least some queries. That narrows the investigation toward the target name, zone, view, record, or cache state rather than a total resolver outage.
The control should be chosen intentionally. A cached public name is not always a strong control for an internal private zone, because the two queries may depend on different DNS paths.
Use nslookup after numeric-IP testing to separate naming from basic routed reachability
> ping 203.0.113.20 Reply from 203.0.113.20: time=24ms TTL=51 > nslookup portal.example DNS request timed out. Server: 10.30.2.53
The numeric-IP probe bypasses DNS and receives an ICMP reply. That does not prove every route or service works, but it makes “the client has no remote IP connectivity at all” a poor explanation for this exact evidence. The DNS timeout becomes the more discriminating branch.
Combine this page with the broader DNS Troubleshooting Guide when you need the complete dependency tree.
Forward and reverse DNS answer different questions
A forward lookup starts with a name and seeks records such as A or AAAA. A reverse lookup starts with an IP address and typically seeks a PTR record in the reverse-DNS namespace. A missing or unexpected PTR record does not automatically mean the forward A record is wrong.
When a scenario supplies both, treat them as separate artifacts. Some services care about reverse DNS; others do not. Do not invent a reverse-DNS requirement unless the scenario or service behavior makes it relevant.
24 nslookup and DNS evidence flashcards
These cards emphasize interpretation. Before revealing the answer, state what the evidence proves, one thing it does not prove, and the next test you would choose.
Five nslookup conclusions that sound reasonable but outrun the output
“The website is up.”
A DNS address answer says nothing about TCP, TLS, or application health.
“The DNS server is down.”
A timeout is compatible with several resolver-path failures; it does not prove global server outage.
“NXDOMAIN means no network.”
NXDOMAIN is itself a DNS response, so communication occurred far enough to receive that negative answer.
“Public DNS should know every name.”
Private organizational namespaces can intentionally be invisible to public resolvers.
“The DNS server shown is authoritative.”
The Server field usually identifies the resolver queried, which is not necessarily authoritative for the target zone.
Capture the failing DNS evidence before flushing caches or replacing configuration
Record the exact query, resolver address, answer or error, time, client DNS configuration, and—when relevant—the same query against a comparison resolver. Then make the smallest justified change.
This creates a before/after delta. If a client switches from an unintended public resolver to the internal resolver and the private name immediately resolves, the change supports a specific mechanism. “I rebooted and it worked” provides far less information.
DNS repair is verified twice: first at DNS, then at the original application requirement
After correcting a resolver, record, cache, or client configuration problem, repeat the exact DNS query and confirm the expected response. Then retest what the user originally needed—such as HTTPS access, mail routing, or another service.
A correct nslookup answer is necessary evidence when DNS was the fault, but it is not sufficient end-to-end verification. The application can have an independent failure beyond DNS.
Turn raw DNS output into a bounded conclusion and one high-information next test
Observation: “The query to resolver 10.30.2.53 returned NXDOMAIN for files.campus.example, while the same resolver answered a known-good internal name.” Inference: “The resolver is responding, but this target name is absent from the answering DNS context.” Next test: “Verify the exact FQDN and whether the expected zone/record exists or whether the client should use a different DNS view.”
That answer is stronger than “DNS is broken” because it preserves what the evidence eliminated and what remains uncertain.