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

A DNS answer printed by dig or nslookup is the whole reply message: a header with flags and a response code, the question, an OPT pseudo-record and up to three sections of records, of which the address is one line. After reading, you can tell who answered and with what authority, read the flags, the OPT line, the TTLs and the failure codes, ask the authoritative server directly, follow a delegation with +trace, and find the part of this series that goes deeper on each line.

View as Markdown

When dig or nslookup prints a DNS answer, the address you wanted is one line. The rest is the reply, "divided into 5 sections (some of which are empty in certain cases)" in the words of (RFC) 1035 (RFC 1035, section 4.1): header, question, answer, authority and additional. Together they say who replied, with what authority and why a lookup failed; each piece below links to the series part that goes deeper. Afterwards you can name who answered, read the flags, the line and each record's time to live (), tell failures apart, and ask the authority yourself.

One answer, from the top

Illustrative: composed in the output format of dig from 9.20.29, with documentation addresses; no live server produced it.

; <<>> DiG 9.20.29 <<>> @192.0.2.53 www.example.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 00112233445566770102030405060708090a0b0c0d0e0f10 (good)
;; QUESTION SECTION:
;www.example.com.		IN	A

;; ANSWER SECTION:
www.example.com.	3600	IN	A	203.0.113.10

;; Query time: 12 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Sun Oct 18 19:00:00 -03 2026
;; MSG SIZE  rcvd: 88

The ->>HEADER<<- and flags: lines are the header; then come the OPT pseudo-section, a block per section that holds records (BIND 9.20.29 message.c) and four statistics lines (BIND 9.20.29 dig.c). The dig output explainer decodes such output; a block-by-block reading opens the series.

Who answered

At the bottom, ;; SERVER: gives the address and port the reply came from, the server as typed, and the transport (BIND 9.20.29 dig.c). Told nothing, dig asks the servers in /etc/resolv.conf (dig manual, Description), so this is usually your resolver, not the zone's server; nslookup prints it first, as Server: and Address: (BIND 9.20.29 nslookup.c). With recursion desired (RD), copied from your query, and recursion available (RA) both set in the reply, the server recursed (RFC 1034, section 4.3.1). More on nslookup's layout and on choosing a resolver.

Authority, cache or referral

The authoritative answer (AA) bit "specifies that the responding name server is an authority for the domain name in question section" (RFC 1035, section 4.1.1). BIND's nslookup prints Non-authoritative answer: when it is clear (BIND 9.20.29 nslookup.c). Clear, the bit says only that the responder is not an authority: a resolver answering from its cache or with an answer just fetched, or a server referring you on, since "these referrals have the AA bit set to 0" (RFC 9499, section 6). Zone data keeps constant TTLs while cached TTLs count down (RFC 1035, section 6.1.3), so a TTL that falls on repeated queries marks a cache. More on authority.

The header and its flags

The ->>HEADER<<- line holds the operation code (opcode), the response code () as status, and the identifier (ID). The Internet Assigned Numbers Authority () registers opcode 0 as Query and RCODEs 0 NoError, 1 FormErr, 2 ServFail, 3 NXDomain, 4 NotImp and 5 Refused (IANA DNS Parameters). The ID is a 16-bit number the querier sets and the reply copies (RFC 1035, section 4.1.1; RFC 1035 erratum 7587). The flags line lists the bits that are set (section 4.1.1; RFC 4035, sections 3.2.2 and 3.2.3):

Flag	Set in a response
`qr`	: a response, not a query
`aa`	Authoritative Answer: from an authority for the name
`tc`	TrunCation: cut to fit the channel
`rd`	Recursion Desired: recursion was asked for
`ra`	Recursion Available: the server offers it
`ad`	Authentic Data: answer and authority sections judged authentic
`cd`	Checking Disabled: the query asked for no validation

Without Extension Mechanisms for DNS ((0)), UDP messages stop at 512 bytes, and "Longer messages are truncated and the TC bit is set in the header" (RFC 1035, section 4.2.1). The client then retries over TCP (RFC 2181, section 9), which every general-purpose implementation MUST support (RFC 7766, section 5); where TCP port 53 is blocked, the retry fails. More on the header.

The OPT line

EDNS(0) lets messages exceed 512 octets, widens the response code and carries options (RFC 9499, section 5). It travels in the additional section as an OPT pseudo-record, a resource record (RR) of type 41, and "OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files" (RFC 6891, section 6.1.1). dig prints it apart, so ADDITIONAL: 1 with no additional section shown is the OPT (BIND 9.20.29 message.c).

