dig Command: DNS Lookups from the Command Line

dig (Domain Information Groper) is the standard command-line tool for querying DNS servers. It ships with BIND and is available on macOS, Linux, and Windows (via WSL or third-party installs). When you need to check DNS records, troubleshoot resolution problems, or verify that a DNS change has propagated, dig gives you the raw data without any filtering or interpretation.

dig is more powerful and more verbose than nslookup. Where nslookup gives you a quick answer, dig gives you the full picture: the question, the answer, the authority section, the additional section, query time, and the server that responded. For a broader introduction to DNS concepts, see the DNS Guide.

Basic Syntax

The simplest dig command takes a domain name and returns its A records.

dig example.com

The output has several sections:

; <<>> DiG 9.18.18 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; 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: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon May 26 10:00:00 UTC 2026
;; MSG SIZE  rcvd: 56

Here is what each section tells you:

HEADER: The response status. NOERROR means the query succeeded. NXDOMAIN means the domain does not exist. SERVFAIL means the DNS server encountered an error.

QUESTION SECTION: What you asked for. This confirms the domain and record type in your query.

ANSWER SECTION: The actual DNS records. Each line shows the domain, TTL (in seconds), class (IN for Internet), record type, and the record value. In this example, example.com has an A record pointing to 93.184.216.34 with a TTL of 86400 seconds (24 hours).

Query time: How long the DNS server took to respond. Useful for diagnosing slow resolution.

SERVER: Which DNS server answered the query.

Querying Specific Record Types

By default, dig queries for A records. To query a different record type, add it after the domain name.

dig example.com AAAA       # IPv6 address
dig example.com MX         # Mail servers
dig example.com NS         # Nameservers
dig example.com TXT        # Text records (SPF, DKIM, etc.)
dig example.com CNAME      # Canonical name
dig example.com SOA        # Start of Authority
dig example.com ANY        # All available records (unreliable)

A few notes on record types:

MX records include a priority value. Lower numbers mean higher priority. The mail server with the lowest priority is tried first.

dig example.com MX

;; ANSWER SECTION:
example.com.    3600    IN    MX    10 mail1.example.com.
example.com.    3600    IN    MX    20 mail2.example.com.

TXT records are used for email authentication (SPF, DKIM, DMARC), domain verification, and other purposes. A domain can have multiple TXT records. For more on checking these, see How to Check DNS Records.

ANY queries are increasingly unreliable. Many DNS servers refuse ANY queries or return incomplete results because they have been abused for DNS amplification attacks. Query specific record types instead.

The +short Flag

When you just want the answer without all the extra sections, use +short.

dig example.com +short

93.184.216.34

This is useful in scripts or when you just need a quick answer. It strips everything except the record values from the output.

You can combine +short with specific record types:

dig example.com MX +short

10 mail1.example.com.
20 mail2.example.com.

dig example.com NS +short

ns1.example.com.
ns2.example.com.

Specifying a Nameserver

