dig – Advanced DNS Lookup & Troubleshooting

1. What Is dig?

dig (Domain Information Groper) is a command-line DNS query tool included in the BIND DNS software suite. Available on Linux, macOS, and Windows (via BIND tools), it is the preferred tool for DNS diagnostics, testing, scripting, and troubleshooting among network engineers and system administrators.

Unlike nslookup (which has an interactive mode and inconsistent output formatting), dig produces structured, predictable output that is easy to parse in shell scripts and automation pipelines. It also provides complete DNS response data including all sections of the DNS message — something simpler tools omit.

Related pages: nslookup Command | How DNS Works | DNS Record Types | DNS Overview | Port Numbers (DNS port 53)

2. Basic dig Command Syntax

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

  @server  — Optional: DNS server to query (e.g., @8.8.8.8)
  name     — Domain name to query (e.g., example.com)
  type     — Record type (A, MX, NS, TXT, etc.; default is A)
  +options — Query flags (e.g., +short, +trace, +tcp)

Most Common Commands at a Glance

3. Understanding dig Output — All Five Sections

A full dig response is structured into up to five sections. Understanding each section is essential for DNS troubleshooting.

Annotated dig Output

$ dig example.com

; <<>> DiG 9.16.1-Ubuntu <<>> example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4578
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
                                                                     ↑ HEADER
;; QUESTION SECTION:                                                 ↑ QUESTION
;example.com.                 IN    A

;; ANSWER SECTION:                                                   ↑ ANSWER
example.com.       299        IN    A      93.184.216.34
│           ↑TTL              ↑Class↑Type  ↑ The IP address

;; AUTHORITY SECTION:                                                ↑ AUTHORITY
example.com.       172799     IN    NS     a.iana-servers.net.
example.com.       172799     IN    NS     b.iana-servers.net.

;; ADDITIONAL SECTION:                                               ↑ ADDITIONAL
a.iana-servers.net.    3600   IN    A      199.43.135.53
b.iana-servers.net.    3600   IN    A      199.43.133.53

;; Query time: 31 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)   ← Which DNS server responded
;; WHEN: Thu Jul 18 14:30:25 UTC 2024
;; MSG SIZE  rcvd: 135

Section-by-Section Reference

4. DNS Header Flags — What They Mean

The header line flags: qr rd ra contains one-letter codes that describe the nature of the DNS message. Understanding these flags is important for DNSSEC and troubleshooting.

Header Status Codes

5. DNS Record Types — Full Reference

6. dig Options and Flags — Complete Reference

7. Annotated Output Examples

A Record Query

$ dig google.com

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51421
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     ↑              ↑                  ↑ No authority (cached response from resolver)
     qr=response    NOERROR=success

;; QUESTION SECTION:
;google.com.                 IN  A
                                ↑ Queried for IPv4 address

;; ANSWER SECTION:
google.com.      299         IN   A    142.250.183.14
                 ↑ TTL(secs) ↑IN  ↑A   ↑ The IP address

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53   ← Local router/resolver answered
;; MSG SIZE rcvd: 55

MX Record Query — Mail Server Priorities

$ dig gmail.com MX

;; ANSWER SECTION:
gmail.com.  3599  IN  MX  5   gmail-smtp-in.l.google.com.   ← Priority 5 (highest)
gmail.com.  3599  IN  MX  10  alt1.gmail-smtp-in.l.google.com.
gmail.com.  3599  IN  MX  20  alt2.gmail-smtp-in.l.google.com.
gmail.com.  3599  IN  MX  30  alt3.gmail-smtp-in.l.google.com.
gmail.com.  3599  IN  MX  40  alt4.gmail-smtp-in.l.google.com.  ← Priority 40 (lowest)

Note: Lower MX priority number = preferred mail server
      Email senders try priority 5 first, fall back to 10, 20, 30, 40 in order

Reverse DNS (PTR) Lookup

$ dig -x 8.8.8.8

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.      IN  PTR
        ↑ dig automatically reverses the IP and appends .in-addr.arpa

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa. 86399 IN  PTR  dns.google.
                                       ↑ Hostname for 8.8.8.8

SOA Record — Zone Authority Details

$ dig example.com SOA

;; ANSWER SECTION:
example.com.  3600  IN  SOA  ns.icann.org. noc.dns.icann.org. (
                    2024041544  ← Serial number (zone version)
                    7200        ← Refresh (seconds between secondary NS checks)
                    3600        ← Retry (retry interval on refresh failure)
                    1209600     ← Expire (secondary stops serving after this many seconds)
                    3600        ← Negative TTL (how long to cache NXDOMAIN responses)
               )

