10 Essential DNS Queries Solved with DIG

DNS is my daily bread. Nine years building EuroDNS infrastructure, managing zones, debugging resolution failures, migrating nameservers at scale. These are the ten dig queries I reach for most — the ones that actually solve problems.

Laptop screen showing a dark terminal with green code on a desk

Throughout this guide I use +short for cleaner output. When you need the full picture, drop it.

1. Find a Domain's IP Address

dig +short amazon.com

72.21.211.176
72.21.214.128
72.21.194.1

Multiple IPs mean Round Robin DNS — clients pick one at random. Records are cached for the duration of their TTL. To target a specific resolver: dig +short amazon.com @8.8.8.8.

2. Identify Nameservers for a Domain

Essential before any DNS migration. Verify delegation before you touch anything.

dig NS +short anouar.im

n1.eurodns.com.
n2.eurodns.com.
n3.eurodns.com.
n4.eurodns.com.

NS TTLs are typically long (24h+). During migrations, keep the old zone live for at least the full TTL duration before decommissioning.

3. Trace the Full DNS Resolution Path

+trace bypasses caches and walks the full delegation chain — root servers → TLD → authoritative. Use this when you suspect a delegation problem.

dig google.com +trace

The output shows every hop: root servers → .com TLD servers → Google's own nameservers. If something breaks in the chain, this is where you find it.

4. Find a Domain's Mail Servers

dig MX adlani.com

adlani.com.  3527  IN  MX  10 aspmx.l.google.com.
adlani.com.  3527  IN  MX  20 alt2.aspmx.l.google.com.
adlani.com.  3527  IN  MX  30 aspmx5.googlemail.com.

Lower priority number = higher preference. MX records must point to A records, not CNAMEs (RFC 2181 §10.3). An MX query on a domain won't return results for its subdomains.

5. Reverse DNS Lookup

PTR records map IPs back to hostnames. Essential for email reputation, security checks, and making traceroute output readable.

dig +short -x 8.8.8.8

google-public-dns-a.google.com.

PTR records are controlled by the IP owner, not the domain owner. If reverse DNS isn't set, you'll get nothing — or worse, someone else's hostname.

6. Find Nameservers for a TLD

Same syntax as any domain. Useful when debugging delegation issues at the registry level.

dig +short NS nl.

nl1.dnsnode.net.
ns1.nic.nl.
ns2.nic.nl.
ns3.nic.nl.

7. Query a Specific DNS Server

@ lets you target any resolver or nameserver directly. Useful for comparing cached results against authoritative output, or testing a new configuration before cutover.

dig google.com @8.8.8.8

Compare the answer you get from Google's public resolver with what your ISP returns. Differences reveal caching or propagation issues.

8. Check When a Record Expires from Cache

The TTL column tells you how many seconds until the resolver queries again.

dig google.com +noall +answer

google.com.  105  IN  A  74.125.79.99
google.com.  105  IN  A  74.125.79.103

105 seconds remaining. During migrations, I drop TTLs to 300s (5 min) 24–48 hours before the change, make the switch, then raise them back once propagation confirms.

9. Verify Zone Sync Across Nameservers

Compare SOA serial numbers across all authoritative nameservers. Same serial everywhere = in sync. Mismatch = replication problem.

dig google.com +nssearch

SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns1.google.com
SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns2.google.com
SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns3.google.com
SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns4.google.com

Quick check — all serials should match:

dig google.com +nssearch | awk '{print $4}' | sort | uniq -c

4 2011120502

Four nameservers, one serial. Zone is healthy.

10. Check if a Zone Exists on a Nameserver

Look at the status header, not just the answer section.

NOERROR — zone exists
NXDOMAIN — domain does not exist
REFUSED — nameserver won't answer (policy or not authoritative)

# Existing domain
dig SOA google.nl @ns1.nic.nl.
# → status: NOERROR

# Non-existing domain
dig SOA googleqwerty.nl @ns1.nic.nl.
# → status: NXDOMAIN

# Domain not managed here
dig SOA google.com @ns1.nic.nl.
# → status: REFUSED

Don't assume from empty answers — always read the status code.

DNS problems are almost always one of three things: wrong record, wrong TTL timing, or a delegation gap. These ten queries cover all three.