By default, dig uses the DNS server configured on your system (typically your ISP's resolver or a public resolver like 8.8.8.8). To query a specific nameserver, prefix the server address with @.

dig @8.8.8.8 example.com          # Query Google Public DNS
dig @1.1.1.1 example.com          # Query Cloudflare DNS
dig @9.9.9.9 example.com          # Query Quad9
dig @ns1.example.com example.com  # Query the authoritative nameserver directly

Querying different nameservers is essential for DNS troubleshooting. If a record resolves correctly on Google DNS but not on your ISP's resolver, the issue is likely caching or propagation delay on your ISP's side. For a guide to checking propagation, see Check DNS Propagation.

Querying the authoritative nameserver directly shows you the current records without any caching layer. This is the fastest way to confirm that a DNS change has been published.

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

# Then query one directly
dig @ns1.example.com example.com

The +trace Flag

+trace is one of dig's most powerful features. It simulates the full DNS resolution process from root servers down to the authoritative nameserver, showing every step.

dig example.com +trace

.                       518400  IN  NS  a.root-servers.net.
.                       518400  IN  NS  b.root-servers.net.
;; Received 262 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms

com.                    172800  IN  NS  a.gtld-servers.net.
com.                    172800  IN  NS  b.gtld-servers.net.
;; Received 828 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms

example.com.            172800  IN  NS  ns1.example.com.
example.com.            172800  IN  NS  ns2.example.com.
;; Received 264 bytes from 192.5.6.30#53(a.gtld-servers.net) in 31 ms

example.com.            86400   IN  A   93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(ns1.example.com) in 18 ms

The trace shows the resolution path:

1. Your configured resolver directs dig to the root servers
2. A root server directs to the .com TLD servers
3. A .com TLD server directs to the authoritative nameservers for example.com
4. The authoritative nameserver returns the actual A record

This is invaluable for diagnosing where in the chain a lookup is failing. If the trace stops at a TLD server, the domain's NS records may be misconfigured. If the authoritative server returns unexpected data, the zone file has the wrong records. For more on how this chain works, see DNS Resolution: How It Works.

Reverse DNS Lookups

To look up the domain name associated with an IP address, use the -x flag.

dig -x 93.184.216.34

;; ANSWER SECTION:
34.216.184.93.in-addr.arpa. 86400 IN PTR example.com.

Reverse lookups query PTR records in the in-addr.arpa zone. They are used for email server verification, security logging, and network diagnostics. Not all IP addresses have reverse DNS configured. If there is no PTR record, the query returns NXDOMAIN.

Batch Queries

dig can process multiple queries from a file using the -f flag.

# Create a file with one query per line
cat domains.txt
example.com A
example.org MX
example.net NS

dig -f domains.txt

Each line in the file follows the same syntax as a regular dig command (domain, then optional record type). dig processes them sequentially and outputs all results. Add +short to get compact output for all queries:

dig -f domains.txt +short

This is useful for auditing DNS records across multiple domains or verifying a batch of DNS changes.

Useful dig Options

Beyond the common flags, dig has several options worth knowing.

dig example.com +noall +answer    # Show only the answer section
dig example.com +norecurse        # Send a non-recursive query
dig example.com +tcp              # Force TCP instead of UDP
dig example.com +dnssec           # Request DNSSEC records
dig example.com +nocmd +noall +answer +ttlid  # Minimal output with TTL

+noall +answer strips everything except the answer records. This is more targeted than +short because it still shows the full record format (domain, TTL, class, type, value) without the header, question, and authority sections.

+norecurse sends a query without the recursion desired flag. This is useful when querying a server that should not perform recursion, like testing whether an authoritative server is configured correctly.

+tcp forces the query over TCP instead of the default UDP. DNS responses larger than 512 bytes (or 1232 bytes with EDNS) may be truncated over UDP, so TCP ensures you get the full response. This matters for domains with many records.

+dnssec requests DNSSEC signatures along with the DNS records. Use this to verify that DNSSEC is configured and working for a domain.

dig vs nslookup

Both tools query DNS servers, but they differ in philosophy and capability. For a full guide to nslookup, see the nslookup Command Guide.

Use dig when you need detailed output, trace resolution, batch queries, or DNSSEC verification. dig is the preferred tool for DNS administrators and anyone who needs the full picture.

Use nslookup when you need a quick answer on a Windows machine where dig is not installed, or when working with someone who is more familiar with its simpler output format.

Common Troubleshooting Scenarios

Verifying a DNS Change

You just updated a DNS record and want to see if the change has taken effect.

# Check the authoritative server (bypasses caching)
dig @ns1.yourdomain.com yourdomain.com A +short

# Check a public resolver (shows cached/propagated value)
dig @8.8.8.8 yourdomain.com A +short

# Check another resolver for comparison
dig @1.1.1.1 yourdomain.com A +short

If the authoritative server shows the new value but public resolvers show the old value, the change has been published but has not propagated yet. Wait for the TTL to expire. See the DNS Troubleshooting Guide for more scenarios.

Finding Why Email Is Not Delivered

# Check MX records
dig yourdomain.com MX +short

# Check SPF record
dig yourdomain.com TXT +short | grep spf

# Check DMARC record
dig _dmarc.yourdomain.com TXT +short

Diagnosing Slow Resolution

# Check query time to your default resolver
dig yourdomain.com | grep "Query time"

# Compare with a public resolver
dig @8.8.8.8 yourdomain.com | grep "Query time"

# Trace to find the slow hop
dig yourdomain.com +trace

If the query time to your default resolver is significantly slower than to a public resolver, consider switching your DNS resolver. If the trace shows a slow response from one specific server in the chain, that server is the bottleneck.

Summary

dig is the most capable DNS query tool available from the command line. The basic dig domain.com command handles most lookups. Add a record type for specific queries. Use +short for scripts. Use @server to target specific nameservers. Use +trace to walk the full resolution chain. Use -f for batch processing.

The output is verbose by default, but that verbosity is its strength. When something is wrong with DNS, the answer, authority, and additional sections together tell you exactly what is happening and where the problem lives.

References

• ISC, "BIND 9 Administrator Reference Manual - dig," https://bind9.readthedocs.io/en/latest/manpages.html#dig-dns-lookup-utility
• IANA, "Root Servers," https://www.iana.org/domains/root/servers