NXDOMAIN — Domain Does Not Exist

$ dig nonexistent-domain-xyz123.com

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
                                    ↑ Domain does not exist in DNS
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
                                          ↑ No answer records

;; AUTHORITY SECTION:
com.   900  IN  SOA  a.gtld-servers.net. nstld.verisign-grs.com. ...
      ↑ SOA in authority section confirms NXDOMAIN is authoritative

8. dig +trace — Full DNS Resolution Path

dig +trace performs the entire DNS resolution from scratch, starting at the root (.) servers, instead of relying on your local resolver's cache. It shows every delegation step — from root to TLD to authoritative server.

$ dig www.example.com +trace

;; Tracing from root (.)
.           518400  IN  NS  a.root-servers.net.
.           518400  IN  NS  b.root-servers.net.
... (13 root servers listed)

;; Root server tells us: .com TLD is handled by:
com.        172800  IN  NS  a.gtld-servers.net.
com.        172800  IN  NS  b.gtld-servers.net.

;; TLD server tells us: example.com is handled by:
example.com.   172800  IN  NS  a.iana-servers.net.
example.com.   172800  IN  NS  b.iana-servers.net.

;; Authoritative server (a.iana-servers.net) answers:
www.example.com.  86400  IN  A  93.184.216.34   ← Final answer
a.iana-servers.net — flag: aa (Authoritative Answer)

9. Querying Specific DNS Servers — Testing and Comparison

The @server syntax directs dig to bypass your default resolver and query a specific DNS server directly. This is invaluable for:

• Comparing what different resolvers return (checking for DNS hijacking or filtering)
• Querying an authoritative server directly to verify published records
• Testing a new DNS server before cutover
• Verifying DNS record propagation after a change

! Query Google's public DNS
dig @8.8.8.8 example.com

! Query Cloudflare's DNS
dig @1.1.1.1 example.com

! Query the domain's own authoritative nameserver directly
! (first find the NS, then query it)
dig example.com NS +short
→ a.iana-servers.net.
dig @a.iana-servers.net example.com

! Compare TTL between your resolver (cached) and authoritative server
dig example.com +noall +answer          ! Your resolver's cached TTL (may be low)
dig @a.iana-servers.net example.com +noall +answer  ! Authoritative TTL (full value)

dig @8.8.8.8 definitely-nonexistent-domain.com   ! Should return NXDOMAIN
dig definitely-nonexistent-domain.com            ! Your local resolver — does it match?

10. Zone Transfers (AXFR) — Security Implications

A zone transfer (AXFR — Authoritative Transfer) requests a complete copy of an entire DNS zone from a nameserver. If permitted, it reveals every hostname, IP address, and service in that zone — a significant security exposure.

! Attempt a full zone transfer
dig @ns1.example.com example.com AXFR

! If zone transfer is ALLOWED (security risk!):
; <<>> DiG 9.16.1 <<>> @ns1.example.com example.com AXFR
example.com.   3600  IN  SOA   ns1.example.com. admin.example.com. ...
example.com.   3600  IN  NS    ns1.example.com.
example.com.   3600  IN  A     93.184.216.34
mail.example.com.   3600  IN  A  93.184.216.40
vpn.example.com.    3600  IN  A  93.184.216.50
...all records exposed...

! If zone transfer is BLOCKED (correct security posture):
; Transfer failed. Received 1 messages.
; TRANSFER: Transfer failed.

11. Real-World DNS Troubleshooting with dig

DNS problems are among the most common connectivity issues. See also Troubleshooting Connectivity for the broader diagnostic workflow.

Systematic Troubleshooting Flow

! Step 1: Basic resolution — does the domain resolve at all?
dig www.example.com
! Check: NOERROR in header? IP in ANSWER section?

! Step 2: If failure — try a known-good public resolver to rule out local resolver issue
dig @8.8.8.8 www.example.com
! If works with 8.8.8.8 but not locally → local DNS server problem

! Step 3: Trace the delegation chain to find where it breaks
dig www.example.com +trace
! Watch for delegation failures at root, TLD, or authoritative level

! Step 4: Check mail configuration (common troubleshooting request)
dig example.com MX
! Verify MX records exist; check priorities; confirm hostnames resolve

