How to Use dig for Deep DNS Troubleshooting (With Real Examples)

dig (Domain Information Groper) is the command-line tool serious admins use to see exactly what DNS is returning — no browser caching, no guessing. Learning to read its output turns DNS troubleshooting from mystery into method. Here are the queries you will use most.

The basics

dig example.com A

This asks your default resolver for the A record. Add +short for just the answer:

dig +short example.com A

Query specific record types

dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com SOA

These are how you verify MX, delegation, SPF/DKIM/DMARC TXT records, and the SOA.

Ask a specific resolver

dig @1.1.1.1 example.com A

Querying different public resolvers is how you check whether a change has been picked up in different places — useful for confirming propagation.

Trace the whole delegation

dig +trace example.com

This walks from the root down through the TLD to the authoritative servers, showing each referral — exactly the resolution chain. Invaluable when delegation is broken.

Reverse lookups

dig -x 203.0.113.10

This checks the PTR record for an IP.

Reading the output

status — NOERROR is good; NXDOMAIN means the name does not exist; SERVFAIL means the resolver failed (often DNSSEC validation or a broken authoritative server).
flags — aa means an authoritative answer; ad means DNSSEC-validated.
ANSWER / AUTHORITY / ADDITIONAL sections — the answer, the responsible nameservers, and extra helpful records.
TTL — the number beside each record, counting down as it is cached.

Frequently asked questions

Why does dig show a different answer than my browser?

Your browser and OS cache DNS, so they may serve an older answer. dig queries fresh (especially against a specified resolver), which is why it is the reliable source of truth during changes.

What does a SERVFAIL mean?

The resolver could not complete the lookup — commonly a broken authoritative server or a DNSSEC validation failure. Try dig +trace and query the authoritative servers directly to isolate where it breaks.

How do I check a record on the authoritative server, bypassing caches?

Query the domain's nameserver directly, for example dig @ns1.example.com example.com A. That shows the true published record without any resolver caching in the way.