The Complete dig Command Guide: Every Flag and Option Explained

dig (Domain Information Groper) is the most powerful DNS query tool available from the command line. It is the tool I reach for first whenever I need to inspect DNS records, debug resolution failures, or verify that a zone change has taken effect. While nslookup and host exist and have their uses, dig gives you the full picture: response flags, authority records, TTL values, query timing, and the ability to trace the entire resolution chain from root servers to the authoritative nameserver.

This guide covers everything you need to know about dig, from basic syntax to advanced scripting. Every flag and option is demonstrated with real output so you can see exactly what to expect.

Installing dig

On most systems, dig is already installed. It ships as part of the BIND DNS utilities package.

Linux (Debian/Ubuntu):

sudo apt install dnsutils

Linux (RHEL/CentOS/Fedora):

sudo yum install bind-utils

macOS:

dig is included with the system. No installation needed.

Windows:

dig is not natively available on Windows. Your best options are:

• WSL (Windows Subsystem for Linux): Install any Linux distribution and use dig normally.
• BIND for Windows: Download the BIND installer from ISC, which includes dig as a standalone utility.

To verify your installation, run:

dig -v

This prints the version number. If you see output like DiG 9.18.x, you are ready to go.

Basic Syntax

The general form of a dig command is:

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

• @server (optional) — The DNS server to query. If omitted, dig uses the servers listed in /etc/resolv.conf.
• name — The domain name you want to look up.
• type (optional) — The record type: A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, SRV, CAA, ANY. Defaults to A if omitted.
• options — Flags that control output format and query behavior (like +short, +trace, +dnssec).

Anatomy of dig Output

Here is the full output of a basic query, annotated section by section:

$ dig example.com A

; <<>> DiG 9.18.28 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41592
;; 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.            86400   IN      A       93.184.216.34

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Wed Feb 12 10:15:30 UTC 2026
;; MSG SIZE  rcvd: 56

Header line — opcode: QUERY confirms this is a standard query. status: NOERROR means the query succeeded. Other status codes include NXDOMAIN (domain does not exist), SERVFAIL (server error), and REFUSED.

Flags — qr (query response), rd (recursion desired), ra (recursion available). If you query an authoritative server directly, you will also see aa (authoritative answer).

QUESTION SECTION — Echoes back what you asked: the domain name, class (IN for Internet), and record type.

ANSWER SECTION — The actual DNS records. Each line shows the name, TTL in seconds (86400 = 24 hours), class, record type, and the record data. This is the section you care about most of the time.

AUTHORITY SECTION — When present, lists the authoritative nameservers for the zone. Often empty when querying a recursive resolver that already has the answer cached.

ADDITIONAL SECTION — Glue records (IP addresses of nameservers listed in the authority section). The OPT PSEUDOSECTION shows EDNS information.

Query statistics — How long the query took (23 msec), which server answered, when the query was made, and the response message size.

Essential Flags

These are the flags I use most often. Each one changes how dig behaves or what it shows you.

+short — Just the Answer

Strips everything except the record data. Perfect for quick checks.

$ dig example.com A +short
93.184.216.34

$ dig example.com MX +short
10 mail.example.com.

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

+noall +answer — Clean Table Output

Removes all sections except the answer. You get a clean, tabular format with TTLs and record types — more detail than +short but without the noise.

$ dig example.com A +noall +answer
example.com.            86400   IN      A       93.184.216.34

This is my go-to format for comparing records across multiple nameservers, because the output is consistent and easy to diff.

+trace — Full Recursive Resolution from Root

+trace makes dig start at the root DNS servers and follow the delegation chain all the way down, showing you the response at each level. I cover this in detail in the +trace deep dive section below.

dig example.com +trace

+dnssec — Request DNSSEC Records

Asks the server to include DNSSEC-related records (RRSIG signatures, NSEC/NSEC3 records) in the response. Essential for verifying that a domain's DNSSEC configuration is working. See What Is DNSSEC? for background on how DNSSEC works.

$ dig example.com A +dnssec +noall +answer
example.com.            86400   IN      A       93.184.216.34
example.com.            86400   IN      RRSIG   A 13 2 86400 20260301000000 20260212000000 12345 example.com. <signature-data>

