Guides
nslookup and dig: The Commands for Every DNS Record Type
A DNS lookup from the terminal answers a narrower question than most people assume. These are the commands per record type, how to read what comes back, and why a cached answer is not the same as a published one.
Run a fresh DomainLens audit and use the report as your priority list.
What a lookup actually asks
When you run nslookup, you are not asking the domain. You are asking whichever resolver your machine is configured to use — your ISP, your router, or a public one such as 8.8.8.8 — and that resolver answers from its cache when it can.
nslookup says so in the output, and the line is easy to skim past:
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: domainlens.site
Address: 157.230.232.77Non-authoritative is the normal case
"Non-authoritative answer" is not a warning. It means the resolver held the record in cache and did not ask the domain’s own nameservers. That is how DNS is meant to work, and it is why almost every lookup you run returns it.
It matters in exactly one situation: you just changed a record and want to know whether the change is live. A cached answer cannot tell you that. Query the domain’s own nameservers instead — the command is further down.
The command for each record type
nslookup takes the record type through -type=; dig takes it as the last argument. The pairs below cover everything a normal DNS problem needs.
| You want | nslookup | dig |
|---|---|---|
| IPv4 address | nslookup example.com | dig example.com A |
| IPv6 address | nslookup -type=aaaa example.com | dig example.com AAAA |
| Mail servers | nslookup -type=mx example.com | dig example.com MX |
| Nameservers | nslookup -type=ns example.com | dig example.com NS |
| TXT, including SPF | nslookup -type=txt example.com | dig example.com TXT |
| DMARC policy | nslookup -type=txt _dmarc.example.com | dig _dmarc.example.com TXT |
| The alias behind a name | nslookup -type=cname www.example.com | dig www.example.com CNAME |
Reading dig output, and the number people misread
dig prints the query, the answer, and the timing. Cut to the part that matters with +short, or read the ANSWER SECTION in full:
;; QUESTION SECTION:
;domainlens.site. IN A
;; ANSWER SECTION:
domainlens.site. 629 IN A 157.230.232.77
;; Query time: 51 msecThat 629 is not your TTL
The number between the name and the class is the seconds this answer stays valid in the cache you asked — what is left of it. If the zone publishes a TTL of 3600 and you see 629, the resolver fetched the record 2 971 seconds ago and will refresh it in another 629.
Run the same command twice a minute apart and the number drops. That is the single most useful signal dig gives you after a change: while the number is still counting down, you are being served the old answer, and nothing you do to the zone will alter it until it reaches zero.
Asking one nameserver directly
To see what the domain actually publishes right now, skip the cache and ask an authoritative nameserver. Find them first, then query one:
$ dig +short domainlens.site NS
ns211.inhostedns.net.
ns111.inhostedns.com.
ns311.inhostedns.org.
$ dig @ns211.inhostedns.net domainlens.site A
# nslookup uses the second argument for the same thing
$ nslookup domainlens.site ns211.inhostedns.net
# and any public resolver works as a second opinion
$ dig @1.1.1.1 +short google.com MX
10 smtp.google.com.When the answer still disagrees with the zone
The order matters. Cache is the common case and costs nothing to rule out; delegation is rare and expensive to misdiagnose.
- The authoritative server agrees with you, your resolver does not — cache. Wait out the TTL shown by dig.
- One nameserver answers differently from another — the zone did not sync across the set. That is a provider problem, not a waiting problem.
- The name resolves but the record type is empty — a CNAME is intercepting it. A name with a CNAME cannot carry other records.
- Nothing answers at all — check the parent delegation with dig NS on the registrar side before touching the zone.
Which command exists where
That split is why nslookup still appears in every set of instructions: it is the one command present on a stock Windows machine. On anything Unix-like, dig gives a cleaner answer and shows the TTL, which nslookup hides.
| Platform | nslookup | dig | host |
|---|---|---|---|
| macOS | Yes, /usr/bin | Yes, /usr/bin | Yes |
| Linux | Usually a package (bind-utils, dnsutils) | Same package | Same package |
| Windows | Yes, built in | No — BIND tools or WSL | No |
If you do not want to install anything
The DNS checker runs the same queries from the browser and reports the A and AAAA records, whether MX exists, and whether SPF and DMARC are published — the set that decides whether a site resolves and whether its mail authenticates. For what each record type is for, see DNS record types ; for the timing question specifically, DNS propagation .
- Is nslookup deprecated?
- No. It is unmaintained relative to dig and its output hides the TTL, but it ships with Windows and still answers correctly. Use dig where you have it; nslookup is not wrong.
- Why does dig show a different address than my browser?
- The browser may hold its own DNS cache, and on some systems the OS caches separately from both. dig asks the resolver directly and bypasses neither of the caches above it, which is why it is the more trustworthy of the two.
- What is the difference between dig and host?
- host is dig with the detail stripped out. It is convenient for a quick address, but it will not show you the TTL, which is usually the number you actually need.