nslookup is the DNS query tool most people meet first, and its output has a simple, stable shape once you know what the pieces are.

The layout

A normal lookup looks like this (example.com's IPv4 addresses on 7 October 2026; they change, so yours may differ):

Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
Name:	example.com
Address: 104.20.23.154
Name:	example.com
Address: 172.66.147.243

The first two lines are the header, and they describe the resolver, not the answer. Server: is the DNS server nslookup asked, and the Address: right below it is that server's address with its port (#53). This trips people up constantly: the first Address line is the resolver you queried, not the address you looked up.

After a blank line comes the answer. The Non-authoritative answer: marker, when present, tells you the result came from a resolver, usually out of its cache, rather than straight from a server authoritative for the zone: nslookup prints it whenever the reply's AA (authoritative answer) bit is clear. Then the records themselves: for an address lookup, a Name: line followed by one or more Address: lines (an IPv6 answer is on an Address line too, told apart by its colons).

Where to look first

If the lookup failed, nslookup does not print an answer; it prints a line like ** server can't find nonexistent.invalid: NXDOMAIN. The name is under .invalid because Request for Comments (RFC) 6761, section 6.4 lets users assume such names always return NXDOMAIN, while example.com now answers NOERROR with no data for names that do not exist (RFC 9824, section 3; observed 2026-10-19). The code at the end is the whole story: NXDOMAIN means the name does not exist, SERVFAIL means the server could not complete the query, and REFUSED means it declined.

If it succeeded, the two questions worth asking are which resolver answered (the Server line, in case you are testing a specific one) and whether the answer is authoritative (the marker). The rest of this series covers how nslookup formats each record type, how it compares to dig, what authoritative really means, and how to read its errors.

The server line is the one to read first

Before the answer, nslookup prints which server it asked. That line is the most useful in the output and the most skipped, because it is the same on every successful lookup, until the day it is not.

A resolver changed by , a (virtual private network) that installed its own, a container inheriting a different resolv.conf: each produces answers that are correct for a resolver nobody meant to consult. The answer is not wrong; the question went somewhere unexpected, and the output looks entirely normal.

Read the server line before the answer. When two machines disagree about a name, it is more often the resolver than the record.

Sources