Reading a DNS answer: the line you skipped is the diagnosis

Fourteen articles on dig and nslookup, arranged as a single answer read from the top: who actually replied, whether they were authoritative or repeating a cache, what the flags admit, what the OPT line is doing there, what the records say, what a failure code means, and how to walk the delegation yourself when the resolver's answer cannot be trusted. Most DNS misdiagnoses are not a misunderstanding of DNS. They are a line that was not read.

When the resolver being read is a firewall rather than a server, FortiGate DNS server modes and filtering covers what it will and will not answer.

The claim

DNS is not hard to understand. It is hard to read, because both tools that query it print an answer that is mostly metadata, and the metadata is where the diagnosis lives. The name resolved - fine, but who said so? To which server did the question actually go? Was the reply from the zone or from a cache that may be hours stale? Did the resolver truncate it, refuse it, or fail to reach anyone? Every one of those is on the screen, and every one is skipped by a reader who is only looking for an address.

So this page arranges the tooling articles as one answer, read from the first line to the last, in the order the questions arise.

Line one: who answered

Reading nslookup output - nslookup prints a Server and Address header before anything else. That is the resolver it asked, which is almost never the server that holds the zone. A large share of "DNS is wrong" reports are reports about that resolver's opinion, and the first thing to establish is whose opinion you are looking at.

Reading dig output - the same answer in dig's fixed shape: version line, header, flags, the pseudo-section, the four sections, and the query statistics at the bottom that tell you which server replied and how long it took.

Line two: whether they were authoritative

Authoritative versus non-authoritative answers - the marker that nslookup prints and the flag that dig shows mean the reply came from a resolver's cache rather than from a server that holds the zone. It can be correct and stale at the same time. When a change "has not propagated," this is the line to look at first, and the article explains why the fix is usually to ask the authority directly rather than to wait.

The Kaminsky flaw is what happens when a cached, non-authoritative answer is the wrong one and nothing in the resolver can tell; the line that says "non-authoritative" is the reason the distinction was worth an industry-wide emergency patch.

The header and the flags

The DNS message header and flags - what kind of query this was, whether it succeeded, and the seven single-bit flags: recursion desired and available, authoritative, truncated, and the rest. Truncation in particular explains a whole family of "works with one tool, not the other" reports, because it is where an answer that did not fit in UDP gets cut and the client is expected to retry over TCP.

The line that is not a record

EDNS and the OPT pseudo-section - near the top of a dig answer sits a line that is not a record and not something you asked for. It is (0) metadata: the buffer size the client offered, the -OK bit, sometimes an extended error code. Readers who do not know what it is either ignore it or worry about it; the article says what it carries and when it matters.

The records themselves

Record types in dig answers - every record is five columns: name, , class, type, data. The TTL column is the one people forget to read, and it is the one that tells you how long the wrong answer will persist.

Record types in nslookup - the same records labelled in prose rather than columns: mail exchanger, canonical name, nameserver, and the multi-line block for a start-of-authority record.

When there is no answer

nslookup errors explained - a failed lookup prints a single line with a code, and the code is the whole diagnosis. NXDOMAIN, SERVFAIL, REFUSED and a timeout are four different failures with four different owners, and treating them as one "DNS is down" is the most common way a resolution problem gets escalated to the wrong team.

Asking precisely

dig query options - choosing the server, the record type, and how much of the answer to print. The habit worth building is @server: asking a specific server, especially the authoritative one, is how a resolver's cache is taken out of the picture.

nslookup interactive mode - the same control from the interactive prompt: switching resolvers, changing the record type, turning on debug output.

Walking the delegation yourself

dig +trace and delegation - the answer to "but which server is supposed to hold this?" Trace resolves the way the internet actually does it: from the root, to the top-level domain, to the zone's own servers, showing each referral. When the resolver's answer and the authority's answer disagree, this is how the disagreement is located. For what the top of that chain depends on, see what happens if the root goes dark.

Backwards, and signed

Reverse lookups with nslookup - mapping an address back to a name through the reverse trees. Reverse records are maintained by whoever holds the address block, not by whoever holds the name, which is why they are so often missing or wrong and why mail systems care.

DNSSEC records in dig - add the flag and the answer grows a family of records: signatures, keys, delegation signers, and the denial-of-existence records. What each one is for, and how to tell a validation failure from an ordinary one.

Two tools, one answer

nslookup versus dig - both query the same thing; nslookup is terser and hides the flags and TTLs that dig shows in full. The article maps one output onto the other, which is the fastest way to become fluent in whichever one the machine in front of you happens to have.

The habit

Read the answer top to bottom, once, before forming a theory. Who answered, whether authoritatively, what the flags say, then the records, then the TTLs. The 500-mile email was solved by someone who looked at a layer nobody was reporting on; a DNS problem is usually solved by someone who looks at a line nobody was reading. For the longer story of how the system came to work this way, see the DNS lineage.