nslookup and dig: A Practical DNS Troubleshooting Sequence

Most "the website is down" reports are DNS problems, and most DNS problems are diagnosed by asking two questions: is the record correct at the source, and is the client getting that answer. A query tool answers both in about thirty seconds if you work in the right order.

The two tools

nslookup ships with Windows and most Unix systems and has an interactive mode. It is universally available, which is its main virtue, and its output is terse.

dig is the preferred tool on Unix-like systems and is available for Windows. Its output shows the full response including flags, sections and timing, which is what you need when the answer is not the obvious part of the problem.

Both do the same job. Use whichever is present, and prefer dig when you need detail.

A working sequence

1. Query normally. Look up the name as the client would. If you get the right answer, DNS is not your problem — move on to connectivity or the application.

2. Query a public resolver directly. Specify a well-known external resolver as the server. If the public resolver returns the correct answer and your local one does not, the fault is local: your resolver, its cache, or its forwarders.

3. Query the authoritative server. Find the zone's name servers with an NS query, then query one of them directly. This is the source of truth and it bypasses every cache. If the authoritative answer is wrong, the record itself is wrong and no amount of cache flushing will help.

That three-step sequence separates the three possible faults — the record, the resolver, or the client — and it is the single most useful thing to remember about DNS troubleshooting.

Reading the response

A few details in the output carry most of the diagnostic value.

The status field distinguishes failure modes. NOERROR with no answer records means the name exists but has no record of that type — a common confusion when an AAAA query returns nothing for a host that has only an A record. NXDOMAIN means the name does not exist at all. SERVFAIL means the resolver failed, often a DNSSEC validation failure or an unreachable upstream, and is a very different problem from a missing record.

The authoritative answer flag tells you whether the response came from the zone's own server or from a cache. The TTL tells you how long a cached answer will persist, and a TTL counting down rather than sitting at its full value confirms you are looking at a cached copy — which is how you distinguish "the record was just changed and this is stale" from "the record is wrong."

Query specific record types deliberately: A and AAAA for addresses, MX for mail routing, TXT for SPF and DMARC and verification records, CNAME for aliases, SOA for zone parameters, PTR for reverse lookups. The full set is covered under DNS record types.

The problems this finds

Propagation confusion. A record was changed and some users still see the old value. Querying authoritative shows the new value while a resolver shows the old one with a decreasing TTL — nothing is broken, the cache simply has not expired. Lowering the TTL before a planned change is the fix, and it has to be done in advance.

Split-horizon mismatch. Internal clients get one answer and external clients another, by design — and when an internal client is using an external resolver, it gets the wrong one. This is now a common symptom of encrypted DNS bypassing the internal resolver, as discussed under DNS over HTTPS.

Missing or wrong records. Mail failing with no MX record, SPF or DKIM records with syntax errors, a CNAME pointing at a hostname that no longer exists.

Resolver problems. SERVFAIL from your resolver but correct answers from authoritative points at the resolver's forwarders, its DNSSEC validation, or its connectivity.

Unexpected answers that differ between resolvers are worth taking seriously rather than dismissing — a banking or corporate domain resolving differently on one network is the signature of the redirection described under pharming.

A note on scope

Ordinary lookups against public resolvers are passive. Querying a target's own authoritative servers touches their infrastructure and appears in their logs, which makes it active reconnaissance — fine for your own domains, and inside scope for anything else.

Exam angles

Know nslookup and dig as DNS query tools and the sequence of querying the local resolver, a public resolver, and the authoritative server to isolate a fault. Distinguish NXDOMAIN (name does not exist), NOERROR with no answer (no record of that type), and SERVFAIL (resolver failure). Recognize TTL and the authoritative flag as the way to tell a cached answer from a source answer, and know that lowering TTL before a planned change is what avoids propagation delay.