Skip to content

nslookup

Everything in the DNS records module — A, AAAA, MX, and the rest — was queried there with dig. nslookup asks the same questions of the same DNS servers, and for a long stretch it was the only widely available way to do it interactively, on every major OS at once. It's still worth knowing, for a reason that has nothing to do with which tool is technically better: it's the one that's actually installed everywhere, including on Windows, where dig isn't available without a separate install.

Non-interactive mode: one query, one answer

nslookup example.com

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

The Server line at the top isn't the DNS server that owns example.com — it's the resolver nslookup actually asked, typically a local caching resolver (127.0.0.53 here is systemd-resolved's local stub on many Linux distributions) rather than the internet-facing authoritative server for the domain. Non-authoritative answer says the same thing more explicitly: this response came from a cache, not from the name's actual authority, which is the normal, expected case for almost every everyday lookup.

Querying a specific record type or a specific server directly:

nslookup -type=MX example.com 8.8.8.8

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
example.com     mail exchanger = 10 mail.example.com.

The trailing argument is the server to query — here, Google's public resolver, bypassing whatever DNS server the local system would normally use. This is a genuinely useful move whenever the question is specifically "does this record look right from the outside," rather than "what does my resolver currently have cached" — the two can legitimately differ, especially right after a record changes and caches haven't all expired yet.

Interactive mode: several queries against one session

Run nslookup with no arguments and it drops into a > prompt, holding the session open for multiple queries against the same server without repeating it each time:

$ nslookup
> set type=AAAA
> example.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   example.com
Address: 2606:2800:21f:cb07:6820:80da:af6b:8b2c
> exit

set type= changes the record type for every subsequent query in the session; exit (or Ctrl+D) leaves interactive mode. This is a convenience for a quick back-and-forth investigation, not a capability the non-interactive form lacks — everything achievable here is also one nslookup -type=... name command away.

Why nslookup is considered legacy — and why it's still around

ISC, the organization behind the BIND DNS server and the dig/host tools that ship alongside it, states plainly in its own documentation that it doesn't recommend nslookup, citing what it calls an arcane interface and inconsistent behavior across implementations. Part of that inconsistency is real and specific: nslookup on some systems has historically used its own internal resolver library rather than the operating system's standard one, which means it can occasionally report a different answer than every other program on the same machine sees — a subtle, confusing failure mode dig doesn't share, since dig and the rest of the system consistently go through the same resolution path.

None of that has removed nslookup from where it actually matters most: it ships by default in Windows' Command Prompt, while dig does not — getting dig on Windows means installing BIND's tools separately, or using PowerShell's Resolve-DnsName instead, which is closer to dig in capability but isn't the same command at all. On Linux and macOS, where dig is standard, nslookup is genuinely the one to reach for less.

Confirming a DNS change actually propagated

A DNS record was just updated to point api.example.com at a new IP address, and a colleague on Windows needs to confirm the change reached their own resolver before redeploying a dependent service:

nslookup api.example.com

Server:  dns.corp.example
Address:  10.0.0.5

Non-authoritative answer:
Name:    api.example.com
Address:  198.51.100.20

nslookup api.example.com 1.1.1.1

Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    api.example.com
Address:  203.0.113.44

Two different answers from two different resolvers — the corporate DNS server already has the new address; Cloudflare's public resolver is still serving a cached, stale one. That's not a sign anything is broken; it's the record's TTL simply not having expired yet on every resolver that cached the old value. The next step isn't another DNS change — it's waiting out the TTL, or checking specifically what TTL was set on the record to know how long that takes.

Practice exercises

  1. Run nslookup in interactive mode, use set type=MX and then set type=NS against the same domain in one session, and compare the results with what a single non-interactive nslookup -type=MX command would show.
  2. Query the same domain against your system's default resolver and against 1.1.1.1 explicitly. If the answers differ, is that necessarily a problem?
  3. On a Windows machine, check whether dig is available by default, and if it isn't, look up how Resolve-DnsName would answer the same MX query nslookup -type=MX does.

nslookup gets a usable answer quickly, on almost any system. The next article covers the tool ISC actually recommends in its place — considerably more capable, and the one this course's own DNS records module already uses throughout.

Sources