You asked for it: in dig, "EDNS is set to 0 by default" (dig manual, +edns), and a responder includes OPT only when the query had one (RFC 6891, sections 6.1.1 and 7). Your offer, 1232 octets in dig 9.20.29 (BIND 9.20.29 dighost.c), shows with +qr, and the do flag says you accept DNS Security Extensions () records, hence its name, DNSSEC OK (DO) (RFC 3225, section 3). In a response, udp: is the responding server's payload size: dig prints the CLASS field of the message it received (BIND 9.20.29 message.c), which erratum 8348, held for document update, describes as the sender's size rather than the requestor's, because "The requestor is not the same as the sender" (RFC 6891 erratum 8348). Options such as COOKIE and Extended DNS Error (EDE) follow (IANA DNS Parameters). More on EDNS.

The record line

Each record prints as owner name, TTL, class, type and data; the data's length travels on the wire unprinted (RFC 1035, section 3.2.1). A TTL runs from 0 to 2147483647, and "The TTL specifies a maximum time to live, not a mandatory time to live" (RFC 2181, section 8). The example's 88 octets add up exactly (RFC 1035, section 4.1):

header     fixed part                     12   six 16-bit words
question   www.example.com. IN A          21   name 1+3 + 1+7 + 1+3 + 1 = 17, QTYPE 2, QCLASS 2
answer     A 203.0.113.10                 16   name pointer 2, TYPE 2, CLASS 2, TTL 4, RDLENGTH 2, address 4
OPT        fixed part, root name          11   name 1, TYPE 2, CLASS 2, TTL 4, RDLEN 2
COOKIE     option in the OPT's data       28   option code 2, length 2, client 8 + server 16
total                                     88   60 without the cookie

More on record data and nslookup's labels.

When the answer is a failure

has no code of its own; it is "an answer with the RCODE set to NOERROR and no relevant answers in the answer section" (RFC 2308, section 2.2). NXDOMAIN, from an authoritative server, says "the domain name referenced in the query does not exist" (RFC 1035, section 4.1.1). SERVFAIL means the server could not process the query: an authoritative server without valid zone data, or a resolver for any of many reasons (RFC 9520, section 2.1). REFUSED is policy: a zone the server does not serve, or a client outside a resolver's access control lists (section 2.2). Silence is no response code: dig prints timed out and no servers could be reached (BIND 9.20.29 dighost.c) and exits with status 9 (dig manual, Return Codes).

Negative answers are cached. The authoritative server adds the zone's (start of a zone of authority) record, whose TTL, the lesser of the SOA's MINIMUM field and its own TTL, "indicates how long a resolver may cache the negative answer" (RFC 2308, section 3). With a MINIMUM of 300 and an SOA TTL of 3600 (illustrative), a cached NXDOMAIN lasts 300 seconds, even for a name created a minute later. That, and positive records living out their TTLs, explains most slow changes; asking the authority shows the new data but empties no cache. How nslookup words each failure has its own part.

Asking precisely

# Ask a chosen server instead of the one in /etc/resolv.conf (addresses illustrative)
dig @192.0.2.53 www.example.com A
# Ask the zone's authoritative server without recursion, then look for aa
dig @198.51.100.53 +norecurse www.example.com A
# Print your own query as well: its RD bit, its OPT record, the udp: size offered
dig +qr www.example.com
# Only the answer section, or only the data
dig +noall +answer www.example.com
dig +short www.example.com

@server chooses the server, and +norecurse clears RD, which dig sets by default (dig manual, +recurse). Put to the zone's authoritative server, the query gets the zone's own answer, marked aa.

Asking each server in the zone's NS (name server) records this way also finds a lame delegation, a server delegated the zone "but is not performing nameservice for that zone" (RFC 1912, section 2.8): its reply comes back non-authoritative.

The dig command builder builds such commands and explains each token; nslookup's prompt has server, set type= and set debug (nslookup manual). More on how dig parses a command, its options and nslookup's prompt.

Following the delegation

With +trace, dig makes iterative queries, following referrals down from the root servers (dig manual, +trace). @server only seeds the query for the root's servers, and +dnssec comes on (+trace). A resolver instead starts from the closest name server records it holds, and "If the data is in the cache, it is assumed to be good enough for normal use" (RFC 1034, section 5.3.3). A trace can thus show a delegation your resolver's cache has not caught up with. More on tracing and on the root itself.

Reverse names and signed answers

dig -x 192.0.2.1 asks for the (domain name pointer) record of 1.2.0.192.in-addr.arpa, the octets reversed (dig manual, -x; RFC 1035, section 3.5); IPv6 writes its 32 hexadecimal digits in reverse, one label each, under ip6.arpa (RFC 3596, section 2.5), as the IPv6 Toolkit shows. Reverse and forward data sit in different zones and can disagree (RFC 1035, section 3.5).