The presence of an RRSIG record alongside the A record confirms that the zone is DNSSEC-signed. If you only see the A record with no RRSIG, either the zone is unsigned or the server is stripping DNSSEC data.

+tcp — Force TCP

DNS normally uses UDP. The +tcp flag forces the query over TCP instead. This is useful when responses are larger than the UDP buffer size (causing truncation), when debugging TCP-specific connectivity issues, or when testing whether your nameserver handles TCP queries correctly.

dig example.com A +tcp

+multiline — Readable SOA Output

SOA records pack a lot of information into a single line that is difficult to read. The +multiline flag reformats it with labeled fields.

$ dig example.com SOA +multiline +noall +answer
example.com.            86400 IN SOA ns1.example.com. admin.example.com. (
                                2026021201 ; serial
                                3600       ; refresh (1 hour)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )

+nocmd +nocomments +nostats — Machine-Parseable Output

Removes the header, comments, and query statistics, leaving only the section data. Combined with +noall +answer, this produces output that is clean enough for scripts.

$ dig example.com A +nocmd +nocomments +nostats +noall +answer
example.com.            86400   IN      A       93.184.216.34

+norecurse — Non-Recursive Query

Sends the query without the RD (Recursion Desired) flag. This is how you test what a nameserver knows directly without asking it to go look things up on your behalf. Useful for querying authoritative servers to confirm they hold the expected records.

dig @ns1.example.com example.com A +norecurse

If the server is authoritative for the domain, you will get an answer with the aa flag set. If it is not authoritative and cannot recurse, you will get a referral (delegation records) or no answer at all.

Querying All Record Types

dig can query any DNS record type. Here are examples for the most common ones. For a detailed explanation of what each type does, see Understanding DNS Record Types.

# IPv4 address
dig example.com A +short

# IPv6 address
dig example.com AAAA +short

# Mail servers (with priority)
dig example.com MX +short

# TXT records (SPF, DKIM, DMARC, domain verification)
dig example.com TXT +short

# Nameservers
dig example.com NS +short

# Start of Authority (zone metadata)
dig example.com SOA +short

# Canonical name (alias)
dig www.example.com CNAME +short

# Reverse DNS (PTR)
dig -x 93.184.216.34

# Service records (SIP, XMPP, etc.)
dig _sip._tcp.example.com SRV +short

# Certificate Authority Authorization
dig example.com CAA +short

# All records (many servers restrict this)
dig example.com ANY +noall +answer

A note on ANY queries: many DNS operators and resolvers now return minimal or empty responses to ANY queries as a defense against amplification attacks. Do not rely on ANY for discovering all records — query each type individually for reliable results.

Custom Nameservers

By default, dig queries whatever resolver is configured in /etc/resolv.conf (usually your ISP or a local caching resolver). The @ syntax lets you query any server directly.

Query a public resolver:

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

Query an authoritative nameserver directly:

# First, find the authoritative nameservers
dig example.com NS +short

# Then query one of them directly
dig @a.iana-servers.net example.com A

Querying an authoritative server directly bypasses all caching. The response will have the aa (authoritative answer) flag set and will show the real TTL value rather than a countdown from a cached copy. This is critical when you have made a DNS change and want to confirm the authoritative server is returning the new record, even if resolvers still have the old one cached.

Comparing responses across nameservers:

When troubleshooting inconsistent DNS behavior, I query multiple nameservers and compare the results:

dig @ns1.example.com example.com A +short
dig @ns2.example.com example.com A +short
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short

If the authoritative servers disagree, you have a zone synchronization problem. If the authoritative servers agree but public resolvers show stale data, it is a caching/TTL issue.

Reverse DNS

Reverse DNS maps an IP address back to a hostname. dig makes this easy with the -x flag:

$ dig -x 8.8.8.8 +short
dns.google.

Under the hood, -x 8.8.8.8 translates to a PTR query on 8.8.8.8.in-addr.arpa.. The octets of the IP address are reversed and appended to the in-addr.arpa zone. You can do this manually if you prefer:

