nslookup Command Guide

Two versions of the same command

There are two common implementations. Windows ships Microsoft's own nslookup, documented in the Windows Commands reference. macOS and Linux ship the version from ISC's BIND tools, the same package that provides dig and host. On Debian and Ubuntu it comes in bind9-dnsutils (or dnsutils), and on Fedora and RHEL in bind-utils.

The everyday commands in this guide work on both. The output looks a little different, and a few options exist on only one side. Where that matters, the examples say which one they show.

Forward and reverse lookups

A forward lookup starts with a name and asks for data stored under it. Most of the time that means an address: an A record for IPv4 or an AAAA record for IPv6. It is what every browser does before it connects to a website.

A reverse lookup starts with an IP address and asks which name belongs to it. DNS cannot search for an address directly, so the address is rewritten as a name under a special zone, and the resolver asks for the PTR (pointer) record there. For IPv4, the four numbers are reversed and in-addr.arpa is added. For IPv6, each hexadecimal digit becomes its own label, in reverse, under ip6.arpa. nslookup does the rewriting for you whenever you give it an address.

Here is a forward lookup followed by a reverse lookup with BIND's nslookup:

$ nslookup mail.example.com
Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
Name:	mail.example.com
Address: 192.0.2.25
Name:	mail.example.com
Address: 2001:db8::25

$ nslookup 192.0.2.25
25.2.0.192.in-addr.arpa	name = mail.example.com.

$ nslookup 8.8.8.8
8.8.8.8.in-addr.arpa	name = dns.google.

The two directions are separate records, kept in separate zones by people who may never talk to each other. A name can point to an address whose PTR record names something else, or nothing at all. When both directions agree, as they do above, the setup is called forward-confirmed reverse DNS. Mail servers check for it, which is why a missing PTR record is a common cause of rejected mail. Reverse DNS and PTR Records explains who sets these records and how to get one changed.

Asking a specific DNS server

By default nslookup sends every query to your computer's configured DNS server, which is often your router or a corporate resolver. To ask a different server, add its address or name as the last argument. This is the most useful thing nslookup does, because comparing servers is how you tell a local problem from a global one.

If you give a server by name, nslookup first resolves that name using your default server, then sends the real query to the address it found. BIND's nslookup also accepts -port= for a server listening on a port other than 53, which is handy for testing a resolver on a lab machine.

In interactive mode, the server command changes the server for the rest of the session. Both versions also have lserver, which does the same thing but resolves the new server's name with the server you started with. That matters when the server you just switched to cannot resolve names, such as an authoritative server.

Which server to ask

To find the authoritative servers, ask for the domain's NS records, then query one of them directly:

$ nslookup -type=NS example.com
Non-authoritative answer:
example.com	nameserver = ns1.example.net.
example.com	nameserver = ns2.example.net.

$ nslookup www.example.com ns1.example.net
Server:		ns1.example.net
Address:	198.51.100.53#53

Name:	www.example.com
Address: 192.0.2.80

Notice that the second answer has no “Non-authoritative answer” line. That is how nslookup shows that the reply came from a server responsible for the zone. If an authoritative server answers with REFUSED or times out, it may not be serving the zone at all, a problem described in Lame Delegation.

Looking up other record types

Set the record type with -type=. Both versions also accept the shorter -q=. The type is not case-sensitive.

Avoid relying on -type=ANY. Many servers now return a single record, or a short placeholder, instead of everything they hold, as allowed by RFC 8482. Ask for each type you care about instead. DNS Record Types Explained describes each type in more depth.

An SOA lookup against each authoritative server is a quick way to check that they all serve the same version of a zone. In a classic primary and secondary setup, differing serial numbers mean at least one server has not picked up the latest change. Zones served by several independent primaries, such as multi-provider setups or Active Directory-integrated DNS, can keep their own serials, so compare the actual records there instead.

$ nslookup -type=SOA example.com ns2.example.net
Server:		ns2.example.net
Address:	203.0.113.53#53

example.com
	origin = ns1.example.net
	mail addr = hostmaster.example.com
	serial = 2026102201
	refresh = 7200
	retry = 3600
	expire = 1209600
	minimum = 300

Reading the output

Every reply has the same parts. Here is the same lookup on Windows, where the differences from BIND's output are easiest to spot:

C:\> nslookup www.example.com
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    www.example.com.cdn.example.net
Addresses:  2001:db8::80
          192.0.2.80
Aliases:  www.example.com

• Server and Address name the DNS server that answered. Check this line first: many confusing results come from asking a server you did not mean to ask. On Windows, UnKnown only means the server's address has no PTR record. It is not an error.
• Non-authoritative answer means the reply came from a recursive resolver rather than from the domain's own name servers. It is normal and usually correct, but it may be up to one TTL old.
• Name is the final name that holds the data. If the name you typed is an alias, Windows lists the alias under Aliases, and BIND prints a canonical name = line before the answer.
• Address or Addresses lists the A and AAAA records. A plain lookup asks for both types, so you may see IPv4 and IPv6 together.

nslookup hides the TTL and the header flags by default. Turn on debug output with -debug (or set debug in interactive mode) to see the response code, whether the answer was authoritative, and how many seconds each record has left in the cache.

