What Is the Dig Command? DNS Troubleshooting and Lookup Explained

The dig command is a flexible command-line tool for querying Domain Name System (DNS) name servers directly. Part of the BIND software suite maintained by the Internet Systems Consortium (ISC), it constructs DNS query packets, sends them to specified servers, and prints the raw response with minimal interpretation.

Unlike everyday web browsing, which relies on the operating system's hidden resolver libraries, dig exposes the full DNS message. Network engineers and system administrators use it to troubleshoot delegation problems, verify DNSSEC signatures, and inspect exactly what a name server returns. If you're unfamiliar with how DNS resolves names behind the scenes, our guide to how DNS works covers the fundamentals.

What Does Dig Stand For?

dig stands for Domain Information Groper. It's one of the core utilities distributed with BIND (Berkeley Internet Name Domain), the reference implementation of DNS server and client software. While BIND runs many of the world's authoritative name servers, dig serves as its companion diagnostic client.

The tool has become the de facto standard for DNS debugging. ISC recommends it over older alternatives because it speaks the DNS protocol directly rather than routing requests through local resolver libraries that might cache results or append search domains silently. When you need the unvarnished truth from a name server, dig is the tool that delivers it.

How Does the Dig Command Work?

When you run a dig query, the tool assembles a DNS request packet and transmits it over UDP by default. If the response is too large to fit in a single UDP datagram, the server sets the truncation (TC) flag in the header. dig sees this flag and automatically retries the query over TCP, which can handle larger streams. You can target a specific name server with the @server syntax, or let it query the resolvers listed in /etc/resolv.conf.

The output is divided into four standard sections that mirror the DNS protocol itself. The Question section restates what you asked, including the domain name, class, and record type. The Answer section contains the actual resource records. Authority lists the name servers responsible for the zone, which is critical when you're tracing delegation paths. Additional provides supporting data such as glue records, which are A or AAAA records for name servers listed in the Authority section. Below these sections, a statistics block shows query time, server IP, message size, and the transport protocol used.

By design, dig bypasses most operating system resolver behaviors. It won't automatically use split-horizon DNS configurations, VPN resolvers, or local search domains unless you explicitly configure it to do so. This directness is exactly why it's trusted for authoritative troubleshooting. What you see is what the queried server sent, not a filtered view from a local cache or forwarding resolver.

Advanced options extend this behavior further. You can request DNSSEC data with +dnssec, set custom buffer sizes with +bufsize, or disable recursive queries with +norecurse to test authoritative servers directly. These flags make dig as much a protocol analyzer as a lookup tool.

Dig vs. Nslookup and Host

Administrators sometimes wonder why dig, nslookup, and host can return different results for the same domain. The answer lies in how each tool reaches the name server. nslookup often relies on system resolver libraries, which means it may follow OS-specific rules, caching layers, or search domain appending that dig ignores. These resolver differences can cause confusion during production debugging, especially when you're trying to verify whether a DNS change has actually reached the internet.

On Windows, nslookup is particularly common because it's included by default. However, its interactive mode and dependence on the Windows resolver can mask problems that dig would expose immediately. When a Windows admin and a Linux admin compare notes and see different answers, the culprit is usually this resolver gap rather than an actual DNS error.

The host utility offers concise, human-readable output focused mainly on the answer section. For a quick IP lookup, it's perfectly adequate. But when you need to see TTL values, authority chains, EDNS options, or truncation behavior, dig is the only common tool that reveals the complete message. It shows you not just the answer, but how that answer was delivered.

Another key distinction is consistency. dig output follows a predictable format that's easy to parse with scripts, awk, and log analyzers. nslookup is interactive by default and its output format varies across platforms, making it less suitable for automation. If you're building monitoring checks or migration validation scripts, dig is the safer choice.

Common Dig Command Examples

Basic usage is straightforward. To query the A record for a domain:

dig example.com

The default output includes the question, answer, authority, and additional sections, plus a footer with timing data. For a cleaner view of just the IP addresses, add +short:

dig example.com +short

To query a specific record type, such as MX or TXT, append it to the command:

dig example.com MX
dig example.com TXT

The +trace option follows the full delegation chain from the root servers down to the authoritative name server. This is invaluable when you're debugging why a DNS change hasn't propagated or when you're verifying that your new authoritative servers are reachable:

