How to Use the dig Command for DNS Lookups?

When a DNS problem needs real answers rather than guesses, dig is the tool most engineers reach for. Short for "domain information groper," it ships with BIND and shows you nearly everything a DNS server sends back: the response code, the flags, every section of the reply, TTLs, and how long the query took. That level of detail is exactly what you need to tell a caching issue from a broken delegation or a missing record.

This guide covers dig from first query to advanced use: installing it, reading its output line by line, querying specific record types and servers, trimming the output for scripts, tracing a lookup from the root, checking DNSSEC, forcing TCP, querying over DoH and DoT, and running batch lookups. If you just need a quick check on a machine without dig, the nslookup guide covers the tool that's available everywhere.

Installing dig

dig is preinstalled on macOS and on many Linux distributions. If it's missing:

# Debian / Ubuntu
sudo apt install dnsutils

# Fedora / RHEL / Rocky / AlmaLinux
sudo dnf install bind-utils

# Arch Linux
sudo pacman -S bind

# Alpine
sudo apk add bind-tools

# macOS with Homebrew (for a newer version than the system copy)
brew install bind

On Windows, the easiest options are running dig inside WSL or installing the BIND tools for Windows. Check your version with dig -v; features like +https and +tls need BIND 9.18 or newer.

Your First Query

dig example.com

With no record type specified, dig asks for an A record. The output looks like this:

; <<>> DiG 9.18.30 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41503
;; flags: qr rd ra ad; 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.            3021    IN      A       203.0.113.10

;; Query time: 14 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu Oct 01 09:12:44 UTC 2026
;; MSG SIZE  rcvd: 56

Reading dig Output

The header

status: NOERROR is the response code. The ones you'll see most are NOERROR (success, though the answer may still be empty), NXDOMAIN (the name doesn't exist), SERVFAIL (the resolver couldn't get a valid answer), and REFUSED (the server won't answer). These are explained fully in what NXDOMAIN, SERVFAIL, and REFUSED mean.

The flags

Flag	Meaning
qr	This is a response (query/response bit)
rd	Recursion desired, set by dig in the query
ra	Recursion available, the server offers recursion
aa	Authoritative answer, the server is authoritative for this zone
ad	Authenticated data, the resolver validated the answer with DNSSEC
tc	Truncated, the answer didn't fit in UDP; retry over TCP
cd	Checking disabled, DNSSEC validation was turned off for this query

The aa flag is the quickest way to know whether you're seeing the source of truth or a cached copy.

The counts and sections

QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 tells you how many records are in each section:

• OPT pseudosection describes EDNS parameters, such as the advertised UDP buffer size.
• QUESTION echoes what you asked.
• ANSWER holds the records that answer the question.
• AUTHORITY holds NS records in a referral, or the SOA record when the answer is negative.
• ADDITIONAL holds helpful extras, such as glue addresses for nameservers.

The answer line

example.com.            3021    IN      A       203.0.113.10

From left to right: the name, the TTL in seconds, the class (IN for internet), the type, and the data. When you query a recursive resolver, the TTL is the time remaining in its cache, so it counts down between queries. Querying an authoritative server shows the full configured TTL. See what a TTL is in DNS for why that matters during changes.

The footer

Query time shows latency, and SERVER shows which server answered and over which transport. A query time of 0 msec usually means the answer came from a cache very close to you.

Querying Specific Record Types

Put the type after the name:

dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS
dig example.com SOA
dig example.com CAA
dig _dmarc.example.com TXT
dig _sip._tcp.example.com SRV

Each command asks for one record type. dig accepts the type before or after the name, and -t makes it explicit: dig -t MX example.com.

Avoid relying on ANY. Many servers return a minimal response to ANY queries, so you won't get the full set of records.

Choosing the Server with @

By default dig uses the resolvers in /etc/resolv.conf. Use @ to query a specific server:

# Public resolvers
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
dig @9.9.9.9 example.com

# An authoritative nameserver for the domain
dig @ns1.example-dns.net example.com +norecurse

Comparing answers across resolvers is the fastest way to spot caching differences after a change. Querying an authoritative nameserver with +norecurse shows what is actually published right now; if the response carries the aa flag, you're looking at the source.

Here's a one-liner that queries every authoritative nameserver for a domain and prints its SOA serial, which tells you whether they're all in sync:

for ns in $(dig example.com NS +short); do
  printf '%-30s %s\n' "$ns" "$(dig @"$ns" example.com SOA +short | awk '{print $3}')"
done

If one server shows an older serial, it hasn't picked up the latest zone version yet.

Controlling the Output

The full output is great for diagnosis but noisy for quick checks and scripts.

# Just the data
dig example.com +short

# Only the answer section, with names, TTLs, and types
dig example.com +noall +answer

# Answer plus authority, useful for negative answers
dig nonexistent.example.com +noall +answer +authority

# Readable, multi-line output for SOA, DNSKEY, and similar records
dig example.com SOA +multiline

+short prints only the record data, one per line. +noall turns off every section, and then +answer (or +authority, +additional, +comments, +stats) turns back on just the ones you want. The +noall +answer combination is the best default for everyday use because it keeps TTLs visible.

