The dig Command Explained

In this post, we explain what the dig command does as well as how to install and use it. We also talk about how to work around its limitations. 

TL;DR: What You Need to Know About the dig Command 

dig is a command-line tool for querying DNS servers. 

You give it a domain name, it sends a DNS query, and it shows you the raw response — the IP address, record type, TTL, which server answered, and how long it took. It’s the go-to tool for DNS troubleshooting, but it has some limitations.

Limitations	Workaround
The default output is overwhelming and requires too many flags just to get a clean answer	Switch to the nslookup command for simpler output, or use the specialized DNS Lookup API if you need structured JSON data for automation.
Not preinstalled on Windows by default	Install it or use nslookup or the DNS Lookup API for an OS-agnostic option
Results may reflect cached responses from recursive resolvers	Use the +trace flag to bypass local caches and force dig to follow the live delegation path from the root DNS servers down to the authoritative source, or use the DNS Lookup API to perform fresh queries from global public DNS servers that aren’t tied to your local resolver.
Running many queries in a row can trigger the DNS resolver’s rate limit	Use the DNS Lookup API, which is built for high-volume lookups

Why Is It Called Dig?

It’s not because you literally dig into DNS servers for data: dig which was historically said to stand for “Domain Information Groper,” but its developer’s official documentation dropped that expansion in 2017 and now describes dig simply as a DNS lookup utility.

How the dig Command Works

When you run a dig command, the tool acts as a DNS client and performs the following:

• You type the dig command (dig example.com) in your terminal. If you don’t specify a name server, dig uses the operating system’s default resolver, usually configured in the file resolv.conf. You can also point it at a specific nameserver using the @ symbol (dig @8.8.8.8 example.com).
• dig sends a recursive query to that resolver. It’s asking the resolver to go find the answer on its behalf.
• The resolver checks its cache. If it already has a valid answer, it returns it right away. This happens when someone recently queried the domain using the same resolver, and the result was saved temporarily.
• If the answer isn’t cached, the resolver performs iterative DNS queries on your behalf. It starts by querying a root name server. The root server points it to the top-level domain (TLD) name server (e.g., .com), and the TLD server points it to the authoritative DNS server for the domain.
• The authoritative server returns the DNS record for the domain name, such as an IP address for an A record lookup or the arbitrary text for a TXT record lookup.
• The resolver sends the result back to dig, which formats and displays it in your terminal.

Note that the +trace flag changes this flow. Instead of relying on your resolver to do the recursive work, dig sends just one query to the resolver to get the current root server list and then performs the iterative queries itself — starting from the root servers. This is useful when you want to bypass your configured recursive resolver and see the live delegation path.

How to Install the dig Command?

Before you can use dig, you may need to install it first. The installation process depends on your OS. First, check if it’s already installed by running this command in your terminal:

dig -v 

If dig is there, you’ll see a version number like DiG 9.18.39. If not, follow the steps below for your OS.

The dig Command on Linux

Many Linux distributions come with dig pre-installed as part of the bind9-dnsutils (Debian/Ubuntu) or bind-utils (RHEL/CentOS/Fedora) package. If it’s missing, install it with the package manager for your distro.

For Debian/Ubuntu:

sudo apt install bind9-dnsutils 

For RHEL/CentOS/Fedora:

sudo dnf install bind-utils

Run dig -v afterward to confirm.

The dig Command on Windows

dig isn’t preinstalled on Windows. The easiest approach is to use the Windows Subsystem for Linux (WSL), which gives you a full Linux shell. We described the whole process in this host command explainer, but here are the steps in a nutshell:

• Enable WSL in PowerShell (as admin): 

wsl --install

This will automatically install Ubuntu on your computer from the Microsoft Store.

• Reboot.
• Open Ubuntu and install dnsutils: 

sudo apt-get install bind9-dnsutils

• Confirm with dig -v.

dig Command on a Mac

dig is preinstalled on macOS. Open Terminal and run dig -v to confirm. If you get a version number, you’re good to go. If for some reason it’s missing, install it via Homebrew:

brew install bind

Run dig -v again to confirm. 

If Homebrew itself isn’t installed yet, run the official install script from brew.sh:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

dig Command Syntax, Flags, and Parameters

Basic Syntax 

dig [@server] [type] [domain] [options]

