dig Command Tutorial: The Complete DNS Query Guide

dig is the tool network engineers reach for when nslookup isn't enough. It's more verbose, more accurate, and gives you the raw DNS protocol view you need to solve real problems. This tutorial covers the syntax, every important flag, and 12 practical examples.

Table of Contents

• What dig is
• Installing dig on Linux, macOS and Windows
• Basic syntax
• Reading the output — QUESTION, ANSWER, AUTHORITY, ADDITIONAL
• 12 real-world examples
• dig +trace explained
• DNSSEC validation with dig +dnssec
• Troubleshooting with dig
• Common mistakes
• Security best practices
• FAQ

What dig Is

dig (Domain Information Groper) is part of the BIND DNS server package. It's a purpose-built diagnostic tool — every response is displayed as close to the raw DNS packet as human-readable output can get.

Installing dig

Linux

Ubuntu/Debian: sudo apt install dnsutils. Fedora/RHEL: sudo dnf install bind-utils.

macOS

dig ships with the system. Just open Terminal and use it.

Windows

Not built-in. Options: install WSL and Ubuntu (apt install dnsutils), download the BIND tools installer from isc.org, or use nslookup / an online DNS Lookup tool as a fallback.

Basic Syntax

dig [@server] [type] name [+options]. Example: dig @8.8.8.8 MX digimetricshub.com +short.

Reading the Output

Every dig response has four sections:

• QUESTION SECTION — what you asked (name, class, type).
• ANSWER SECTION — the actual records returned.
• AUTHORITY SECTION — which name servers are authoritative.
• ADDITIONAL SECTION — extra records the server included (usually glue A/AAAA for the NS names).

The HEADER at the top shows the opcode, status (NOERROR / NXDOMAIN / SERVFAIL), and flags (qr, aa, rd, ra, ad, cd).

12 Real-World Examples

1. Basic A record

dig digimetricshub.com — default type is A, default class is IN. Returns the IPv4 addresses.

2. Short one-line output

dig +short digimetricshub.com — perfect for scripts. Only the answer values.

3. IPv6 (AAAA)

dig AAAA cloudflare.com +short.

4. Mail exchangers

dig MX gmail.com +short — returns priority and hostname pairs.

5. TXT (SPF, DKIM, DMARC)

dig TXT google.com +short — read SPF here. For DMARC: dig TXT _dmarc.google.com +short.

6. Name servers

dig NS wikipedia.org +short — verify authoritative NS after a registrar change.

7. SOA record

dig SOA digimetricshub.com — see the zone serial to know when it was last updated.

8. Reverse DNS

dig -x 8.8.8.8 +short — the -x flag automatically builds the in-addr.arpa query. Returns dns.google.

9. Query a specific resolver

dig @1.1.1.1 digimetricshub.com — pins the query to Cloudflare. Useful for confirming an issue is your resolver.

10. Query the authoritative NS directly

First: dig NS digimetricshub.com. Then: dig @ns1.example.com digimetricshub.com — bypasses every cache and returns the truth.

11. Trace the delegation chain

dig +trace digimetricshub.com — walks from the root servers down through the TLD servers to the authoritative NS. Great for debugging broken glue records or slow parent zones.

12. DNSSEC check

dig +dnssec cloudflare.com — returns RRSIG records. If the resolver validates, the ad (authenticated data) flag appears in the header.

Troubleshooting with dig

1. Site down for you but not for others? Compare dig @1.1.1.1 vs dig @your.resolver.
2. Records look old? Check the TTL column, then wait or force cache flush.
3. SERVFAIL? Try +cd (checking disabled) to see if DNSSEC validation is failing.
4. TIMEOUT? Try +tcp to bypass UDP fragmentation issues on large answers.
5. Registrar changed NS but nothing updates? dig +trace shows where the delegation breaks.

Common Mistakes

• Using ANY-type queries and expecting all records — modern resolvers refuse per RFC 8482.
• Reading a cached answer as authoritative. Look for aa in flags or query the NS directly.
• Confusing SERVFAIL with NXDOMAIN — SERVFAIL is a server error, NXDOMAIN is a real 'not found'.
• Not using +short in scripts and then parsing verbose output with brittle regex.

Security Best Practices

• Prefer DNS-over-HTTPS or DNS-over-TLS in production; dig +https works with BIND 9.18+.
• Always test DNSSEC with dig +dnssec before enabling in production.
• Never expose recursive resolvers to the public internet — they get abused as DDoS amplifiers.