Linux dig Command Deep Dive: The Swiss Army Knife for DNS Queries#

Network engineers know: when DNS breaks, dig is the first tool to reach for. nslookup? Too basic. dig is the real deal.

Updated: May 13, 2026 08:27

Why dig Beats nslookup#

nslookup has been marked as “deprecated” by POSIX. It’s still around, but limited in functionality. dig is part of the BIND DNS suite and shows the complete DNS response structure—HEADER, QUESTION, ANSWER, AUTHORITY, and ADDITIONAL sections, each displayed clearly.

More importantly, dig supports +trace to track the complete resolution path. Want to see how google.com resolves step-by-step from root servers? dig can show you the entire chain.

DNS Protocol Basics: Understanding dig Output#

The first part of dig output is the HEADER:

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

opcode: QUERY: Operation code, standard query
status: NOERROR: Response status, NOERROR means success
id: 58641: Query ID, used to match request and response
flags: Critical flag bits
- qr: Query Response, indicates this is a response packet
- rd: Recursion Desired, requests recursive query
- ra: Recursion Available, server supports recursion

Core Usage: From Basics to Advanced#

1. Basic Query#

dig google.com

Output too long? Just get the ANSWER section:

dig +noall +answer google.com
# google.com.    299    IN    A    142.250.190.78

+noall disables all section displays, +answer only shows the ANSWER section.

2. Specify DNS Server#

dig @8.8.8.8 google.com    # Use Google DNS
dig @1.1.1.1 google.com    # Use Cloudflare DNS
dig @114.114.114.114 google.com    # Use 114 DNS

Different DNS servers may return different results (especially in CDN scenarios). Testing global DNS resolution consistency? Run multiple servers and compare.

3. Query Different Record Types#

DNS is more than just A records:

dig google.com MX      # Mail exchange records
dig google.com NS      # Nameserver records
dig google.com TXT     # Text records (SPF, DKIM)
dig google.com CNAME   # Alias records
dig google.com SOA     # Start of authority records
dig google.com AAAA    # IPv6 addresses

Real-world example: Check mail server priorities

dig +short gmail.com MX | sort -n
# 5 gmail-smtp-in.l.google.com.
# 10 alt1.gmail-smtp-in.l.google.com.
# 20 alt2.gmail-smtp-in.l.google.com.
# 30 alt3.gmail-smtp-in.l.google.com.
# 40 alt4.gmail-smtp-in.l.google.com.

Lower numbers mean higher priority. Failover? Look at these backup servers.

4. Reverse DNS Lookup (PTR Records)#

dig -x 8.8.8.8
# ;; ANSWER SECTION:
# 8.8.8.8.in-addr.arpa.    86120    IN    PTR    dns.google.

Reverse lookups are common in mail server configuration and IP ownership verification. Servers sending spam usually have abnormal PTR records.

5. Trace DNS Resolution Path (The Killer Feature)#

This is dig’s trump card:

dig +trace google.com

Output shows the complete resolution chain:

.            518400    IN    NS    a.root-servers.net.
.            518400    IN    NS    b.root-servers.net.
...
;; Received 525 bytes from 198.97.190.53#53(h.root-servers.net)

com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
...
;; Received 777 bytes from 192.5.6.30#53(a.gtld-servers.net)

google.com.    172800    IN    NS    ns1.google.com.
google.com.    172800    IN    NS    ns2.google.com.
...
;; Received 156 bytes from 192.42.93.30#53(a.gtld-servers.net)

google.com.    300    IN    A    142.250.190.78
;; Received 60 bytes from 216.239.38.10#53(ns4.google.com)

Resolution process:

Ask root servers (.)
Root servers return NS records for .com
Ask .com NS
.com NS returns NS records for google.com
Ask google.com NS, get the final A record

This feature is extremely effective for troubleshooting DNS hijacking and resolution anomalies.

6. Show TTL and Statistics#

dig +ttlid +stats google.com

TTL (Time To Live) determines cache duration:

google.com.    299    IN    A    142.250.190.78
                ^^^
                TTL = 299 seconds

Statistics:

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed May 13 08:27:36 CST 2026
;; MSG SIZE  rcvd: 60

Query time shows DNS response latency—useful when troubleshooting DNS server performance.

Real-World Cases#

Case 1: Troubleshooting CDN Resolution#

Users reported a CDN domain resolving to overseas nodes, causing slow access in China. Compare results from different DNS servers:

for dns in 8.8.8.8 114.114.114.114 223.5.5.5; do
  echo "=== DNS: $dns ==="
  dig +short @$dns cdn.example.com
done

Found that 114 DNS returned domestic IPs while Google DNS returned overseas IPs. Problem identified: GeoDNS misconfiguration.

Case 2: Verify SPF Record#

Email rejected, check SPF record:

dig +short TXT google.com | grep spf1
# "v=spf1 redirect=_spf.google.com"

SPF records are in TXT, format is v=spf1 .... Domains without this record often have emails marked as spam.

Case 3: Detect DNS Hijacking#

Some ISPs hijack DNS to return fake IPs. Use +trace to detect:

dig +trace example.com

If the ANSWER section source isn’t the domain’s real NS server but some strange IP, that’s hijacking.

Case 4: Batch Query Subdomains#

cat subdomains.txt | xargs -I {} dig +short {}.example.com

Combine with xargs for batch queries, common in subdomain enumeration.

Performance Optimization & Tips#

1. Pipeline Batch Queries#

echo -e "google.com\nbaidu.com\ngithub.com" | xargs -P 10 -I {} dig +short {}

-P 10 runs 10 concurrent queries, significant speed improvement.

2. JSON Output (Script-Friendly)#

dig +json google.com

BIND 9.16+ supports +json, making script parsing easier:

{
  "status": "NOERROR",
  "answer": [
    {
      "name": "google.com.",
      "type": "A",
      "ttl": 299,
      "data": "142.250.190.78"
    }
  ]
}

3. Short Output Mode#

dig +short google.com A
# 142.250.190.78

Just the IP, nothing else. Most common in scripts.

4. Specify Port (Non-Standard DNS Server)#

dig -p 5353 @127.0.0.1 google.com

Useful when testing local DNS servers (like dnsmasq).

Common Error Troubleshooting#

NXDOMAIN#

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345

Domain doesn’t exist. Possible causes:

Typo in domain name
Domain expired and deleted
DNS server misconfiguration

SERVFAIL#

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

Server processing failed. Possible causes:

Authoritative DNS server down
DNSSEC validation failed
Network issues

REFUSED#

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12345

Server refused query. Possible causes:

Authoritative DNS doesn’t allow recursive queries
ACL configuration restrictions

Comparison with Other Tools#

Tool	Recursive Query	Trace Resolution	JSON Output	Reverse Query	Use Case
dig	✅	✅	✅	✅	Professional DNS debugging
nslookup	✅	❌	❌	✅	Simple queries
host	✅	❌	❌	✅	Lightweight output
drill	✅	✅	❌	✅	PowerDNS suite

Recommendation: Use dig for daily work, dig +short in scripts, and dig +trace for deep troubleshooting.

Summary#

dig is the Swiss Army knife of DNS tools, far surpassing nslookup. Master +trace for tracking resolution paths, +short for script-friendly output, and -x for reverse queries, and you can handle 90% of DNS troubleshooting scenarios.

When DNS breaks, run dig +trace first, then analyze the output. That’s the battle-tested advice from veteran sysadmins.

Related Tools:

DNS Lookup Tool - Online DNS Query
IP Address Lookup - IP Geolocation Query
HTTP Status Codes - HTTP Status Code Reference