You push a DNS change, then sit there wondering if it actually took. Don't wonder, ask: nslookup example.com works on any OS, Windows included, and confirms a name resolves or that a fresh record went live. When we want detail we reach for dig. dig +short example.com prints just the answer, and dig MX example.com or dig TXT example.com pull one record type so you're not wading through the rest. The bit worth memorising is the @ syntax. dig @8.8.8.8 example.com asks a specific resolver and steps around your own cache, which is how we check whether a change has actually propagated. Below: the commands, plus what the output is really telling you.
The short answer
nslookup example.com works everywhere. On Linux and macOS we run dig example.com for the full picture and dig +short example.com for just the answer. Add a type (dig MX example.com) or a resolver (dig @1.1.1.1 example.com).
nslookup for portability, dig for detail
nslookup is on every box we touch, Windows included, and honestly that’s the whole reason we keep it in hand. Give it a name and it prints the addresses, after a couple of lines telling you which server answered. Those first lines are your own resolver, not the result. They trip everyone up once.
nslookup example.com
On Linux and macOS, dig is the one worth learning. Out of the box it prints a full report with the TTL and the authority section. Gold when you’re debugging. Noise when you’re not. +short cuts it down to just the answer, one value per line:
dig +short example.com
Ask for one record type
Mail not arriving? Check MX. Chasing an SPF record or a domain-verification string? That lives in TXT. Name the type and dig fetches only that, which beats reading a whole zone to find one line:
dig MX example.com
Bypass your cache to check propagation
Point the query at a public resolver with @. If a freshly changed record shows up there but not from your default resolver, you’re just waiting for the old cached copy to expire:
dig @8.8.8.8 example.com
Prefer clicking to typing? The DNS lookup tool queries every record type in one click, and what DNS TTL means explains the propagation wait.
Three dig habits worth having, because they answer the questions that come straight after "what’s the record".
+short strips everything except the answer, which is what makes dig usable inside scripts. Pointing at a specific resolver with @ is how you tell "my machine is caching" apart from "the change hasn’t published", since you can ask the authoritative server directly and compare. And +trace walks the delegation from the root down, which is the fastest way to find the point where a broken zone stops answering.
dig +short A example.com @1.1.1.1
dig +trace example.com
One note on nslookup, since it worries people: the "Non-authoritative answer" line it prints is normal. It just means the reply came from a cache rather than from the zone’s own server, which is true of nearly every lookup you’ll ever run.
If you only take one of the two away, make it dig. nslookup is everywhere and it’s fine for a quick answer, but it won’t tell you what you need when a zone is genuinely broken, and that’s exactly when you’re looking.
Frequently asked questions
Should I use nslookup or dig?
nslookup when you just want a quick answer and it's the only tool installed, which on Windows it is. dig when you want detail or you're scripting: it shows the exact records with their TTLs and tells you which server answered, and "dig +short" gives clean output you can pipe. dig isn't installed by default on Windows, so nslookup is the portable choice there.
How do I look up just one record type, like MX or TXT?
Name the type. With dig, "dig MX example.com" pulls the mail servers and "dig TXT example.com" the SPF and verification records. IPv6? "dig AAAA example.com". With nslookup it's "nslookup -type=MX example.com". That's how we debug mail flow or confirm an SPF record without wading through everything else.
What does dig +short do?
It strips the full report down to just the answer values, one per line. "dig +short example.com" prints the IP addresses and nothing else, which is exactly what we want at a glance or in a script. Drop the +short when you miss the TTL and the authority section.
How do I check if a DNS change has propagated?
Query a public resolver directly so you skip your own cache: "dig @8.8.8.8 example.com" asks Google DNS, "dig @1.1.1.1 example.com" asks Cloudflare. New value shows there but not from your default resolver? You're just waiting for the old record cached locally to expire, and that wait is the TTL.