Here’s an example dig command:

dig @8.8.8.8 MX gmail.com +short

This returned the following result:

Flags

Flag	Description	Sample Query
@server	Specifies the name server to query.	dig @8.8.8.8 example.com
-b address	Sets the source IP address of the query.	dig -b 192.168.1.10 example.com
-c class	Sets the query class. The default is IN (Internet), which covers all standard DNS lookups. The only other class you’re likely to use is CH (Chaosnet), which is paired with specific record types to query a name server’s identity or software version.	dig @8.8.8.8 TXT hostname.bind CH
-f filename	Runs in batch mode. It reads queries from a file, one per line.	dig -f domains.txt
-h	Prints a summary of arguments and options.	dig -h
-k keyfile	Specifies a TSIG key file to sign DNS queries.	dig -k auth.key example.com
-m	Enables memory usage debugging.	dig -m example.com
-p port#	Queries a non-standard port instead of the default port 53.	dig -p 5353 example.com
-q name	Sets the query name explicitly.	dig -q example.com
-t type	Sets the query type, such as A, MX, NS, AXFR, or TXT record.	dig -t MX example.com
-u	Prints query times in microseconds instead of milliseconds.	dig -u example.com
-v	Prints the version number and exits.	dig -v
-x addr	Performs a reverse DNS lookup, mapping an IP address back to a hostname using a PTR record.	dig -x 8.8.4.4
-y [hmac:]name:key	Specifies a TSIG key directly on the command line.	dig -y hmac-sha256:user1:pass123 example.com
-4	Forces the tool to use IPv4 only.	dig -4 example.com
-6	Forces the tool to use IPv6 only.	dig -6 example.com

Query Options That Change the Output Format

You can set parameters to control the tool’s output formatting:

Option	Description	Sample Query
+short	Returns a short version of the answer instead of the full verbose output.	dig example.com +short
+nocomments	Hides some comment lines in the output.	dig example.com +nocomments
+noanswer	Hides the answer section of the output.	dig example.com +noanswer
+noauthority	Shows or hides the authority section of the output.	dig example.com +noauthority
+noadditional	Hides the additional section of a reply.	dig example.com +noadditional
+noquestion	Hides the question section.	dig example.com +noquestion
+nostats	Hides query statistics, such as response time and reply size.	dig example.com +nostats
+noall	Used to clear all display flags, then enable a specific section.	dig example.com +noall +answer
+multiline	Prints records in a human-readable multi-line format.	dig example.com +multiline
+nottlid	Hides the TTL value when printing records.	dig example.com +nottlid
+ttlunits / +nottlunits	Displays or hides TTL in human-readable units, like days or hours, and implies +ttlid.	dig example.com +ttlunits

Query Options That Change the Query Behavior

There are also options that change how the tool performs the query:

Option	Description	Sample Query
+trace	Traces the full delegation path from root name servers down to the answer.	dig example.com +trace
+norecurse	Disables recursive queries.	dig example.com +norecurse
+tcp	Forces the tool to use TCP instead of the UDP, which is the default for most queries.	dig example.com +tcp
+search	Uses the search list defined in /etc/resolv.conf.	dig internal-host +search
+nssearch	Finds the authoritative nameservers for a zone and displays its SOA records.	dig example.com +nssearch
+dnssec	Toggles on the request for DNSSEC records (sets the DO bit) to display DNSSEC-related records (RRSIG, DNSKEY).	dig example.com +dnssec
+time=T (or +timeout=T for newer distributions)	Sets the query time in seconds (the default is 5).	dig example.com +timeout=2
+tries=T	Sets the number of times to attempt the query (the default is 3).	dig example.com +tries=5
+retry=T	Sets the number of retries per server, not counting the initial query (the default is 2).	dig example.com +retry=1
+fail	+fail stops the tool from trying the next server when it receives a SERVFAIL. +nofail (the default) keeps trying.	dig example.com +fail

What Does the dig Command Do? (with Examples)

1. Find the Website’s IP Address

This is the most basic use case: dig returns the A record (the IPv4 address) for the domain.

dig example.com

2. Query the MX Record for the Domain

Using the following command, dig returns the mail server(s) responsible for the domain. 

dig MX google.com 

You can add the +short option to get just the mail server.

dig MX google.com +short