+dnssec sets DO (dig manual, +dnssec), and a signed zone's server then adds Resource Record Signature (RRSIG) records to data, Next Secure () records to denials and Delegation Signer (DS) records to referrals; DNS Public Key () records come when asked for (RFC 4034, section 1; RFC 4035, section 3.1).

A validating resolver answers SERVFAIL for bogus data, but "it MUST return the full response if and only if the original query had the CD bit set" (RFC 4035, section 5.5): if +cd turns a SERVFAIL into data, suspect validation. More on reverse lookups, DNSSEC records and the chain of trust.

The same answer in nslookup

Server:		192.0.2.53
Address:	192.0.2.53#53

Non-authoritative answer:
Name:	www.example.com
Address: 203.0.113.10

Illustrative, in BIND 9.20.29's nslookup format; Windows has its own nslookup, whose exact output is not shown here. BIND's prints the server, Non-authoritative answer: when AA is clear, then labelled records; TTLs appear only in debug output, flags never, and a failure reads ** server can't find plus the name and the code (BIND 9.20.29 nslookup.c). Microsoft's documentation names its error messages Nonexistent domain, Server failure, Refused, No records and timed out (Microsoft Learn, nslookup). The nslookup output explainer decodes such output, and which tool to use has its own part.

Forged answers and the 2008 fix

Cache poisoning plants forged DNS data in a resolver's cache (VU#800113, Description). A resolver accepts the first reply whose question, ID, address and port match its query (RFC 5452, section 3), and in 2008 forging one was practical: the ID has 16 bits, and some implementations reused one source port for every query (VU#800113, Description). The fix changed how queries leave the resolver, not what answers print: "A number of vendors have released patches to implement source port randomization in the nameserver." (VU#800113, Solution). Without protocol changes such as DNSSEC, "these mitigations cannot completely prevent cache poisoning" (Description). Forged and genuine cached answers are both non-authoritative; only DNSSEC validation tells them apart. More: The Kaminsky flaw, encrypting the question.

What to remember

dig's ;; SERVER: line and nslookup's first lines name who answered: by default your resolver, not the zone's server.
aa marks an authority for the name; without it the answer may be cached, freshly fetched or a referral.
In a response, the OPT line's udp: is the responding server's payload size; dig 9.20.29 offers 1232 octets, shown by +qr.
NODATA is NOERROR without answers; NXDOMAIN means no such name, SERVFAIL a server unable to process the query, REFUSED policy, a timeout no reply.
Negative answers are cached for the lesser of the SOA's MINIMUM and its TTL, and cached TTLs count down: slow changes are mostly caches.
The 2008 patches randomised source ports; only DNSSEC validation, never a line of output, tells a forged cached answer from a genuine one.

This series, in order

This article opens the series DNS, read from the answer. It reads one answer from the top, line by line, and points to the article behind each line; the parts below are those articles in the same order: the two tools' output, who answered, the header and the OPT section, the records, the failures, then asking precisely, walking the delegation, reverse lookups, DNSSEC, and the choice between the two tools.

Reading dig Output From Top to Bottom. dig's fixed shape, from the version line to the query statistics, block by block.
Reading nslookup Output. The Server and Address header, the Non-authoritative marker, and the per-type prose that follows.
Authoritative vs Non-Authoritative Answers. What the Non-authoritative answer marker means, why it is usually fine, and how to get an authoritative answer.
The DNS Header: Opcode, Status, and Flags. Opcode, status and the seven single-bit flags (qr, aa, tc, rd, ra, ad, cd) that say who answered and how.
EDNS and the OPT Pseudo-Section. The OPT pseudo-section: the UDP payload size, the DO bit that asks for DNSSEC, and options such as cookies.
Reading the Records in a dig Answer. The five columns of every record, then the rdata of A, , , SOA, , and the others you meet.
How nslookup Prints Each Record Type. How nslookup labels each record in prose instead of columns, the multi-line SOA block included.
nslookup Errors and What They Mean. NXDOMAIN, SERVFAIL, REFUSED and timeouts: the code after ** server can't find is the diagnosis.
Anatomy of a dig command line: how dig reads what you type. How dig reads a server, flags, a name, a type, a class and plus options in almost any order, and the defaults it fills in.
dig Query Options and Output Control. The options used every day, from @server and -t to +short and the ones that trim the output.
nslookup Interactive Mode. The interactive prompt: switching resolvers, changing the record type, turning on debug output.
Following Delegation with dig +trace. Resolving from the root down, hop by hop, the way the internet actually does it.
Reverse DNS Lookups with nslookup. PTR records under in-addr.arpa and ip6.arpa, and how nslookup builds the reverse name for you.
DNSSEC Records in dig Output. RRSIG, DNSKEY, DS and NSEC: how they chain from the root to a zone, and what the ad flag certifies.
nslookup vs dig: Which to Use. The same answer in both tools, and a simple rule for which to reach for.