Lookup tools: dig, nslookup, Resolve-DnsName, online
The four ways to query DNS from the helpdesk, and the diagnostic split between authoritative and cached.
The lookup tools are the eyes of all the DNS work in this course. Every diagnostic, every verification after a change, every is the record set right check uses one of these tools.
dig is the standard; learn it first. The others are fallbacks for specific environments.
The four tools
| 1 | # 1. dig — the gold standard (Linux, macOS, WSL on Windows) | |
| 2 | dig A example.com | |
| 3 | dig +short MX example.com | |
| 4 | dig A example.com @8.8.8.8 # query a specific resolver | |
| 5 | dig A example.com @ns1.cloudflare.com # query the authoritative directly | |
| 6 | dig +trace example.com # recursive resolution from root | |
| 7 | dig -x 198.51.100.42 # reverse lookup (PTR) | |
| 8 | ||
| 9 | # 2. nslookup — universal fallback (older, less verbose; ships everywhere) | |
| 10 | nslookup example.com | |
| 11 | nslookup -type=MX example.com | |
| 12 | nslookup example.com 8.8.8.8 | |
| 13 | ||
| 14 | # 3. Resolve-DnsName — PowerShell on Windows; structured output | |
| 15 | Resolve-DnsName example.com -Type A | |
| 16 | Resolve-DnsName example.com -Type MX -Server 8.8.8.8 | |
| 17 | ||
| 18 | # 4. Online lookup tools — when no terminal is available |
Authoritative vs cached: which to query
The most common diagnostic split: is the record correct at the authoritative server, or is the cached state stale?
- Authoritative (
dig A example.com @ns1.cloudflare.com): bypasses caches; returns the canonical value the authoritative holds now. - Public resolver (
dig A example.com @8.8.8.8): goes through Google’s cache; returns what end-users with that resolver would see.
If the authoritative result is correct and the public-resolver result is stale: change is fine, propagation in flight. If the authoritative is also stale: change didn’t save; check the panel.
Practice: staleness triage
A client changed their A record 30 minutes ago. Their office still resolves to the old IP. Walk through the diagnostic sequence.
When to use which tool
| Tool | When |
|---|---|
dig | Default for any Linux / macOS / WSL session. Most verbose, most flexible. |
nslookup | Windows machines without WSL or BIND tools, where dig isn’t installed. |
Resolve-DnsName | PowerShell scripting; structured output you can pipe to Where-Object etc. |
| Online lookup | Locked-down client environment with no terminal. Filtered through whichever resolvers the service uses; you can’t pick an authoritative server the same way dig @ns1... lets you. |
What this is NOT
- “The default resolver shows the truth.” It shows cached state. Always query the authoritative for the canonical answer.
- “Nameservers and resolvers are the same thing.”
dig @ns1.cloudflare.comasks the authoritative.dig @8.8.8.8asks a recursive resolver. Different roles; different answers when caches diverge. - “Read
digoutput from the bottom up.” The ANSWER section is what matters for most lookups. The AUTHORITY and ADDITIONAL sections are diagnostic colour.
When to escalate
dig +traceshows delegation problems at the TLD level (the TLD nameserver doesn’t have the right NS for the domain). Registrar-level issue; may indicate unauthorised delegation changes.- Queries against the authoritative server fail to connect entirely. DNS-host outage.
- The authoritative returns
SERVFAILorREFUSED. Zone misconfigured at the authoritative side; often beyond the helpdesk-tech ceiling to fix.