← Back to Guides
TERMINAL

Debugging DNS with dig and nslookup

January 20, 2026•8 min read

When DNS isn't working, you need tools that show you what's actually happening. Enter dig and nslookup— two command-line utilities that every developer should know. They're powerful, fast, and installed on nearly every system.

The Basics: nslookup

nslookup is the simpler of the two tools. It's great for quick queries and available on Windows, macOS, and Linux.

Basic Usage

nslookup example.com

This returns the IP address(es) for example.com. You'll see both the DNS server that answered the query and the response.

Query Specific DNS Servers

nslookup example.com 8.8.8.8

This queries Google's public DNS (8.8.8.8) instead of your default resolver. Super useful for checking if the problem is with your local DNS or the authoritative servers.

Query Specific Record Types

nslookup -type=MX example.com

Common record types:

  • A — IPv4 address
  • AAAA — IPv6 address
  • MX — Mail exchange servers
  • NS — Nameservers
  • TXT — Text records (SPF, DKIM, verification codes, etc.)
  • CNAME — Canonical name (alias)
  • SOA — Start of authority (zone metadata)

The Power Tool: dig

dig (Domain Information Groper) is more powerful and provides more detailed output. It's the tool DNS professionals use. Available on macOS and Linux by default, and installable on Windows via WSL or BIND tools.

Basic Usage

dig example.com

The output shows:

  • Query information (what you asked for)
  • Answer section (the actual DNS records)
  • Authority section (which nameservers are authoritative)
  • Query time and server used

Short Output (Just the Answer)

dig example.com +short

This gives you just the IP address. Perfect for scripts or when you don't need the verbose output.

Query Specific Record Types

dig example.com MX

Or query multiple types at once:

dig example.com A AAAA MX

Trace the Full DNS Resolution Path

dig example.com +trace

This shows the entire DNS resolution process, starting from the root servers. Incredibly useful for understanding delegation and tracking down where queries are failing.

Query Specific DNS Servers

dig @8.8.8.8 example.com

The @ syntax lets you specify which DNS server to query. Try different servers to see if you're getting different answers (a sign of propagation issues or misconfiguration).

Reverse DNS Lookup

dig -x 93.184.216.34

This performs a reverse lookup—given an IP, it tells you the associated domain name.

Real-World Debugging Scenarios

Scenario 1: Website Not Loading

Your site isn't loading. Is it DNS?

dig yourdomain.com +short

If you get an IP address back, DNS is working. If you get nothing or an error, DNS is the problem. Next, check if the IP is correct:

dig yourdomain.com

Look at the ANSWER section. Is the IP what you expect? Check the TTL—if it's high and you recently changed the record, you're waiting for caches to expire.

Scenario 2: Email Not Working

Email delivery issues? Check your MX records:

dig yourdomain.com MX

Verify:

  • The MX records exist
  • They point to the right mail servers
  • The priority values are correct (lower number = higher priority)

Also check SPF, DKIM, and DMARC records:

dig yourdomain.com TXT

Scenario 3: Propagation Check

You just changed your DNS records. Are they propagating?

dig @8.8.8.8 yourdomain.com dig @1.1.1.1 yourdomain.com dig @208.67.222.222 yourdomain.com

Query multiple public DNS servers (Google, Cloudflare, OpenDNS). If they all return the same answer, propagation is complete. If they differ, some servers have the new record and some still have the old one.

Scenario 4: Finding Authoritative Nameservers

Which nameservers actually control your domain?

dig yourdomain.com NS

Then query those nameservers directly to see what they think the records should be:

dig @ns1.example.com yourdomain.com

Advanced dig Tricks

Check All Common Record Types at Once

dig yourdomain.com ANY

Note: Many authoritative servers now refuse ANY queries due to DNS amplification attacks, so this may not work everywhere.

Get Just the IP Address in Scripts

dig +short yourdomain.com A | head -n1

See What Your Local Resolver Cached

dig example.com

Look at the TTL value. If it's decreasing with each query, you're seeing a cached response. If it stays the same (or resets), you're hitting the authoritative server.

Common Issues and What They Mean

NXDOMAIN

The domain doesn't exist. Either you mistyped it, or the domain truly isn't registered.

SERVFAIL

The DNS server encountered an error. This usually means:

  • Authoritative nameservers are down
  • Misconfigured DNSSEC
  • Invalid zone configuration

REFUSED

The DNS server refused to answer your query. Common when querying a server that doesn't allow recursive queries from your IP.

No answer / Empty response

The domain exists, but the specific record type you asked for doesn't. For example, querying for an AAAA record on a domain that only has IPv4.

Pro Tips

  • Always use +short when you just need the answer — cleaner output, faster to read
  • Query authoritative servers directly — bypasses all caching, shows you the source of truth
  • Use +trace for mysterious issues — shows you exactly where delegation breaks down
  • Check from multiple locations — DNS can behave differently based on geographic location and resolver
  • Look at TTL values — they tell you how long until caches expire

Quick Reference Cheat Sheet

// Basic queries dig example.com dig example.com +short nslookup example.com // Specific record types dig example.com A dig example.com AAAA dig example.com MX dig example.com TXT dig example.com NS // Query specific server dig @8.8.8.8 example.com nslookup example.com 8.8.8.8 // Trace full resolution dig example.com +trace // Reverse lookup dig -x 93.184.216.34 // Query multiple types dig example.com A AAAA MX

Final Thoughts

dig and nslookup are indispensable tools for DNS debugging. They turn the invisible (DNS resolution) into the visible (concrete answers and timing data). When someone says "the site is down," your first command should be dig.

The more you use these tools, the faster you'll spot patterns and diagnose issues. DNS problems that used to take hours to debug will take minutes. And you'll finally be able to say with confidence: "Yes, it was DNS" or "No, actually it's something else."

← Back to Guides