Basic syntax
dig [@server] [name] [type] [+option ...]
By default, dig queries the A record using the resolver from /etc/resolv.conf:
$ dig example.com
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
Common record types
| Type | What it holds |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | alias to another name |
| MX | mail server |
| NS | name server for the zone |
| TXT | arbitrary text records (SPF, DKIM, verification tokens) |
| SOA | start of authority: zone parameters |
| PTR | reverse lookup: IP to name |
| CAA | which CAs may issue a certificate for the domain |
| SRV | service location (SIP, XMPP, MS AD) |
| DS / DNSKEY | DNSSEC |
dig example.com AAAA # IPv6
dig example.com MX # mail servers
dig example.com TXT # SPF, DKIM
dig example.com NS # authoritative NS
dig example.com ANY # everything available (ChannelBind may reject this)
+short: the quick answer
The default output is verbose. +short keeps only the answer:
$ dig example.com +short
93.184.216.34
$ dig example.com MX +short
10 mail.example.com.
20 backup-mail.example.com.
Handy in scripts, but too terse for debugging.
Choosing a server
dig @8.8.8.8 example.com # query Google DNS
dig @1.1.1.1 example.com # query Cloudflare
dig @ns1.example.com example.com # query the authoritative server
Without @, dig uses /etc/resolv.conf. This matters during debugging: a local
resolver may be returning a cached stale answer.
+trace: the full resolution path
Shows each hop from the root down to the authoritative server:
$ dig example.com +trace
;; . root NS
;; com. .com TLD NS
;; example.com. authoritative NS
;; example.com. 93.184.216.34
Each hop is a separate non-recursive query. When something "works here but not there," +trace shows exactly where the chain breaks.
Reverse DNS
dig -x 93.184.216.34
;; ANSWER:
34.216.184.93.in-addr.arpa. PTR example.com.
PTR records live in the in-addr.arpa zone. They are often out of sync with the A record (forward says one thing, reverse says another).
DNSSEC
dig example.com +dnssec
Shows RRSIG (signatures). +sigchase follows the chain of trust from the root.
Useful when DNSSEC validation fails and you need to locate the break.
Useful options
| Option | What it does |
|---|---|
+short | compact output |
+trace | full resolution path from root |
+dnssec | show RRSIG records |
+tcp | use [[tcp-handshake |
+notcp | UDP only |
+nostats | omit the stats footer |
+nocomments | suppress ;; comment lines |
+noall +answer | minimal: ANSWER section only |
+time=3 +tries=1 | 3-second timeout, one attempt |
+norec | non-recursive query (for authoritative servers) |
-p 5353 | alternate port (mDNS) |
A useful pattern
To see only the TTL and value:
dig example.com +noall +answer
example.com. 3600 IN A 93.184.216.34
If the TTL drops between queries, the resolver is caching. If it stays at 3600, you are getting a cache hit.
Query all types in parallel
for t in A AAAA MX NS TXT CAA SOA; do
echo "=== $t ==="
dig example.com $t +short
done
Troubleshooting
connection timed out; no servers could be reached
The resolver is unreachable. Check /etc/resolv.conf, the firewall, and the
network path.
SERVFAIL
The authoritative server returned an error. Often a DNSSEC validation problem,
or the upstream resolver has a stuck query. Try dig @8.8.8.8 to query a
different resolver.
NXDOMAIN
The domain does not exist. Check for a typo in the name, or the zone may not have been delegated yet.
REFUSED
The server will not answer this query (it does not allow external recursion). This is normal for authoritative servers. Query them only for their own zones.
Alternatives
host: simpler output, no auxiliary informationnslookup: older, but familiar on Windows and macOSdrill(LDNS): a modern replacement for dig from the same NLnet team, but dig is available everywhere