How to use the dig command to troubleshoot DNS?

To use the dig command to troubleshoot DNS, run dig name type, such as dig example.com A, and read the status in the header and the records in the ANSWER section. Then narrow the problem down by changing who you ask: dig @server queries a specific resolver or authoritative nameserver, +norecurse checks what a nameserver itself holds, +trace follows the delegation from the root servers down, and +dnssec and +cd tell you whether DNSSEC validation is the cause of a failure. Comparing the answers from each step shows you exactly where things go wrong.

dig (domain information groper) is part of the BIND tools and is the standard DNS debugging utility for administrators. It shows the raw response with very little interpretation, which is exactly what you want when something isn't working. This guide explains how to install it, how to read every part of its output, the options that matter most, and a set of practical troubleshooting scenarios you can work through when a domain misbehaves.

Installing dig

dig comes preinstalled on macOS and most Linux server images. If it's missing:

# Debian and Ubuntu
sudo apt install dnsutils

# Fedora, RHEL, Rocky Linux, AlmaLinux
sudo dnf install bind-utils

# Alpine
apk add bind-tools

# macOS with Homebrew, for a newer version than the system one
brew install bind

On Windows, the easiest route is to use dig inside WSL, or install the BIND tools for Windows. PowerShell's Resolve-DnsName is a good native alternative, but this guide focuses on dig.

Check your version:

dig -v

DiG 9.20.4

Anything from BIND 9.16 onwards supports all the options in this guide.

The Basic Syntax

dig [@server] [name] [type] [+options]

• @server: The DNS server to ask. If you leave it out, dig uses the resolvers from /etc/resolv.conf.
• name: The domain name to look up.
• type: The record type, such as A, AAAA, MX, TXT, NS, SOA or CAA. The default is A.
• +options: Query and display options, covered below.

The order is flexible, so dig MX example.com and dig example.com MX both work.

Reading dig's Output

Here's the full output of a simple query:

dig example.com A

; <<>> DiG 9.20.4 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41927
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
example.com.		300	IN	A	192.0.2.10

;; Query time: 18 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sat Oct 17 09:12:44 BST 2026
;; MSG SIZE  rcvd: 56

The Header

The ->>HEADER<<- line holds the single most important field: status, the response code.

Status	Meaning	Typical cause
NOERROR	The query succeeded	Normal, even if the answer section is empty
NXDOMAIN	The name doesn't exist	Typo, missing record, wrong zone
SERVFAIL	The server couldn't produce an answer	DNSSEC failure, broken delegation, unreachable nameservers
REFUSED	The server won't answer this query	Asking a server that isn't authoritative and doesn't offer recursion
FORMERR	The server couldn't parse the query	Very old or broken server, often EDNS-related
NOTIMP	The query type isn't supported	Rare, some servers with unusual types

The Flags

The flags line tells you what kind of answer you got:

• qr: This is a response.
• aa: Authoritative answer. The server answering is authoritative for the zone, not a cache.
• rd: Recursion desired. dig asked for recursion, which it does by default.
• ra: Recursion available. The server offers recursive lookups.
• ad: Authenticated data. A validating resolver confirmed the answer with DNSSEC.
• cd: Checking disabled. You asked the resolver to skip DNSSEC validation.
• tc: Truncated. The answer didn't fit in the UDP response.

The counts after the flags show how many records are in each section.

The Sections

• QUESTION: What you asked, echoed back.
• ANSWER: The records that answer your question.
• AUTHORITY: Nameservers for the zone, or an SOA record when the answer is negative.
• ADDITIONAL: Extra helpful records, such as IP addresses for nameservers. The OPT PSEUDOSECTION shows EDNS details, including the UDP buffer size.

The Footer

The final lines show the query time, which server answered and over which transport, when, and the response size. A query time of 0 or 1 ms usually means the answer came from a local cache.

Options You'll Use All the Time

Trimming the Output

# Just the values
dig example.com MX +short

# Only the answer section, but with names, TTLs and types
dig example.com MX +noall +answer

# Answer and authority sections
dig example.com MX +noall +answer +authority

# Long records such as DNSKEY or SOA split over several lines with comments
dig example.com SOA +multiline +noall +answer

example.com.		3600 IN	SOA ns1.dns-host.example. hostmaster.example.com. (
				2026101701 ; serial
				3600       ; refresh (1 hour)
				900        ; retry (15 minutes)
				1209600    ; expire (2 weeks)
				300        ; minimum (5 minutes)
				)

+short is quick, but it hides the status code. When you're troubleshooting, an empty +short result could mean NXDOMAIN, SERVFAIL or simply no record of that type. Use +noall +answer +comments or the full output when the result matters.

