The dig Command Cheat Sheet: Practical DNS Debugging Recipes

The dig command (Domain Information Groper) is the tool most network engineers reach for when DNS misbehaves. Unlike a web dashboard, it shows you exactly what a resolver returned, including the raw flags, TTLs, and section headers. This cheat sheet collects the dig recipes you will actually use day to day, with real output you can compare against your own terminal.

The anatomy of a basic query

Run dig against a hostname and it prints a full response broken into labelled sections. The default query asks for an A record using whatever resolver your system is configured to use.

$ dig example.com

;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        3600    IN  A   93.184.216.34

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

The number before IN A is the TTL in seconds. The SERVER line tells you which resolver answered, which matters when you are chasing a stale cache. The QUESTION section echoes what you asked, and the ANSWER section is the payload.

The recipes you will use most

Most debugging sessions use only a handful of flags. The table below is the short list worth memorizing.

Getting clean output with +short

When you only care about the value, +short strips everything else. It is ideal for scripts and quick checks.

$ dig +short example.com
93.184.216.34

$ dig +short MX gmail.com
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.

If +short prints nothing, the record genuinely does not exist, or you asked for the wrong type. That empty result is itself useful information.

Querying a specific record type

Place the record type anywhere on the command line. These are the types you reach for when diagnosing mail and verification problems.

$ dig TXT example.com +short
"v=spf1 include:_spf.google.com ~all"

$ dig NS example.com +short
a.iana-servers.net.
b.iana-servers.net.

$ dig CNAME www.example.com +short
example.com.

$ dig AAAA example.com +short
2606:2800:220:1:248:1893:25c8:1946

A word on dig ANY: it once returned every record in one shot, but most authoritative servers now refuse ANY queries or return a minimal response (RFC 8482) to blunt amplification abuse. Query each type explicitly instead of relying on ANY.

Asking a specific resolver with @

The @server syntax bypasses your system resolver and asks a nameserver directly. This is how you confirm whether a change is live at the source versus stuck in a cache somewhere between you and the origin.

# Ask Cloudflare and Google public resolvers
$ dig @1.1.1.1 example.com +short
$ dig @8.8.8.8 example.com +short

# Ask the domain's own authoritative nameserver
$ dig @a.iana-servers.net example.com +short

When the authoritative server shows the new value but a public resolver still shows the old one, you are looking at normal caching, not a broken record. Wait for the TTL to expire.

Following the delegation with +trace

The +trace option walks the resolution path yourself, starting at the root servers, then the TLD servers, then the authoritative nameservers for the zone. It is the fastest way to spot a broken delegation or a lame nameserver.

$ dig +trace example.com

.           518400  IN  NS  a.root-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        3600    IN  A   93.184.216.34

Each block is a referral from one level to the next. If the trace stops before reaching your domain, the level where it halts is where the delegation is broken.

Reverse lookups with -x

The -x flag builds the reverse query for you, so you do not have to hand-assemble the in-addr.arpa name. Reverse DNS matters most for mail servers, where a missing or mismatched PTR record gets your messages flagged.

$ dig -x 8.8.8.8 +short
dns.google.

$ dig -x 2001:4860:4860::8888 +short
dns.google.

Reading the flags and sections

The HEADER line carries flags that explain the response at a glance. Learn these four and most responses become readable.

• aa: authoritative answer. The responding server owns this zone rather than caching it.
• rd: recursion desired. Your query asked the resolver to chase the full answer.
• ra: recursion available. The server is willing to recurse for you.
• ad: authenticated data. The answer passed DNSSEC validation.

The status field is just as important. NOERROR means success, NXDOMAIN means the name does not exist, and SERVFAIL usually points to a DNSSEC failure or an unreachable authoritative server.

The AUTHORITY and ADDITIONAL sections

Beyond ANSWER, a full response may include an AUTHORITY section listing the nameservers responsible for the zone, and an ADDITIONAL section with glue records (the IP addresses of those nameservers). When an answer is missing, a referral in the AUTHORITY section tells you who to ask next.

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net. 172800  IN  A   199.43.135.53

Timing, batching, and formatting

A few more options earn their place in a cheat sheet. The +stats output (shown by default) reports the query time in milliseconds, which is your first clue when resolution feels slow. You can also pass several names in one invocation, and you can combine formatting flags to produce exactly the lines you want.

# Query several names at once
$ dig +short example.com example.org example.net

# Answer only, with no comments or stats, ideal for diffing
$ dig +noall +answer example.com

# Compare query time across two resolvers
$ dig @1.1.1.1 example.com | grep "Query time"
$ dig @8.8.8.8 example.com | grep "Query time"

When a lookup returns a surprisingly high query time, repeat it. The second run is usually far faster because the resolver has now cached the answer, which both confirms caching is working and tells you the first query had to walk the full delegation.

A quick debugging workflow

1. Run dig +short to confirm what your resolver currently returns.
2. Query the authoritative server directly with @ to see the source of truth.
3. If the two differ, check the TTL and wait, or flush your local cache.
4. If the authoritative answer is wrong, fix the record at your DNS provider.
5. Use +trace when the delegation itself looks broken.

dig is precise, but it only shows you one vantage point at a time. When a change looks live locally but users elsewhere still see the old value, run the same lookup from dozens of networks at once with the Valla DNS propagation checker to see which regions have caught up. Pair it with our guides on reading TTLs and tracing a broken delegation, and you will spend far less time guessing whether the problem is your record or someone else's cache.