Getting comfortable with dig

dig has a reputation for being intimidating, mostly because of its long list of options. In practice, you only need a handful of them for everyday DNS troubleshooting. This guide covers the ones that matter, plus a configuration trick that makes dig's output much more readable.

Two kinds of arguments

Everything you pass to dig falls into one of two categories: arguments that define the DNS query itself, and arguments that control how the response is displayed. Keeping that distinction in mind makes the tool far less confusing.

Controlling the query

There are three things you typically want to specify in a DNS query:

  • Name — e.g., jvns.ca. The default is the empty name (.).
  • Query type — e.g., A or CNAME. The default is A.
  • Server — the DNS server to query, e.g., 8.8.8.8. The default comes from /etc/resolv.conf.

The argument order is:

dig @server type name

Some examples:

  • dig @8.8.8.8 jvns.ca — query Google's public DNS (8.8.8.8) for jvns.ca.
  • dig ns jvns.ca — fetch NS records for jvns.ca.

Reverse lookups with -x

For reverse DNS lookups, use -x:

$ dig -x 172.217.13.174
174.13.217.172.in-addr.arpa. 72888 IN	PTR	yul03s04-in-f14.1e100.net.

Under the hood, -x simply constructs a PTR query for the in-addr.arpa domain. The command dig -x 172.217.13.174 is equivalent to:

$ dig ptr 174.13.217.172.in-addr.arpa.
174.13.217.172.in-addr.arpa. 72888 IN	PTR	yul03s04-in-f14.1e100.net.

The -x flag just saves you the typing.

Formatting the output

The default dig output is verbose enough to be off-putting:

; <<>> DiG 9.16.20 <<>> -r jvns.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28629
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d87fc3022c0604d60100000061ab74857110b908b274494d (good)
;; QUESTION SECTION:
;jvns.ca.			IN	A

;; ANSWER SECTION:
jvns.ca.		276	IN	A	172.64.80.1

;; Query time: 9 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Dec 04 09:00:37 EST 2021
;; MSG SIZE  rcvd: 80

Most of the time you only care about a single line in the answer section (like jvns.ca. 276 IN A 172.64.80.1). Two formatting options help you get there quickly.

Option 1: +noall +answer

This restricts output to the Answer section of the response. For example, querying NS records for google.com:

$ dig +noall +answer ns google.com
google.com.		158564	IN	NS	ns4.google.com.
google.com.		158564	IN	NS	ns1.google.com.
google.com.		158564	IN	NS	ns2.google.com.
google.com.		158564	IN	NS	ns3.google.com.

Each record line follows this structure:

NAME         TTL            TYPE   CONTENT
google.com   158564   IN    NS     ns3.google.com.

If you've ever wondered about IN, it's the query class — short for "internet." It's a vestige from when competing networks like chaosnet existed alongside the internet.

Option 2: +short

This strips the output down even further, showing only the record data:

$ dig +short ns google.com
ns2.google.com.
ns1.google.com.
ns4.google.com.
ns3.google.com.

Customizing defaults with .digrc

You don't have to type formatting flags every time. Create a ~/.digrc file with your preferred options, and dig will apply them automatically.

For instance, with +noall +answer in ~/.digrc, running dig jvns.ca yields:

$ dig jvns.ca
jvns.ca.		255	IN	A	172.64.80.1

That's much friendlier. If you ever need the full output — say, to inspect records in the Authority section — you can override the config file's formatting options on the command line:

$ dig +all jvns.ca

Tracing the resolution path

The +trace option simulates what a recursive resolver does: it starts at the root nameservers, follows the delegation chain through .com and so on, until it reaches the authoritative nameserver. That involves roughly 30 queries — dig fetches both A and AAAA records for each root nameserver, even though those addresses are already known.

While +trace is great for learning how DNS resolution works, it's rarely the tool for debugging an actual issue.

Why stick with dig?

Simpler alternatives like host and dog exist, but dig's verbosity is precisely what makes it useful. Running dig +all exposes every section of the response — Answer, Authority, and Additional — which some other tools blur together.

$ dig @h.root-servers.net. jvns.ca +all
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18229
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;jvns.ca.			IN	A

;; AUTHORITY SECTION:
ca.			172800	IN	NS	c.ca-servers.ca.
ca.			172800	IN	NS	j.ca-servers.ca.
ca.			172800	IN	NS	x.ca-servers.ca.
ca.			172800	IN	NS	any.ca-servers.ca.

;; ADDITIONAL SECTION:
c.ca-servers.ca.	172800	IN	A	185.159.196.2
j.ca-servers.ca.	172800	IN	A	198.182.167.1
x.ca-servers.ca.	172800	IN	A	199.253.250.68
any.ca-servers.ca.	172800	IN	A	199.4.144.2
c.ca-servers.ca.	172800	IN	AAAA	2620:10a:8053::2
j.ca-servers.ca.	172800	IN	AAAA	2001:500:83::1
x.ca-servers.ca.	172800	IN	AAAA	2620:10a:80ba::68
any.ca-servers.ca.	172800	IN	AAAA	2001:500:a7::2

;; Query time: 103 msec
;; SERVER: 198.97.190.53#53(198.97.190.53)
;; WHEN: Sat Dec 04 11:23:32 EST 2021
;; MSG SIZE  rcvd: 289

For comparison, dog displays additional records (marked with +) but doesn't clearly label which section they belong to, and it omits the Authority section entirely. host shows only answer records — none in the example above.

$ dog @h.root-servers.net. jvns.ca 
  NS ca.                2d0h00m00s A "c.ca-servers.ca."
  NS ca.                2d0h00m00s A "j.ca-servers.ca."
  NS ca.                2d0h00m00s A "x.ca-servers.ca."
  NS ca.                2d0h00m00s A "any.ca-servers.ca."
   A c.ca-servers.ca.   2d0h00m00s + 185.159.196.2
   A j.ca-servers.ca.   2d0h00m00s + 198.182.167.1
   A x.ca-servers.ca.   2d0h00m00s + 199.253.250.68
   A any.ca-servers.ca. 2d0h00m00s + 199.4.144.2
AAAA c.ca-servers.ca.   2d0h00m00s + 2620:10a:8053::2
AAAA j.ca-servers.ca.   2d0h00m00s + 2001:500:83::1
AAAA x.ca-servers.ca.   2d0h00m00s + 2620:10a:80ba::68
AAAA any.ca-servers.ca. 2d0h00m00s + 2001:500:a7::2

$ host jvns.ca h.root-servers.net
Using domain server:
Name: h.root-servers.net
Address: 198.97.190.53#53
Aliases:

Those simpler tools are perfectly valid, and drill's output looks similar to dig's, but dig's explicitness about response sections is what keeps it as the go-to for DNS work.

One limitation worth noting: there's no built-in dig option to show a short response that also includes the DNS status (like NOERROR or NXDOMAIN). A .digrc file won't solve that, but it will save you from wading through full default output on every query.