dig example.com +trace

To query a specific resolver rather than your system's defaults, use the at-sign:

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com MX

Here's what a typical A record query looks like in full:

$ dig example.com

; <<>> DiG 9.18.24 <<>> 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: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jul 25 12:00:00 UTC 2026
;; MSG SIZE  rcvd: 56

Notice the EDNS line showing a UDP buffer size of 1232 bytes. That's the modern default, and it affects whether large responses arrive over UDP or trigger a TCP fallback. The flags line tells you whether the response was authoritative (aa), recursive (ra), or truncated (tc).

Modern Dig Features and Version Differences

BIND 9.18 and later changed the default EDNS UDP buffer size from 4096 bytes to 1232 bytes. This aligns with DNS Flag Day recommendations to avoid IP fragmentation on modern networks. The practical effect is that dig now receives truncated responses more often, causing it to retry over TCP. ISC's documentation on version behavior notes that you can override this with +bufsize=4096 when testing legacy systems that expect larger UDP payloads.

Newer versions also expose more detail in the statistics section. When TCP fallback occurs, the output explicitly states which transport protocol was used. The +qr flag prints the outgoing query packet, making it easier to verify that your buffer-size settings are being advertised correctly. These small details matter enormously when you're debugging intermittent resolution failures across different network paths.

DNSSEC validation options, cookie support, and advanced query flags remain core strengths. You can request signatures with +dnssec, chase trust chains, or inspect the DO bit in responses. For operators managing signed zones, these capabilities aren't optional extras. They're essential for confirming that validating resolvers will accept your data.

These changes matter for firewall rules, too. Because TCP fallback is now more common with default settings, ensuring that outbound DNS over TCP isn't blocked has become essential for reliable lookups.

A firewall that allows UDP port 53 but blocks TCP port 53 will cause mysterious failures that only dig's truncation and retry behavior reveals clearly.

When to Use Dig

Reach for dig whenever you need to know exactly what a name server thinks about a domain. It's the right tool for verifying DNSSEC delegations, checking TTL values before a migration, or scripting health checks that must not be skewed by local caching resolvers. If you're tracing network issues beyond DNS, tools like Traceroute and MTR can help you analyze the path itself.

Before cutting over to new name servers, use dig @newserver example.com to confirm the zone is answering correctly. Check the TTL in the answer section to estimate how long old records will live in remote caches. If you're lowering a TTL in preparation for a change, dig confirms the new value is actually being served by the authoritative system.

For casual browsing or quick checks, host or dig +short will do. Reserve the full dig output for situations where authority sections, response flags, or raw protocol details reveal the truth. The difference between thinking DNS works and knowing DNS works often comes down to reading the full message.

Understanding dig means understanding DNS itself.

The command doesn't simplify the protocol. It shows it to you exactly as it travels across the wire, flags, sections, and all.

Frequently asked questions

What is the dig command?

Dig (Domain Information Groper) is a command-line DNS lookup tool that queries name servers directly and displays the raw response. It is part of the BIND software suite and is the standard tool for DNS troubleshooting.

How do I use dig to look up DNS records?

Run dig example.com for the default A record lookup. Add a record type like dig example.com MX for mail servers or dig example.com TXT for text records. Use dig @1.1.1.1 example.com to query a specific resolver.

What is the difference between dig and nslookup?

Dig queries DNS servers directly and shows the full protocol response including authority sections, flags, and EDNS options. Nslookup relies on system resolver libraries, which may cache results or apply search domains, making it less reliable for authoritative debugging.

What is dig +trace?

The +trace option follows the full delegation chain from root servers down to the authoritative name server for the domain. It is useful for verifying DNSSEC signatures and diagnosing propagation delays.

What does dig +short do?

+short condenses output to just the IP addresses or record values, omitting the question, authority, and statistics sections. It is the quickest way to get a clean answer for scripting or casual lookups.

Does dig use TCP or UDP?

Dig sends queries over UDP by default. If the response is too large, the server sets the truncation flag and dig retries over TCP. Modern dig versions use a smaller EDNS buffer size (1232 bytes), which may trigger TCP fallback more often than older versions.