Setting Defaults in ~/.digrc

If you always want the same display options, put them in ~/.digrc:

+noall +answer

Every dig command will now behave as if those options were typed. Override them on the command line when you need the full output, for example with +all.

Choosing the Server and Transport

dig @1.1.1.1 example.com          # ask a specific resolver
dig @ns1.dns-host.example example.com   # ask an authoritative nameserver
dig -4 example.com                # use IPv4 only
dig -6 example.com                # use IPv6 only
dig -p 5353 @127.0.0.1 example.com   # use a non-standard port
dig +tcp example.com              # use TCP instead of UDP

Timeouts and Retries

By default, dig waits a few seconds and retries a couple of times. When you're testing a slow or flaky server, make that explicit:

dig @192.0.2.53 example.com +time=2 +tries=1

Troubleshooting Scenarios

Scenario 1: Is the Record Right at the Source?

When someone reports the wrong IP address, first find out what the authoritative nameservers actually serve. Find them:

dig example.com NS +short

ns1.dns-host.example.
ns2.dns-host.example.

Then ask one directly, with recursion turned off:

dig @ns1.dns-host.example www.example.com A +norecurse

Look for the aa flag in the response. It confirms you're getting the zone's own data, not a cached copy. If the answer is wrong here, the problem is in the zone, so fix it at your DNS provider. If it's right here but wrong at a resolver, it's a caching issue and will resolve itself when the TTL runs out.

Ask every nameserver, not just the first. If they disagree, your secondaries may not be updating. The +nssearch option checks the SOA serial on all of them in one go:

dig example.com +nssearch

SOA ns1.dns-host.example. hostmaster.example.com. 2026101701 3600 900 1209600 300 from server 192.0.2.53 in 11 ms.
SOA ns1.dns-host.example. hostmaster.example.com. 2026101601 3600 900 1209600 300 from server 198.51.100.53 in 24 ms.

The second server has an older serial, so it hasn't picked up the latest change.

Scenario 2: Follow the Delegation With +trace

+trace makes dig act like a resolver. It starts at the root servers and follows each referral down to the authoritative answer, printing every step:

dig www.example.com +trace

.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
;; Received 1171 bytes from 198.41.0.4#53(a.root-servers.net) in 15 ms

example.com.		172800	IN	NS	ns1.dns-host.example.
example.com.		172800	IN	NS	ns2.dns-host.example.
;; Received 680 bytes from 192.5.6.30#53(a.gtld-servers.net) in 22 ms

www.example.com.	300	IN	A	192.0.2.10
;; Received 60 bytes from 192.0.2.53#53(ns1.dns-host.example) in 14 ms

The output is trimmed here for readability. Use +trace when:

• You've just changed nameservers: The .com step shows what the registry is really publishing, regardless of caches.
• A domain fails everywhere: The trace shows the step where it breaks, such as a TLD pointing at nameservers that don't answer.
• You suspect a lame delegation: The parent lists a nameserver that doesn't actually serve the zone, so the final step times out or returns REFUSED.

Because each step may go to a different server chosen at random, repeat the trace a few times if you suspect only some nameservers are broken.

Scenario 3: NXDOMAIN or Just No Record?

These two look the same in a browser but mean different things:

dig nothere.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5512
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.		300	IN	SOA	ns1.dns-host.example. hostmaster.example.com. 2026101701 3600 900 1209600 300

dig www.example.com AAAA

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61733
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

• NXDOMAIN: No records of any type exist at that name. Check for typos, and check you created the record in the right zone.
• NOERROR with zero answers, often called NODATA: The name exists, but not with that record type. Here, www has an A record but no AAAA record.

In both cases, the SOA in the authority section tells you how long the negative answer will be cached. That's the lower of the SOA record's own TTL and its last field (the "minimum"), which is 300 seconds here. If you look up a record before creating it, resolvers may remember that it doesn't exist for that long.

Scenario 4: SERVFAIL and DNSSEC

SERVFAIL means the resolver tried and failed. One of the most common causes is a broken DNSSEC chain, for example a stale DS record after changing DNS providers. Test it by asking the resolver to skip validation with +cd:

dig @1.1.1.1 example.com A

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2210

dig @1.1.1.1 example.com A +cd

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39107
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

If the query works with +cd and fails without it, DNSSEC validation is the problem. Compare the DS record at the parent with the keys the zone publishes:

dig example.com DS +short
dig example.com DNSKEY +multiline +noall +answer | grep -E 'key id|DNSKEY'

