The dig command in Linux
dig (domain information groper) sends DNS queries and prints the full answer, including which server replied and how long it took. When "the site is down" is actually "the name doesn't resolve", dig is the instrument that proves it — and during DNS migrations it is how you watch the new records propagate.
How dig works
dig builds a DNS query packet and sends it — UDP port 53 by default, retrying over TCP when the answer is too large and arrives truncated. The reply's sections mirror the protocol: ANSWER holds the records you asked for, AUTHORITY names the servers responsible, ADDITIONAL carries helper records. The status (NOERROR, NXDOMAIN, SERVFAIL) and the "Query time" line make dig a protocol instrument, not just a lookup tool.
The resolution world has two kinds of servers, and dig lets you interrogate both. Recursive resolvers (your ISP's, 8.8.8.8) chase answers on your behalf and cache them subject to each record's TTL — the reason changes propagate gradually. Authoritative servers hold the zone's truth. dig @resolver shows what the world currently believes; dig @authoritative shows what it should believe; +trace walks the whole delegation from the root, exposing exactly which link in the chain is broken.
Syntax
dig [@SERVER] NAME [TYPE]Common options
| Option | What it does |
|---|---|
A / AAAA | IPv4 / IPv6 address records (A is the default type). |
MX | Mail exchangers for the domain. |
TXT | Text records: SPF, verification tokens, DKIM. |
NS | The authoritative name servers. |
@8.8.8.8 | Ask a specific server instead of the system resolver. |
+short | Just the answer values, nothing else. |
+trace | Walk the delegation from the root — see the whole resolution path. |
How to use dig: examples
$ dig example.com +shortThe IP(s) behind a name, and nothing more.
$ dig example.com MX +shortWhere this domain's mail goes.
$ dig @8.8.8.8 example.comBypass your local resolver: is the record wrong everywhere, or only in your cache?
$ dig example.com +traceFollow resolution from the root servers down — the tool for "which delegation is broken?".
$ dig -x 93.184.216.34 +shortReverse lookup: the name registered for an IP.
Real-world use cases for dig
Watching a migration propagate
After changing an A record: dig @authoritative-ns example.com confirms the zone is right, then dig @8.8.8.8 and dig @1.1.1.1 show which public resolvers have picked it up as TTLs expire. No more "clear your cache and pray".
Verifying mail configuration
Deliverability audit in three queries: dig domain MX (where mail goes), dig domain TXT (SPF policy), dig selector._domainkey.domain TXT (DKIM key). Most "our emails go to spam" tickets are solved staring at exactly these three answers.
Pro tips and common mistakes
- Lower the TTL a day BEFORE a migration; old caches honor the old TTL, and patience beats panic.
- +short for scripts and quick checks; the full output when status codes and authority matter.
- dig -x IP (reverse lookup) identifies mystery addresses in logs — when a PTR record exists.
Frequently asked questions about dig
My DNS change is not visible — why?
Caches. Every record carries a TTL, and resolvers serve the old value until it expires. Query the authoritative server directly (dig @ns1.provider.com name) to confirm the change itself is live.
What is the difference between dig and nslookup?
Same job; dig gives more complete, script-friendly output and is the standard on Linux. nslookup survives mainly on Windows.
What does SERVFAIL / NXDOMAIN mean?
NXDOMAIN: the name does not exist. SERVFAIL: the resolver failed to get an answer (often broken delegation or DNSSEC). They point to different culprits.
Related commands
Download files, test APIs, send POST requests with JSON, and inspect headers.
pingCheck whether a host is reachable and measure round-trip latency.
ipThe modern tool for addresses, links and routes — replacing ifconfig and route.