nslookup: five invocations, and three ways it misleads you

Every DNS article tells you to use dig. They are right, and it is not always available: a client's Windows laptop, a locked-down corporate desktop, a shared hosting shell, a Docker image with nothing in it. nslookup is there.

It is also the tool most likely to give you a true answer to a question you did not mean to ask. So here are the five forms worth memorising, and then the three ways the output is read wrong.

The five

One. What does my machine think.

nslookup example.com

This asks whatever resolver your operating system is configured to use: your router, your office DNS, your VPN's. It is the right question when you are asking "what does a person on this network get", and the wrong question for anything else.

Two. What does somebody else's resolver think.

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

The address after the name is the resolver to ask. This is the invocation that ends the "it works on my machine" conversation, because it lets two people on two continents ask the same resolver and compare.

Three. A record type other than the default.

nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
nslookup -type=SOA example.com

NS and SOA are the two people forget, and they are the ones that answer the question underneath most DNS confusion: who is actually in charge of this zone. A client can be editing records at their registrar while the domain's nameservers point at a hosting company, in which case the edits are real, saved, and completely without effect.

Four. Ask the authority directly.

nslookup -type=NS example.com
nslookup example.com ns1.theirprovider.net

Two steps: find the nameservers, then query one of them by name. This bypasses every cache between you and the truth. If the authoritative answer is right and a public resolver disagrees, nothing is broken and you are looking at a cache with time left on it. If the authoritative answer is itself wrong, no amount of waiting will help, and the change you think you made was made somewhere that does not matter.

Five. See the TTL.

nslookup -debug example.com

The plain output hides the TTL, which is the single most useful number in any migration. In debug mode it appears next to each record, counting down. Ask twice a minute apart and watch it drop: that tells you how much longer the current answer will persist, which is the actual measure of how far along a change is. The reason that number is the whole subject, and why lowering it during a cutover does nothing, is propagation is not a thing, TTL is.

Three ways the output misleads

"Non-authoritative answer" is not a warning. It means the answer came from a cache rather than from the zone's own nameserver, which is true of almost every DNS answer ever given and is completely normal. People read it as "this result may be wrong" and start chasing a problem that does not exist. The only time it matters is when you specifically wanted the authoritative answer, in which case use form four and it will disappear.

nslookup ignores your hosts file. On most systems it talks to a DNS server directly rather than going through the operating system's name resolution, so an entry in /etc/hosts or its Windows equivalent is invisible to it. This produces a spectacular kind of confusion during a migration: your browser reaches the new server because you added a hosts entry two weeks ago and forgot, nslookup reports the old address, and you conclude that DNS is broken. It is not. You are two different clients.

When in doubt, ask something that does use the system resolver:

getent hosts example.com

It quietly completes short names. If your machine has a search domain configured, a lookup of a bare name can be silently expanded, and you get a perfectly confident answer about example.corp.internal when you asked about example. On a corporate network this is how a name resolves to an internal address for one person and a public address for everybody else. End the name with a dot to forbid the completion: nslookup example.com.

The interactive mode, and why to avoid it

Run nslookup with no arguments and it drops into a prompt where you set options with set type=MX and then type names. It works. It is also where every stale piece of advice on the internet lives, and it makes what you did impossible to paste into a ticket.

One-shot invocations are reproducible, quotable, and scriptable. Somebody reading your handover note six months later can run the exact line. That is worth more than the two seconds saved.

When you do have a choice

Prefer dig, and the reason is not snobbery about tooling. dig prints the query it sent, the flags that came back, the TTL, and the section each record came from, all without asking. nslookup prints a summary and decides for you what is worth showing, which is exactly what you do not want from a diagnostic tool.

Keep nslookup for the situation it is actually good at: you are on somebody else's machine, on somebody else's network, and you need to know what that machine sees. That is a real question, it comes up constantly on client work, and it is the one question nslookup answers better than anything you could install.

The invocation you will reach for most is the mail one, and not because mail is complicated. It is because a mail failure produces no error anybody reports to you: the site is up and the mail is gone, and the sender is told nothing.

The one resolution a monitor does before it trusts a name

Everything above is about asking a resolver a question you want answered. A monitor resolves for the opposite reason: to find out whether the answer is allowed. Ours calls gethostbynamel(), then refuses the request outright if any returned address is private, loopback, or the metadata address 169.254.169.254 that cloud hosts serve to anything asking. The whole check is one short function in src/Http.php.

That is a validation, not a pin, and the difference matters if you ever build this yourself. A name whose record lives zero seconds can answer a public address while you validate and a private one when you connect, so validating and then connecting by name leaves a gap. Closing it means connecting to the address you checked while still presenting the name, which is what our public checker does because it takes hostnames from strangers. The engine watches sites its own owner registered, so the validation is the proportionate answer there. Knowing which of the two situations you are in is the whole decision.