dig

What it does

dig (Domain Information Groper) sends DNS queries to a resolver or a specific nameserver and displays the full response — the question asked, the answer section with resolved records and TTLs, and (optionally) authority and additional sections showing which servers are authoritative. It's the standard, most detailed command-line DNS diagnostic tool, part of the BIND DNS utilities, and is preferred over nslookup and host for anything beyond a quick lookup because of how much protocol detail it exposes.

Beginner examples

• dig example.com — look up the A record(s) for a domain, full detailed output
• dig example.com +short — same lookup, terse output (just the IP)
• dig example.com MX — look up mail exchanger records
• dig -x 8.8.8.8 — reverse lookup: find the hostname for an IP address

dig example.com +short

Advanced examples

• Query a specific public resolver directly to compare against your local DNS (useful when suspecting DNS cache poisoning or a stale local cache): dig @1.1.1.1 example.com
• Trace the full delegation chain from root servers to authoritative nameserver to debug a broken DNS setup: dig example.com +trace
• Check TXT records for SPF/DKIM/domain verification entries: dig example.com TXT +short
• Get clean, script-friendly output with just the answer section: dig example.com A +noall +answer

dig +trace example.com

Common mistakes

• Forgetting that dig by default queries your system's configured resolver, which may have cached an old/incorrect record — use @server to bypass the cache and check an authoritative or public resolver directly.
• Misreading dig's default verbose output when only the IP is needed — reach for +short instead of grepping through the full response.
• Assuming a missing record type means the domain is misconfigured, without checking whether that record type was ever expected to exist (e.g., expecting an AAAA record for a domain that's IPv4-only).
• Not specifying a record type and being confused why dig example.com MX info doesn't show up in a plain dig example.com (which defaults to the A record only).

Tips

• Use +short constantly for quick lookups and scripting — it strips away the header, question, and metadata noise.
• dig +trace is invaluable when a domain "doesn't resolve" and you need to find exactly which level of the delegation chain (root → TLD → authoritative) is broken.
• Combine dig with @server to directly compare answers from different resolvers when debugging DNS propagation delays after a record change.

Best practices

• After changing DNS records, verify propagation by querying multiple resolvers directly (dig @8.8.8.8, dig @1.1.1.1) rather than relying solely on your local (possibly cached) resolver.
• In scripts and monitoring checks, always use +short and pin down a specific record type to keep output parseable and predictable.
• When documenting DNS troubleshooting steps, prefer dig over nslookup — nslookup is officially deprecated by ISC in favor of dig/host, even though it's still present on many systems.

Real-world use cases

• Verifying a DNS record change (A, CNAME, MX, TXT) has propagated correctly after updating a zone file or DNS provider's dashboard.
• Diagnosing "why won't this domain resolve" issues by tracing the delegation path with +trace to find the broken link in the chain.
• Checking SPF/DKIM/DMARC TXT records when troubleshooting email deliverability issues.

Common interview questions

• What's the difference between dig and nslookup? dig provides more detailed, protocol-accurate output and is the modern standard; nslookup is older, has quirky default behavior, and is considered deprecated by its own maintainers (ISC) in favor of dig/host.
• How would you find the mail servers for a domain? dig example.com MX +short.
• How does dig +trace work, and when would you use it? It walks the DNS delegation chain manually, starting from the root servers, through the TLD servers, down to the domain's authoritative nameservers — useful for pinpointing exactly where a delegation is broken.