The DS record's first number is a key tag. With +multiline, dig prints the key tag of each DNSKEY as a comment (key id = 2371). If no DNSKEY with flags 257 has a key tag matching the DS record, the chain is broken.

When DNSSEC is working, a validating resolver sets the ad flag:

dig @1.1.1.1 example.com A +dnssec +noall +comments | grep flags

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Many resolvers also include Extended DNS Errors in a failing response, which dig shows in the OPT PSEUDOSECTION as an EDE: line, such as EDE: 9 (DNSKEY Missing). If you see one, it usually names the problem directly.

If +cd doesn't help, the issue is more likely the nameservers themselves. Query each authoritative server directly, as in Scenario 1, and look for timeouts or REFUSED.

Scenario 5: Timeouts and Unreachable Servers

When a server doesn't respond at all, dig reports it clearly:

;; communications error to 192.0.2.53#53: timed out
;; no servers could be reached

Work out where the problem is:

# Does a public resolver work? If so, your local resolver may be the problem.
dig @1.1.1.1 example.com +time=2 +tries=1

# Does the authoritative server respond over UDP and TCP?
dig @192.0.2.53 example.com +time=2 +tries=1
dig @192.0.2.53 example.com +tcp +time=2 +tries=1

If UDP fails but TCP works, or the reverse, a firewall is probably blocking one of them. Authoritative servers must answer on both UDP and TCP port 53.

Scenario 6: Truncated and Oversized Responses

Large answers, such as zones with many TXT records or DNSSEC signatures, may not fit in a UDP packet. The server sets the tc flag and the client is expected to retry over TCP. dig does this automatically and prints a note:

;; Truncated, retrying in TCP mode.

To see the truncated UDP response itself, use +ignore:

dig example.com TXT +ignore +bufsize=512

If a domain resolves for some users but not others, and the response is large, check that TCP works to every nameserver and that nothing in the path drops large UDP packets. Most modern resolvers advertise a buffer size of 1,232 bytes, which you'll see in the udp: field of the OPT PSEUDOSECTION.

Scenario 7: Which Server Actually Answered?

Big resolvers and DNS providers use anycast, so the same IP address is served from many locations. When results differ between users, it helps to know which instance answered. Many servers support the NSID option:

dig @ns1.dns-host.example example.com +nsid +noall +comments | grep NSID

; NSID: 6c 68 72 31 ("lhr1")

Some servers also answer a CHAOS-class query for id.server or hostname.bind:

dig @1.1.1.1 id.server CH TXT +short

Not every server supports these, and some deliberately return nothing.

Scenario 8: Checking Reverse DNS

Mail delivery problems often come down to reverse DNS. dig -x looks up the PTR record for an IP address:

dig -x 203.0.113.25 +short
dig -x 2001:db8::25 +short

mail.example.com.
mail.example.com.

Then confirm the name points back to the same address, which many mail servers check:

dig mail.example.com A +short

Running Many Queries at Once

dig can read queries from a file with -f, one per line, using the same syntax as the command line:

example.com A
example.com MX
_dmarc.example.com TXT
www.example.com CNAME

dig -f queries.txt +noall +answer

That's handy for checking a fixed set of records before and after a change. Save the output to two files and compare them with diff.

Quick Reference

Task	Command
Basic lookup	dig example.com A
Values only	dig example.com MX +short
Clean answer with TTLs	dig example.com +noall +answer
Ask a specific server	dig @8.8.8.8 example.com
Check authoritative data	dig @ns1.dns-host.example example.com +norecurse
Follow the delegation	dig example.com +trace
Compare SOA serials	dig example.com +nssearch
Check DNSSEC validation	dig @1.1.1.1 example.com +dnssec
Bypass DNSSEC validation	dig @1.1.1.1 example.com +cd
Force TCP	dig example.com +tcp
Reverse lookup	dig -x 192.0.2.10
Identify anycast instance	dig @server example.com +nsid
Batch queries	dig -f queries.txt

---

FAQ: Using dig

---

Conclusion

dig is the most useful single tool for troubleshooting DNS because it shows you exactly what a server said, with nothing hidden. Read the status first, then the flags and sections, and you'll quickly know whether you're dealing with a missing record, a negative answer, a failed lookup or a cached copy.

From there, troubleshooting is a matter of changing who you ask. Query the authoritative nameservers with +norecurse to check the source, use +trace to follow the delegation, compare +dnssec and +cd to isolate validation failures, and test TCP, timeouts and buffer sizes when responses go missing. With those few options, you can track down almost any DNS problem to the exact place it breaks.