DNS Troubleshooting with dig and nslookup – Practical Guide

When a domain isn’t resolving correctly — site won’t load, email bouncing, AutoSSL failing — the answer is almost always in DNS. dig and nslookup are the command-line tools that show what DNS actually says, free from browser caching or assumptions. This guide covers the queries you’ll actually run, how to read their output, and the patterns that reveal what’s wrong.

Why dig over online checkers

Online DNS lookup tools (dnschecker.org, mxtoolbox.com) are useful but limited. dig run locally gives you:

• Query specific DNS servers (find which servers disagree).
• See full DNS response including authority and additional sections.
• Test from your network (the network your problem actually exists on).
• Read TTLs and timestamps accurately.
• Combine queries quickly.

dig is available on macOS and Linux by default. Windows users: nslookup ships natively; for dig install via WSL, Chocolatey, or use online dig at toolbox.googleapps.com/apps/dig.

Basic dig syntax

dig yourdomain.com                 # default A record from your system resolver
dig yourdomain.com A               # explicit A record
dig yourdomain.com MX              # mail exchanger records
dig yourdomain.com NS              # nameservers
dig yourdomain.com TXT             # text records (SPF, verification)
dig yourdomain.com AAAA            # IPv6 records
dig yourdomain.com CNAME           # alias records
dig yourdomain.com ANY             # all records (some servers refuse)

Reading dig output

Example output for dig yourdomain.com:

; <<>> DiG 9.10.6 <<>> yourdomain.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

;; QUESTION SECTION:
;yourdomain.com.            IN  A

;; ANSWER SECTION:
yourdomain.com.     3600    IN  A   192.0.2.1

;; Query time: 32 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat May 30 12:00:00 UTC 2026
;; MSG SIZE  rcvd: 59

What each section means:

• HEADER status: NOERROR — DNS lookup succeeded. NXDOMAIN means domain doesn’t exist; SERVFAIL means resolver failed.
• QUESTION SECTION — What you asked.
• ANSWER SECTION — The records returned. 3600 is TTL in seconds; IN A is record type; 192.0.2.1 is the value.
• SERVER — Which DNS resolver gave you this answer.
• Query time — How long it took.

Critical: querying specific DNS servers

This is dig’s superpower. Force the query to a specific server:

# Query Google's public DNS
dig @8.8.8.8 yourdomain.com

# Query Cloudflare's public DNS
dig @1.1.1.1 yourdomain.com

# Query the authoritative nameserver directly
dig @ns1.iwebvault.com yourdomain.com

# Find what record YOUR ISP's resolver is serving
dig yourdomain.com

Why this matters: caching. Your ISP’s resolver may have a stale record; Google’s may have fresh data. By querying multiple resolvers you find inconsistency.

Common diagnostic patterns

“My DNS change isn’t propagating”

# Check the authoritative source first
dig @ns1.iwebvault.com yourdomain.com

# If authoritative shows new IP, the change is live at source
# Now check resolvers
dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
dig yourdomain.com   # your local resolver

If authoritative shows the new value but resolvers show old: TTL caching. Wait until original TTL expires.

If authoritative still shows old value: the change wasn’t actually made (or wasn’t saved). Check your DNS panel.

“Email isn’t being delivered to my domain”

# Check MX records
dig yourdomain.com MX

# Check the A record for the MX hostname
dig mail.yourdomain.com A

# Verify SPF
dig yourdomain.com TXT | grep spf

# Check DKIM (replace 'default' with your selector)
dig default._domainkey.yourdomain.com TXT

# Check DMARC
dig _dmarc.yourdomain.com TXT

If MX returns nothing or wrong hosts: mail won’t deliver. Fix MX records.

“AutoSSL keeps failing”

# A record for the domain
dig yourdomain.com A

# Compare to server's actual IP
# AutoSSL needs DNS pointing to the server before it can issue cert

If A record returns a different IP than your iWebVault server: AutoSSL can’t validate. Fix DNS first.

“NS records show wrong nameservers”

# Query parent zone for NS records
dig yourdomain.com NS

# Or query at registrar level
dig +trace yourdomain.com

+trace follows the DNS hierarchy from root → TLD → your authoritative server. Useful for “which nameservers does the world think this domain uses”.

Short-form dig — saving keystrokes

dig +short yourdomain.com           # just the IP, nothing else
dig +short yourdomain.com MX        # just MX values
dig +noall +answer yourdomain.com   # full answer section, suppress noise

nslookup — the older alternative

nslookup ships natively on Windows; available on macOS/Linux. Less feature-rich than dig but covers basics:

# Basic query
nslookup yourdomain.com

# Query specific record type
nslookup -type=MX yourdomain.com

# Use specific DNS server
nslookup yourdomain.com 8.8.8.8

# Interactive mode
nslookup
> set type=MX
> yourdomain.com
> server 1.1.1.1
> yourdomain.com

Use nslookup when dig isn’t available (Windows defaults). For everything else, dig.

Web-based dig — for when terminal isn’t available

• toolbox.googleapps.com/apps/dig — Google’s web dig.
• dnsviz.net — DNS visualization including DNSSEC.
• intodns.com — health check of DNS configuration.
• mxtoolbox.com — mail-focused checks.

Useful when you’re on a phone or can’t access command line.

Common questions

“dig returns NXDOMAIN but my domain works in browser.” Browser may have cached the resolution. Try in incognito or different browser. If dig from multiple resolvers all NXDOMAIN, domain genuinely doesn’t resolve — check at registrar level.

“dig +trace fails part way through.” Usually means upstream nameservers aren’t responding properly. Note where it stopped — that’s the broken link in DNS chain.

“Different resolvers return different values.” Either TTL hasn’t expired everywhere yet, OR you have a DNS misconfiguration where authoritative servers disagree. Query authoritative servers directly to find truth.

“dig works but my actual application doesn’t see the same.” Application may use system resolver cached differently than dig. Restart application, clear OS DNS cache (sudo dscacheutil -flushcache on macOS, ipconfig /flushdns on Windows).

“What’s a good TTL?” 3600 (1 hour) is typical default. Lower (300) for records you change frequently. Higher (86400 / 24 hours) for stable records. Lower TTL means changes propagate faster but more DNS queries.

What’s next

• Understanding DNS records: DNS records guide.
• Propagation depth: DNS propagation.
• Specific email DNS setup: SPF/DKIM/DMARC.

Most DNS problems boil down to “the value I see isn’t what I expect” — and dig is how you find out which resolver, which server, and which TTL is responsible. Five-minute investment learning these commands saves hours of “why isn’t this working” later.