You can save preferred defaults in ~/.digrc. For example, a file containing +noall +answer makes that the default output style for every dig run.

Tracing a Lookup from the Root

dig example.com +trace

+trace makes dig act like a resolver itself. It starts at the root servers, follows the referral to the .com TLD servers, follows the next referral to the domain's nameservers, and prints each step. This bypasses your resolver's cache completely.

Use it when:

• A domain resolves for some people and not others.
• You just changed nameservers and want to see what the TLD is delegating to.
• You suspect a lame delegation, where the TLD points to nameservers that don't answer for the zone.

The trace shows exactly which hop fails. For the bigger picture of what each hop is doing, see how DNS works.

Reverse Lookups

dig -x 203.0.113.10 +short

-x builds the in-addr.arpa (or ip6.arpa) name for you and asks for the PTR record. For bulk reverse lookups and interpreting the results, see how to perform a reverse DNS lookup.

Checking DNSSEC

# Ask for DNSSEC records along with the answer
dig example.com A +dnssec

# Look at the zone's keys and the DS record in the parent
dig example.com DNSKEY +multiline
dig example.com DS

With +dnssec, the answer section includes RRSIG signatures, and if your resolver validates, the header shows the ad flag. If a domain returns SERVFAIL and you suspect a DNSSEC problem, compare with checking disabled:

dig example.com +cd

If +cd returns an answer while the normal query returns SERVFAIL, the zone's DNSSEC chain is broken. For setup and troubleshooting, see what DNSSEC is. BIND also ships delv, which performs full validation and explains what failed: delv example.com A.

Transport Options: TCP, DoT, and DoH

# Force TCP instead of UDP
dig example.com +tcp

# DNS over TLS (port 853)
dig @1.1.1.1 example.com +tls

# DNS over HTTPS
dig @cloudflare-dns.com example.com +https

+tcp is useful when testing large responses or firewalls that block TCP on port 53. +tls and +https (BIND 9.18 and newer) let you confirm that an encrypted resolver works and returns the same answers as plain DNS.

Other Useful Options

Option	What it does
-4 / -6	Use only IPv4 or IPv6 transport
-p 5353	Query a non-standard port
+norecurse	Don't ask for recursion; essential for authoritative checks
+timeout=2	Wait 2 seconds per try
+tries=1	Only try once
+nsid	Ask the server to identify which instance answered (useful with anycast)
+nssearch	Query every authoritative server and show its SOA
+subnet=203.0.113.0/24	Send an EDNS Client Subnet hint to test geo-based answers
+bufsize=1232	Set the advertised EDNS UDP buffer size

The +nsid option is particularly handy with anycast services: many large resolvers and authoritative providers return an identifier showing which site or server handled the query.

Batch Queries

dig can read queries from a file with -f. Each line holds the arguments for one query:

example.com A +short
example.com MX +short
www.example.com CNAME +short
-x 203.0.113.10 +short

dig -f queries.txt

dig runs each line in order. For larger jobs, combine dig with xargs to run queries in parallel:

cat domains.txt | xargs -P 8 -I{} sh -c 'printf "%s %s\n" "{}" "$(dig +short {} A | head -n 1)"'

This resolves every domain in domains.txt, eight at a time, and prints each domain next to its first A record. Keep the parallelism modest to avoid hammering a single resolver.

A Practical Troubleshooting Sequence

When a site isn't resolving correctly, this order isolates the problem quickly:

# 1. What does my resolver say?
dig www.example.com +noall +answer +comments

# 2. What does a public resolver say?
dig @1.1.1.1 www.example.com +noall +answer

# 3. Who is authoritative?
dig example.com NS +short

# 4. What does the authoritative server say?
dig @ns1.example-dns.net www.example.com +norecurse +noall +answer

# 5. Is delegation correct from the root down?
dig www.example.com +trace

If steps 1 and 2 differ, it's caching. If step 4 is wrong, the record itself is wrong at your DNS host. If step 5 shows unexpected nameservers, the delegation at the registrar is wrong. For a broader checklist, see how to troubleshoot DNS issues.

---

dig Command FAQ

Conclusion

dig rewards a few minutes of learning with far better visibility than any other everyday DNS tool. Once you can read the header status, the aa and ad flags, the sections, and the TTLs, most DNS problems become obvious. A small set of options covers the vast majority of real work: @server to pick who answers, +short and +noall +answer to cut the noise, +norecurse for authoritative checks, +trace to follow delegation, and +dnssec or +cd for signing problems.

Make the five-step sequence above a habit, comparing your resolver, a public resolver, and the authoritative nameserver, and you'll be able to say exactly which layer is wrong instead of waiting and hoping it fixes itself.

For full documentation of every option, see these references:

1. BIND 9 Documentation: BIND 9 Administrator Reference Manual — includes the official dig and delv manual pages.
2. ISC: BIND 9 — the project that develops and distributes dig.
3. RFC 1035: Domain Names - Implementation and Specification — defines the message format, header flags, and sections that dig displays.
4. RFC 6891: Extension Mechanisms for DNS (EDNS(0)) — explains the OPT pseudosection in dig output.
5. RFC 5001: DNS Name Server Identifier (NSID) Option — the standard behind +nsid.