dig 8.8.8.8.in-addr.arpa. PTR +short

For IPv6, reverse DNS uses the ip6.arpa zone with each nibble of the expanded address separated by dots. The -x flag handles this automatically:

dig -x 2001:4860:4860::8888 +short

Reverse DNS is important for email deliverability (mail servers check that the sending IP's PTR record matches the HELO hostname), for security auditing, and for identifying what is behind an IP address.

+trace Deep Dive

The +trace flag is the most powerful diagnostic option in dig. It starts at the root DNS servers and follows the delegation chain step by step, showing you exactly how a domain name resolves. This is how you diagnose delegation problems, broken nameservers, and misconfigured zones. For a deeper explanation of how DNS resolution works at each stage, see How DNS Queries Work.

$ dig example.com A +trace

; <<>> DiG 9.18.28 <<>> example.com A +trace
;; global options: +cmd
.                       86400   IN      NS      a.root-servers.net.
.                       86400   IN      NS      b.root-servers.net.
.                       86400   IN      NS      c.root-servers.net.
;; [... other root servers omitted for brevity ...]
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 12 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
;; [... other .com TLD servers omitted ...]
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 18 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 266 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms

example.com.            86400   IN      A       93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 31 ms

Here is what happens at each step:

Step 1: Root servers — dig queries a root server for example.com. The root server does not know the answer, but it knows who is responsible for .com — so it returns NS records for the .com TLD servers. The line Received 239 bytes from 192.168.1.1 shows that dig got the initial list of root servers from your local resolver.

Step 2: TLD servers — dig queries one of the .com TLD servers (a.root-servers.net referred it). The TLD server does not know the IP address either, but it knows the authoritative nameservers for example.com and returns an NS delegation.

Step 3: Authoritative nameservers — dig queries one of the .com servers (a.gtld-servers.net) which returns the NS records for example.com, pointing to a.iana-servers.net and b.iana-servers.net.

Step 4: The answer — dig queries the authoritative nameserver (a.iana-servers.net) which finally returns the A record: 93.184.216.34.

What to look for in +trace output:

• Broken delegation: If a TLD server points to nameservers that do not respond, the trace will hang or fail at that step. This usually means your domain's NS records at the registrar are pointing to servers that do not exist or are not configured for your zone.
• Lame delegation: The trace completes but the authoritative server returns REFUSED or SERVFAIL instead of an answer. The server is listed as authoritative but is not actually serving the zone.
• Missing glue records: If your nameservers are under the same domain they serve (e.g., ns1.example.com is a nameserver for example.com), the parent zone needs glue records (A/AAAA records for the nameserver). Missing glue causes resolution to fail because there is a circular dependency.

Advanced Options

These flags handle less common scenarios but are invaluable when you need them.

Timeout and Retry Control

# Set query timeout to 10 seconds (default is 5)
dig example.com A +timeout=10

# Set number of retry attempts to 1 (default is 3)
dig example.com A +tries=1

Useful when querying slow or distant nameservers, or when you want faster failure detection in scripts.

EDNS Buffer Size

# Set the EDNS UDP buffer size
dig example.com A +bufsize=4096

EDNS allows DNS responses larger than the traditional 512-byte UDP limit. If you suspect EDNS-related issues (truncated responses, firewall problems with large UDP packets), adjusting the buffer size can help diagnose the problem.

EDNS Client Subnet

# Send a client subnet hint
dig @8.8.8.8 cdn.example.com A +subnet=203.0.113.0/24

EDNS Client Subnet (ECS) tells the resolver to optimize the answer for clients in a particular IP range. CDN providers use this to return the closest edge server. This flag is useful for testing geo-DNS behavior — you can see what IP address a CDN would return for users in a specific region without actually being in that region.

Nameserver Search and Identification

# Query all authoritative servers for SOA and compare
dig example.com +nssearch

# Show which server answered each record (useful with +trace)
dig example.com A +identify

+nssearch is a shortcut for checking zone consistency: it queries every listed nameserver for the SOA record and shows you the serial number from each. If the serial numbers do not match, your zone transfers are not working correctly.

IPv4 and IPv6 Selection

# Force IPv4 transport only
dig -4 example.com A

# Force IPv6 transport only
dig -6 example.com AAAA

Useful when debugging connectivity issues specific to one IP version, or when you need to verify that a nameserver is reachable over both IPv4 and IPv6.

Scripting with dig

dig is designed for automation. Its consistent output format and quiet modes make it well-suited for monitoring scripts, batch operations, and CI/CD pipelines.

Batch Queries with -f

Create a file with one query per line, then process them all at once:

# queryfile.txt
example.com A
example.com MX
mail.example.com A
example.com TXT

dig -f queryfile.txt +noall +answer

This is significantly faster than running individual dig commands in a loop because dig reuses the connection to the resolver.

Parsing Output for Monitoring

Extract just the IP address and use it in a health check:

# Check if a domain resolves to the expected IP
CURRENT_IP=$(dig example.com A +short)
EXPECTED_IP="93.184.216.34"

if [ "$CURRENT_IP" != "$EXPECTED_IP" ]; then
    echo "ALERT: example.com resolving to $CURRENT_IP instead of $EXPECTED_IP"
fi

Monitoring TTL Countdown

# Show the remaining TTL for a cached record
dig example.com A +noall +answer | awk '{print $2}'

Run this repeatedly to watch the TTL count down. When it resets to the original value, the resolver has fetched a fresh copy from the authoritative server.

Looping Over Multiple Nameservers

# Check all public resolvers for consistency
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
    echo -n "$ns: "
    dig @$ns example.com A +short
done

Output:

8.8.8.8: 93.184.216.34
1.1.1.1: 93.184.216.34
9.9.9.9: 93.184.216.34
208.67.222.222: 93.184.216.34

Checking Zone Consistency Across All Nameservers

# Get all NS records, then query each for the SOA serial
for ns in $(dig example.com NS +short); do
    SERIAL=$(dig @$ns example.com SOA +short | awk '{print $3}')
    echo "$ns: serial $SERIAL"
done

If any serial numbers disagree, your secondary nameservers are not receiving zone transfers properly.

Extracting Specific Fields with awk

# Get just the TTL values
dig example.com A +noall +answer | awk '{print $2}'

# Get just the IP addresses from MX lookups
dig example.com MX +short | awk '{print $2}'

# Get record count
dig example.com TXT +noall +answer | wc -l

dig vs nslookup vs host

All three tools query DNS, but they differ significantly in detail, scriptability, and available features. Here is a side-by-side comparison:

My recommendation: Use dig for all serious DNS debugging and automation. It gives you the most information and the most control. Use host for quick one-off checks where you just need a yes/no answer. Use nslookup only when you are on a Windows machine without WSL or dig is not available — it works but gives you less to work with.

Online Alternatives

There are situations where installing dig is not an option: you are on a locked-down workstation, you need to test from a different geographic location, or you want a visual interface instead of a terminal.

My DNS Inspector runs 25+ automated tests on any domain — parent delegation, nameserver health, SOA configuration, MX validation, SPF/DKIM/DMARC authentication, DNSSEC status, and more. It produces a scored health report that covers far more ground than any single dig command.

When you need to verify that a DNS change has propagated globally, the Propagation Checker queries 30+ resolvers around the world and shows you which locations have the new record and which are still serving stale cached data, with TTL countdowns for each.

These tools complement dig rather than replacing it. I use dig for targeted investigation and the online tools for broad verification. For more tools in this category, see my DNS Troubleshooting Tools Guide.

Wrapping Up

dig is the single most valuable tool in a DNS administrator's toolkit. Learning its flags and output format pays dividends every time you need to investigate a DNS issue. Start with the basics — dig domain.com +short for quick answers, dig domain.com +trace for tracing the resolution path — and expand from there as you encounter more complex scenarios.

The key insight is that dig shows you exactly what the DNS protocol is doing, without abstraction. When you read a dig output, you are reading the actual DNS response. That directness is what makes it indispensable for debugging.

For related guides, check out Understanding DNS Record Types for a reference on what each record type does, and the DNS Troubleshooting Tools Guide for other tools that complement dig.