NetworkingAugust 4, 20266 min read

How to Diagnose DNS Problems with dig and nslookup

When a domain won't resolve, dig and nslookup tell you exactly why. A practical, example-driven guide to reading their output and finding the real problem.

NBy Nxeon

When a site won't load or email won't deliver, DNS is often the culprit — and dig and nslookup tell you exactly what's wrong. This is a practical, example-driven guide to using them: the commands that matter, how to read the output, and how to isolate the real problem. It ties together the setup work across this whole cluster.

dig basics

dig (Domain Information Groper) is the tool of choice on Linux and macOS. The simplest form:

dig example.com

That's verbose. For everyday checks, +short cuts to the answer:

dig +short example.com A

You'll get just the IP(s). Query any record type by naming it:

dig +short example.com MX
dig +short example.com TXT
dig +short example.com NS
dig +short www.example.com CNAME

To see the TTL and the authoritative answer neatly:

dig example.com A +noall +answer

The output columns are: name, TTL, class, type, value.

Checking specific problems

"My A record change isn't showing." Query your authoritative nameserver directly, bypassing caches:

dig @dana.ns.cloudflare.com example.com A +short

If the authoritative server has the new value but dig example.com (via your resolver) shows the old one, it's just caching — wait out the TTL. This is exactly DNS propagation in action, governed by TTL.

"Email isn't arriving." Check MX and the authentication TXT records:

dig +short example.com MX
dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig +short mail._domainkey.example.com TXT

Missing or wrong records here explain most mail issues — cross-check against how to set up SPF, DKIM and DMARC step by step.

The Nxeon game-server control panel — live console, player slots, and TPS
The Nxeon game-server control panel — live console, player slots, and TPS

Tracing the full delegation

When a domain doesn't resolve at all, trace it from the root down:

dig +trace example.com

This walks root → TLD (.com) → your authoritative nameservers, so you can see exactly where the chain breaks — often a nameserver delegation problem. Check which nameservers the parent hands out:

dig example.com NS +short

If those aren't the nameservers you expect, your registrar delegation is wrong — see how to set up custom nameservers for your domain or, for vanity nameservers, what is a glue record.

Reverse DNS with dig -x

To check a PTR record (crucial for mail servers):

dig -x 203.0.113.10 +short

It should return the hostname. Pair this with how to set up reverse DNS (PTR) for a mail server.

nslookup: the cross-platform fallback

nslookup ships everywhere, including Windows. It's less detailed but handy:

nslookup example.com
nslookup -type=mx example.com
nslookup -type=txt example.com

You can also point it at a specific server: nslookup example.com 1.1.1.1. For quick checks it's fine; for delegation tracing and TTLs, dig wins.

Reading status codes

The dig header shows a status::

  • NOERROR — success (even if no records of that type exist).
  • NXDOMAIN — the name doesn't exist. Check for typos or a missing record.
  • SERVFAIL — the nameserver failed, often a broken DNSSEC chain. See how to enable DNSSEC on your domain.

A dig flag cheat-sheet

A handful of flags cover almost everything:

  • +short — just the answer, no noise.
  • +noall +answer — the answer section with TTLs and types, tidy.
  • +trace — walk the delegation from the root down.
  • +dnssec — include RRSIG signatures and the ad flag.
  • +tcp — force TCP (useful for large responses).
  • @server — query a specific resolver or authoritative server.
  • -x IP — reverse lookup (PTR).

Combine freely: dig @1.1.1.1 example.com MX +short asks Cloudflare's resolver for MX records, briefly.

Check propagation across resolvers

After a change, different resolvers update at different speeds because of caching. Compare a few to see how far a change has spread:

dig @1.1.1.1 example.com A +short      # Cloudflare
dig @8.8.8.8 example.com A +short      # Google
dig @9.9.9.9 example.com A +short      # Quad9
dig @your-authoritative-ns example.com A +short   # source of truth

If the authoritative server shows the new value but public resolvers still show the old one, it's pure caching — wait out the TTL. This is DNS propagation in real time, and lowering TTL ahead of a change shortens it.

Script a quick health check

Bundle the common lookups into one command so you can audit a domain in seconds:

for t in NS A MX TXT; do
  echo "== $t =="
  dig +short example.com $t
done
echo "== DMARC =="; dig +short _dmarc.example.com TXT
echo "== PTR =="; dig -x 203.0.113.10 +short

Empty results where you expect data point straight at the problem — no NS means a delegation issue (see how to set up custom nameservers for your domain), no MX or TXT explains mail trouble, and a blank PTR fails mail servers per how to set up reverse DNS (PTR) for a mail server.

FAQ

Why does dig show a different result than my browser?

Your browser and OS cache DNS, and so does your resolver. Query the authoritative server directly (dig @ns example.com) to see the true current value versus a cached one.

How do I check DNS from a specific server?

Append @ and the server: dig @1.1.1.1 example.com uses Cloudflare's resolver; dig @your-ns example.com queries your authoritative server directly.

What does NXDOMAIN mean?

The queried name doesn't exist in DNS — a typo, a missing record, or the wrong domain. NOERROR with no answer means the name exists but has no record of that type.

Is dig or nslookup better?

dig is more powerful and precise (TTLs, +trace, reverse lookups), preferred on Linux/macOS. nslookup is simpler and ships on Windows by default — fine for quick checks.

How can I check DNS from another location or country?

Your local dig only shows what your nearby resolvers return, which may lag behind a change. To see DNS from elsewhere, query public resolvers in different regions directly (dig @1.1.1.1 example.com, dig @8.8.8.8 example.com), since these are globally distributed and hint at how far a change has spread. For true multi-location checking, web tools like whatsmydns.net query dozens of resolvers worldwide at once and map which locations see the new record versus the old — ideal for watching propagation. The authoritative answer, though, always comes from your own nameservers: dig @your-ns example.com bypasses all caching and shows the current truth, against which every cached location eventually converges.

Prefer a friendly UI? Try Nxeon's free DNS lookup tool and WHOIS tool — and when you're ready to host, spin up a fast NVMe VPS.

#dig#nslookup#dns#troubleshooting#networking#seobatch

Deploy your first server in under a minute

Creating an account is free and takes no card details. You pay when you deploy — choose a billing term and pay from your wallet or by card at checkout.