dig network

The dig man page is 400 lines long. You need about four query types and you’ll never paste a domain into a web-based DNS tool again.

You needed to check DNS records. So you opened a browser. You went to mxtoolbox.com. Or dnschecker.org. Or who.is. Or one of the seventeen other sites that do the same thing. You typed the domain. You clicked “DNS Lookup.” You waited for the page to load. It showed you results surrounded by ads for SSL certificates and domain registrars. You scrolled past a banner telling you about “free monitoring.” You found the A record. You closed the tab.

Then you needed to check another record type. So you went back. Different dropdown. Different page load. More ads. More banners.

dig does all of this from your terminal. Instantly. With no ads. And it queries the DNS servers directly instead of showing you cached results from some random web service’s perspective.

Unless you’re running Windows then wtf none of this applies to you. But hey, come to the dark side, go install WSL2 and you can follow along. We’ll wait. Impatiently.

If you’re lazy like me (all sysadmins are!) then click here for the dig cheat sheet.

Basic lookup (A record)

dig example.com

Returns the A record — the IPv4 address the domain points to. The output is verbose by default. The answer is in the ANSWER SECTION:

;; ANSWER SECTION:
example.com.        3600    IN    A    93.184.216.34

That’s the domain, the TTL (time-to-live in seconds), the record class, the type, and the IP address.

Short answer only

dig +short example.com

93.184.216.34

Just the IP. No headers, no authority section, no additional section, no statistics. For when you just need the answer and nothing else.

Query specific record types

MX records (mail servers)

dig MX example.com

Shows which mail servers handle email for the domain, with priority numbers. Lower priority = preferred server. For debugging “why aren’t emails being delivered.”

dig +short MX example.com

10 mail.example.com.
20 mail2.example.com.

NS records (nameservers)

dig NS example.com

Which nameservers are authoritative for this domain. The first thing to check when DNS isn’t working — are the nameservers correct?

TXT records (SPF, DKIM, verification)

dig TXT example.com

TXT records hold all kinds of things — SPF records for email authentication, domain verification strings for Google/Microsoft/Cloudflare, DKIM keys. If you’re debugging email deliverability, this is where you look.

CNAME records (aliases)

dig CNAME www.example.com

Shows if a subdomain is an alias pointing to another hostname. Common for CDN setups and SaaS platforms.

AAAA records (IPv6)

dig AAAA example.com

The IPv6 equivalent of an A record. For when you need to know if a domain has IPv6 support.

ANY (everything at once)

dig ANY example.com

Asks for all record types. Some DNS servers refuse ANY queries for security reasons, but when it works, you get everything in one shot.

Query a specific DNS server

dig @8.8.8.8 example.com

Queries Google’s public DNS instead of your local resolver. Essential for debugging — “does this resolve on Google’s DNS but not on mine?”

dig @1.1.1.1 example.com

Cloudflare’s DNS. Compare results across different resolvers to check for propagation issues.

dig @ns1.example.com example.com

Query the authoritative nameserver directly. The most definitive answer — what the domain’s own DNS server says, before any caching.

Check DNS propagation

dig +short example.com @8.8.8.8
dig +short example.com @1.1.1.1
dig +short example.com @9.9.9.9
dig +short example.com @208.67.222.222

Query Google, Cloudflare, Quad9, and OpenDNS. If they all agree, propagation is complete. If they disagree, changes are still rolling out. This is what dnschecker.org does — but from your terminal, without the ads.

Trace the full resolution path

dig +trace example.com

Shows every step of DNS resolution — from the root servers, to the TLD servers, to the authoritative nameservers. This is how DNS actually works: a chain of referrals. When something is broken, the trace shows you exactly where the chain breaks.

Reverse DNS lookup

dig -x 93.184.216.34

Given an IP address, what domain points to it? Reverse DNS. Essential for email deliverability (mail servers check that your sending IP has valid reverse DNS) and for identifying mystery IPs in your logs.

Check TTL (caching time)

dig example.com | grep -A1 "ANSWER SECTION"

;; ANSWER SECTION:
example.com.        3600    IN    A    93.184.216.34

That 3600 is the TTL in seconds — this record is cached for one hour. If you just changed a DNS record and it’s not updating, check the TTL. A TTL of 86400 means caches hold the old value for up to 24 hours.

Before making DNS changes, lower the TTL first. Wait for the old TTL to expire. Then make the change. Then raise the TTL back. This is DNS change management, and it’s saved more outages than any monitoring tool.

The flags that actually matter

“But mxtoolbox—”

Close the browser tab.

“MXToolbox shows me everything.” MXToolbox shows you DNS records from their servers, with their caching, at their refresh rate, surrounded by their ads. dig @8.8.8.8 queries the actual DNS infrastructure directly. You’re getting the real answer, not someone else’s cached copy of the answer. That said — credit where it’s due. MXToolbox is a genuinely great tool and we’ve used it countless times over the years. Their blacklist checker alone has saved more Monday mornings than coffee. But for actual DNS debugging? dig is the source of truth.

“I use nslookup.” nslookup works. It’s also been considered deprecated in favor of dig for over a decade. The output format is inconsistent, it doesn’t support all query types cleanly, and the interactive mode is confusing. dig’s output is standardized, scriptable, and complete. Every DNS tutorial written after 2005 uses dig for a reason.

“dnschecker.org shows propagation across regions.” It queries DNS servers in different geographic locations, which is useful. But for most debugging, querying Google (8.8.8.8), Cloudflare (1.1.1.1), and the authoritative nameserver directly covers it. Three dig commands vs one website load with a cookie consent banner.

“My registrar has a DNS management panel.” That’s where you edit records. dig is where you verify they’re working. They’re not the same thing. You change a record in the panel, then run dig @ns1.your-registrar.com domain.com to confirm it took effect. Trust but verify.

dig cheat sheet

You made it. Or you skipped straight here. Either way, no judgment. Copy and paste these. Pin them. Tattoo them on your forearm. Whatever works.

The one command: dig +short example.com — the IP address, nothing else. For everything deeper, add a record type or @server.

Back to the top, you overachiever.