3. Request All Available DNS Records

You can use dig to request all record types for a domain using ANY. However, per RFC 8482, many authoritative nameservers now return only a minimal response instead of the full record set to curb DNS amplification abuse. And some public resolvers — such as Cloudflare’s 1.1.1.1 — refuse ANY queries completely.

dig example.com ANY

As a workaround, you can specify a resolver that doesn’t block ANY requests. However, if the domain’s authoritative name server restricts this type of query, then you would have to query each record type individually instead.

dig @8.8.8.8 example.com ANY

4. Trace the DNS Path

You can enable dig to query root servers and follow the delegation chain all the way to the authoritative name server instead of using your configured resolver. The trace option is useful for diagnosing propagation issues or confirming which server is authoritative.

dig example.com +trace

5. Find the Name Servers Responsible for a Domain

To get a domain name’s name servers, use this command:

dig NS example.com 

Use the +short option to hide all the other details in the response.

dig NS example.com +short

6. Find Name Servers Responsible for a TLD

dig also lets you obtain the name servers for a specific top-level domain (TLD).

dig NS com +short

Without the +short parameter, you’d see other details.

7. Check the TTL Value for the A Record

To see just the TTL value of a domain’s A record, you need to include the +noall and +answer parameters. This suppresses everything except the answer section. The command looks like this:

dig example.com +noall +answer

However, if you’re running this on WSL, you might encounter a common issue in some WSL configurations where it zeroes out TTL values in DNS responses. To get real TTL values, you have to query an external DNS server directly.

dig @8.8.8.8 example.com +noall +answer

8. Check if a Zone Exists on a Name Server

If the name server doesn’t have the zone, it returns a not found error message.

dig SOA example.com @ns1.example.com 

dig SOA example.com @elliott.ns.cloudflare.com

9. Perform a Reverse DNS Lookup

Use dig to perform a reverse DNS lookup by mapping an IP address to a hostname through a PTR record.

dig -x 74.6.231.20

10. Query a Batch of Domain Names 

dig can read domain names from a file and run queries on each one. This is useful for checking a list of domains, but keep in mind that running a large number of queries from one machine can trigger rate limiting on DNS servers.

dig -f domains.txt +short

If you want to see the full response for each domain, remove the +short parameter.

When to Use the dig Command and When to Use Other Tools

Use dig when you want to:

• Run low-level DNS diagnostics: dig gives you the full DNS response, including the record type, TTL, which server answered, and how long it took. It’s the right tool when you need to see exactly what’s happening at the DNS level.
• Inspect the resolution path with +trace: This option lets you follow a domain’s delegation from root DNS servers to the authoritative name server, which is useful for diagnosing propagation issues or confirming where a domain is resolving from.
• Check whether an answer comes from a cache or an authoritative server: TTL values can indicate how long a resolver will keep a cached response before refreshing it. Lower TTL values usually mean the record has been cached for some time already.

You want to avoid using dig and use another tool when you need:

• Quick lookups: If you just need a fast answer — like an IP address or a TXT record — tools like host or nslookup are simpler and return a clean result with no extra flags needed.
• Large-scale automation: As you see in the examples above, dig outputs unstructured text, which is hard to parse in scripts. On top of that, running many queries in succession from a single machine can hit DNS servers’ rate limits. A DNS Lookup API is a better fit for automation as it returns structured JSON and is built for high-volume use. 
• Monitoring: dig can be scripted to run on a schedule, but it has no built-in alerting, dashboards, or historical tracking. If you need to monitor DNS health over time and get notified when something changes, a dedicated monitoring tool is a better fit.

FAQs

What is the difference between dig and nslookup?

Both tools query the DNS, but they work differently. 

nslookup is simpler and is available on Windows by default, so it’s a common choice for quick DNS lookups. 

dig gives more detail in the output — including the full DNS response, TTL, and query statistics. You can also customize how dig sends a DNS query and what it returns in a way that nslookup doesn’t, particularly using flags like +trace, +noall +answer, and +multiline.

Does dig use TCP or UDP?

By default, dig uses UDP on port 53, though it automatically switches to TCP for ANY and IXFR queries, and always uses TCP for AXFR (zone transfer) queries. UDP is faster and sufficient for most DNS queries. But you can force the tool to use TCP with the +tcp flag.