! Step 5: Verify email sender authentication
dig example.com TXT
! Look for: v=spf1... (SPF), v=DKIM1... (DKIM), v=DMARC1 (DMARC)

! Step 6: Check reverse DNS for IP (email deliverability)
dig -x 203.0.113.25
! Mail servers check PTR records; mismatched PTR = email delivery issues

! Step 7: Verify authoritative servers are correct
dig example.com NS
! Confirm they match what the domain registrar shows

! Step 8: Check SOA serial for zone propagation
dig example.com SOA @ns1.example.com
dig example.com SOA @ns2.example.com
! Serial numbers should match; different serials = zone replication lag

Common Diagnostic Scenarios

12. dig for Scripting and Automation

The +short flag and batch mode make dig ideal for automation.

! Get just the IP address (perfect for variable assignment in scripts)
IP=$(dig example.com +short)
echo "example.com resolves to: $IP"

! Check if a domain exists (returns empty if NXDOMAIN)
RESULT=$(dig nonexistent.example.com +short)
if [ -z "$RESULT" ]; then
  echo "Domain does not resolve"
fi

! Batch lookup — check multiple domains from a file
cat domains.txt
  example.com
  google.com
  cisco.com

dig -f domains.txt +short

! Get TTL for a record (useful for monitoring cache expiry)
dig example.com +noall +answer | awk '{print $2}'

! Check if an MX record exists (returns empty if no MX)
MX=$(dig example.com MX +short)
[ -z "$MX" ] && echo "No MX records — email not configured"

! Compare resolution across DNS providers
for server in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo -n "$server: "
  dig @$server example.com +short
done

13. Common Misconceptions About dig

• "dig always queries the authoritative server."
  By default, dig queries your configured resolver (usually your local DNS server or ISP's resolver), which may serve a cached answer. To query an authoritative server directly, you must specify it with @server or use +trace. The aa flag in the header confirms whether the response came from an authoritative source.
• "An empty ANSWER section means the domain doesn't exist."
  NOERROR with an empty ANSWER section means the domain exists but has no record of the requested type — for example, querying dig example.com AAAA on a domain with no IPv6 address returns NOERROR with no ANSWER. NXDOMAIN is the status code for a non-existent domain.
• "+short always shows just the IP."
  +short shows just the record data, whatever type was queried. For A records it's an IP. For MX it's the priority and mail server hostname. For TXT it's the quoted text string. The format depends on the record type, not just the flag.
• "dig -x requires me to manually construct the in-addr.arpa query."
  The -x flag automatically reverses the IP octets and appends .in-addr.arpa. — dig -x 8.8.8.8 is identical to dig 8.8.8.8.in-addr.arpa PTR. You never need to construct the reverse zone name manually.
• "SERVFAIL always means the domain has an error."
  SERVFAIL can result from DNSSEC validation failure (the signatures don't verify), the authoritative server being unreachable, a lame delegation (NS record points to a server that doesn't serve the zone), or a resolver bug. Use +cd (checking disabled) to test whether DNSSEC is the cause: dig example.com +cd.

14. Key Points & Exam Tips

• dig = Domain Information Groper — advanced DNS query and diagnostic tool. Preferred over nslookup for detail and scripting.
• Default query type is A (IPv4). Specify other types: dig example.com MX.
• Use @server to query a specific DNS server: dig @8.8.8.8 example.com.
• Five output sections: HEADER (status/flags), QUESTION (what was asked), ANSWER (the result), AUTHORITY (authoritative NS), ADDITIONAL (glue records).
• Status codes: NOERROR = success; NXDOMAIN = domain doesn't exist; SERVFAIL = server error; REFUSED = server won't answer.
• +short: concise output for scripting. +trace: full root-to- authority delegation trace. +tcp: force TCP (for large responses).
• -x IP: reverse DNS lookup (PTR record) — dig -x 8.8.8.8.
• aa flag: Authoritative Answer — response came directly from the zone's nameserver, not a cache.
• ad flag: Authenticated Data — DNSSEC validated the response.
• AXFR: zone transfer request — should always be blocked/refused in production. An open zone transfer is a security vulnerability exposing the entire DNS namespace.
• MX priority: lower number = higher preference. Email tries lowest number first.

Related pages: nslookup Command | How DNS Works | DNS Record Types | DNS Overview | Port Numbers (DNS port 53)

15. dig – Advanced DNS Lookup Quiz