Authoritative and non-authoritative answers

An authoritative answer comes from a server that holds the zone itself. A non-authoritative answer comes from a resolver that fetched the data from an authoritative server, possibly some time ago, and cached it. When you have just changed a record, the authoritative servers show the new value straight away, while resolvers keep showing the old one until the cached copy's TTL runs out. An old cached answer can persist for its TTL, but a correct answer from one authoritative server does not rule out delegation, DNSSEC, policy or reachability faults. Check those and the other authoritative servers before prescribing a wait. Incorrect authoritative data needs correction at the provider. Authoritative DNS vs Recursive DNS and DNS TTLs and Caching Explained go into more detail.

Common errors

The response codes are explained in NXDOMAIN vs NODATA vs REFUSED and DNS SERVFAIL Explained.

Interactive mode

Run nslookup with no arguments, or with - followed by a server, to get a > prompt. Anything you type that is not a command is treated as a name to look up, and settings stay in place between queries. That saves typing when you are checking several names or record types against the same server.

$ nslookup
> server 9.9.9.9
Default server: 9.9.9.9
Address: 9.9.9.9#53
> set type=MX
> example.com
…
> example.org
…
> set type=TXT
> _dmarc.example.com
…
> exit

The same settings work on the command line with a dash, such as nslookup -timeout=10 -retry=3 example.com. Windows also offers ls -d example.com, which attempts a zone transfer to list every record. Almost every public server refuses it, as it should; a server that allows transfers to anyone is leaking its zone.

Platform quirks that change the answer

On Linux, nslookup is part of the bind-utils (Fedora, RHEL) or dnsutils / bind9-dnsutils (Debian, Ubuntu) package. Minimal installs and containers often leave it out, so install that package if the command is missing.

Windows: DNS suffixes and the trailing dot

Windows nslookup may append the connection's DNS suffixes, such as corp.example.com, to the name before sending it. On a work network, a query for intranet becomes intranet.corp.example.com, which is often what you want. It can also produce surprises, such as a wildcard record in the internal domain answering for a public name. End the name with a dot, as in nslookup example.com., to say the name is complete and stop suffixes from being added. BIND's nslookup on macOS and Linux can do the same with its search list: a name without a dot gets the suffixes straight away, and a dotted name such as api.prod gets them if the name as typed is not found. The trailing dot works there too. Turn on -debug to see exactly which names were tried.

macOS: nslookup is not what apps use

On macOS, nslookup reads /etc/resolv.conf, but applications use the system resolver, which also honors per-domain rules from VPN clients and files in /etc/resolver/. If a VPN sends internal names to an internal server, nslookup may not follow that rule. Run scutil --dns to see the real configuration, or dscacheutil -q host -a name example.com to resolve a name the way apps do.

Linux: the local stub resolver

On many Linux systems, /etc/resolv.conf points at a local stub such as systemd-resolved on 127.0.0.53, so the Server line shows that address rather than your real upstream server. Run resolvectl status to see which servers the stub forwards to, or name a server explicitly.

Everywhere: hosts files and encrypted DNS

nslookup does not read the hosts file itself. The one exception is a local stub: systemd-resolved answers from /etc/hosts, so on Linux systems that use it, hosts entries can show up in nslookup too. nslookup also cannot send DNS over HTTPS or DNS over TLS itself, so it never sees the answers a browser gets from its own encrypted DNS setting. Operating-system encrypted DNS is different: if a local stub such as systemd-resolved forwards over TLS, nslookup's queries to that stub go out encrypted too. If ping or a browser reaches a different address than nslookup reports, check the hosts file and the encrypted DNS settings first. Why does DNS work on one network but not another? walks through the other usual causes, including split-brain DNS.

A troubleshooting routine

1. Run nslookup name and note which server answered and what it said.
2. Ask two public resolvers, such as 1.1.1.1 and 8.8.8.8. If they agree with each other but not with your default server, investigate caching, filtering and internal zones, while also checking validation and authoritative reachability along the failing resolver’s path.
3. Find the NS records and ask each authoritative server. If they disagree with each other, compare SOA serials (or, with multiple independent providers, the records themselves). If they all agree but the resolvers do not, check remaining cache TTLs, DNSSEC, delegation and resolver policy; wait only when a healthy cached answer explains the difference.
4. If a validating resolver returns SERVFAIL but the authoritative servers answer, suspect DNSSEC. Debugging DNSSEC validation errors covers the next steps.
5. For mail problems, check MX, then the A and AAAA records of each mail host, then reverse DNS of each address.

When you need TTLs, flags, DNSSEC records or the full delegation path, switch to dig. nslookup vs dig compares the two, and the dig Command Deep Dive covers dig's options. On Windows, PowerShell's Resolve-DnsName is another option that returns structured output and accepts -Server and -Type parameters.

How DNS Panopticon helps

Domain Visualizer runs the lookups you would otherwise type one at a time. It queries a domain's records through public resolvers, so you can check MX, TXT, CAA and DNSSEC in one place and then use nslookup to confirm what your own network sees. Website Recon looks up the network that holds each of a site's addresses, which tells you who controls their reverse DNS. If you run your own zones, export one and load it into Zone Analyzer to review every record, including PTR records, before you start querying servers.