DNS Troubleshooting Tools: What the Pros Actually Use

When something breaks in DNS, the first few minutes matter. You need to figure out whether the problem is delegation, caching, a bad record, a security misconfiguration, or something upstream — and you need to do it before your inbox fills up with "is the site down?" messages.

This guide covers every DNS diagnostic tool worth knowing. Some you'll use daily, others you'll reach for once a year when nothing else explains what's happening. For each tool, I cover what it does, when to use it, and a real example so you can see the output format and know what to look for.

Command-Line Tools: The Daily Drivers

These are the tools you'll use most often. They're available on virtually every Unix-like system and handle the vast majority of DNS troubleshooting tasks.

dig (Domain Information Groper)

dig is the gold standard for DNS queries among network engineers and sysadmins. It ships with BIND and is available on macOS, Linux, and Windows (via WSL or BIND installation). Unlike simpler tools, dig gives you the full DNS response including the answer section, authority section, additional section, response flags, and timing information.

When to use it: Whenever you need to inspect DNS records, trace the resolution chain, query specific nameservers, or check TTL values.

# Basic A record lookup
dig example.com A

# Query a specific nameserver directly
dig @8.8.8.8 example.com MX

# Get just the answer (clean output)
dig example.com A +short

# Trace the full resolution path from root to authoritative
dig example.com +trace

# Check all record types at once
dig example.com ANY

# Query with DNSSEC validation
dig example.com A +dnssec

# Check SOA serial for zone consistency
dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +short

What to look for in the output: The status field tells you whether the query succeeded (NOERROR), the domain doesn't exist (NXDOMAIN), or the server had a problem (SERVFAIL). The flags field shows whether the response is authoritative (aa) and whether recursion was available (ra). The ANSWER SECTION contains the actual records with their TTL values.

dig is the tool you should learn first and learn deeply. Most DNS problems can be diagnosed with dig alone.

nslookup

nslookup is older than dig and available on every operating system including Windows natively. It has both an interactive mode and a command-line mode. While dig is preferred by most professionals for its detailed output, nslookup is useful when you're on a Windows machine without WSL or need a quick check.

When to use it: Quick lookups on any OS, especially Windows. Also useful for non-technical team members who need to check DNS without learning dig syntax.

# Basic lookup
nslookup example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

# Look up MX records
nslookup -type=MX example.com

# Look up nameservers
nslookup -type=NS example.com

# Reverse DNS lookup
nslookup 203.0.113.50

Limitations: nslookup doesn't show TTL values by default, doesn't support +trace, and its output format is harder to parse programmatically. For serious troubleshooting, use dig.

host

host is the simplest of the three core DNS lookup tools. It's designed for quick, human-readable output without the verbose details that dig provides. It comes pre-installed on most Linux distributions and macOS.

When to use it: When you just need a fast yes/no answer — does this domain resolve, what are the MX records, what are the nameservers. No flags to remember.

# Basic lookup (shows A, AAAA, and MX by default)
host example.com

# Specific record type
host -t TXT example.com

# Query a specific nameserver
host example.com 1.1.1.1

# Reverse DNS
host 203.0.113.50

# Verbose mode (more like dig)
host -v example.com

host is ideal for shell scripts where you need clean, predictable output. For example, host -t A example.com | grep "has address" cleanly extracts just the IP addresses.

DNSSEC-Specific Tools

When you need to validate DNSSEC signatures, check chain of trust, or debug validation failures, these specialized tools go beyond what dig +dnssec can show you.

drill

drill is part of the ldns library and was designed as a modern replacement for dig with first-class DNSSEC support. It's particularly good at walking the DNSSEC chain of trust and showing you exactly where validation succeeds or fails.

When to use it: Debugging DNSSEC validation failures, verifying that your DNSSEC deployment is correct end-to-end, or when you need to trace the chain of trust from the root zone down to your domain.

# Basic query (similar to dig)
drill example.com A

# Trace DNSSEC chain of trust
drill -T example.com

# Chase DNSSEC signatures from root
drill -S example.com

# Check DS records at parent
drill -t DS example.com @f.gtld-servers.net

What to look for: The -S (chase) flag walks the entire DNSSEC chain and tells you whether each link validates. If you see Bogus at any level, that's where the chain breaks. Common causes include expired signatures, mismatched DS records at the registrar, or algorithm mismatches.

drill needs to be installed separately (apt install ldnsutils on Debian/Ubuntu, brew install ldns on macOS).

delv (DNSSEC Lookup and Validation)

delv ships with BIND 9.10+ and is specifically designed for DNSSEC diagnostics. Unlike dig +dnssec (which just fetches DNSSEC-related records), delv actually performs full validation and tells you whether the response is trusted.

When to use it: When you need to know whether a DNSSEC-signed zone actually validates correctly, not just whether the records exist.

# Validate a domain's DNSSEC
delv example.com A

# Show the full validation chain
delv example.com A +vtrace

# Check with a specific trust anchor
delv @8.8.8.8 example.com A +rtrace

What to look for: The key output is either fully validated (DNSSEC is working correctly) or unsigned answer (no DNSSEC) or a validation failure message. If you see validation failures, +vtrace shows you exactly which signature or DS record is causing the problem.

Network-Level DNS Tools

Sometimes the problem isn't with DNS records themselves but with the network layer — packets being dropped, responses being modified in transit, or latency issues between your resolver and the authoritative server.

tcpdump

tcpdump captures raw network packets and is invaluable when you need to see exactly what DNS queries are being sent and what responses come back. It shows you the actual bytes on the wire, which means you can catch issues like truncated responses, EDNS problems, or middleboxes modifying DNS traffic.

When to use it: When dig says one thing but your application behaves differently. When you suspect a firewall, proxy, or ISP is intercepting or modifying DNS traffic. When debugging DNS-over-TCP fallback issues.

# Capture all DNS traffic on port 53
sudo tcpdump -i any port 53

# Capture with full packet decode
sudo tcpdump -i any port 53 -vv

# Save to file for later analysis in Wireshark
sudo tcpdump -i any port 53 -w dns_capture.pcap

# Filter for a specific domain (in packet content)
sudo tcpdump -i any port 53 -vv | grep example.com

# Capture only queries TO a specific nameserver
sudo tcpdump -i any dst host 8.8.8.8 and port 53

What to look for: Compare the query and response. Are you getting the response you expect? Is the response truncated (TC flag set)? Is the response coming from the server you expect, or is something intercepting it? Are there retransmissions suggesting packet loss?

Wireshark

Wireshark provides a graphical interface for the same packet capture that tcpdump does, but with powerful filtering, protocol decoding, and visualization. It fully decodes DNS packets into human-readable fields, making it much easier to inspect individual queries and responses.

When to use it: Deep packet inspection when tcpdump output is too raw. Analyzing captured .pcap files. Visualizing DNS conversation flows. Debugging EDNS, DNS-over-TCP, or DNS-over-HTTPS issues.

You can capture with tcpdump -w capture.pcap on a remote server and then open the file locally in Wireshark. Use the display filter dns to isolate DNS traffic, or dns.qry.name contains "example.com" to focus on a specific domain.

mtr (My Traceroute)

mtr combines traceroute and ping into a single tool that continuously probes the network path to a destination. While not DNS-specific, it's essential for diagnosing network-level issues that affect DNS resolution — particularly latency or packet loss between your system and a nameserver.

When to use it: When DNS queries are timing out or taking abnormally long. When you suspect network issues between your resolver and the authoritative nameserver. When DNS works from one location but not another.

# Trace route to your nameserver
mtr ns1.example.com

# Report mode (run 10 cycles and exit)
mtr -r -c 10 ns1.example.com

# Use TCP instead of ICMP (useful if ICMP is blocked)
mtr --tcp -P 53 ns1.example.com

What to look for: High packet loss at any hop, especially the final destination. Latency spikes that could cause query timeouts. Asymmetric routing where the path out differs significantly from the path back.

DNS Zone and Configuration Tools

These tools help you validate DNS zone files and server configurations before deploying them, catching errors that would otherwise cause outages.

named-checkzone

Part of the BIND suite, named-checkzone validates a DNS zone file for syntax errors, missing records, and RFC compliance before you load it into production. It catches mistakes that would cause a zone to fail to load or serve incorrect data.

When to use it: Before deploying any zone file changes. As part of a CI/CD pipeline for DNS-as-code workflows. When you inherit a zone file and want to verify its integrity.

# Check a zone file
named-checkzone example.com /etc/bind/zones/db.example.com

# Check with strict mode
named-checkzone -k fail example.com db.example.com

What to look for: Missing SOA records, CNAME conflicts (a CNAME record coexisting with other record types at the same name), out-of-zone data, and syntax errors. The tool reports the exact line number of any problems.

named-checkconf

The companion to named-checkzone, this validates your BIND configuration file (named.conf). It catches syntax errors, missing zone files, incorrect ACLs, and configuration inconsistencies.

# Check the main configuration
named-checkconf /etc/bind/named.conf

# Check with zone file loading
named-checkconf -z

DNS Performance and Load Testing

When you need to measure how fast your DNS infrastructure responds or how much query load it can handle, these tools generate controlled DNS traffic and measure the results.

dnsperf

dnsperf is a DNS performance testing tool originally developed by Nominum (now Akamai). It sends a high volume of DNS queries and measures throughput, latency, and error rates. It's the standard tool for benchmarking DNS server performance.

When to use it: Load testing a new DNS server before putting it in production. Comparing performance between DNS providers. Capacity planning for authoritative nameservers.

# Basic performance test (queries from a file)
dnsperf -s 192.0.2.1 -d queryfile.txt

# Set queries per second limit
dnsperf -s 192.0.2.1 -d queryfile.txt -Q 1000

# Test with multiple clients
dnsperf -s 192.0.2.1 -d queryfile.txt -c 10

The query file is a simple text file with one domain and record type per line:

example.com A
example.com MX
mail.example.com A

DNSTop

dnstop monitors DNS traffic in real time, showing you which domains are being queried, which record types are most common, and which source IPs are generating the most queries. Think of it as top for DNS traffic.

When to use it: Monitoring a live DNS server to understand query patterns. Identifying unusual traffic (potential DDoS or amplification attacks). Finding which domains are generating the most queries.

# Monitor DNS traffic on eth0
sudo dnstop eth0

# Filter for specific source
sudo dnstop eth0 -s 192.168.1.0/24

Online DNS Tools

Command-line tools query from your machine's perspective. Online tools query from servers around the world, giving you a broader view of how DNS behaves for users in different regions.

DNSChkr (This Site)

My own DNS Inspector runs 25+ automated tests covering parent delegation, nameserver health, SOA configuration, MX validation, SPF/DKIM/DMARC authentication, DNSSEC status, and more. It produces a scored health report with prioritized recommendations.

The Propagation Checker queries 30+ global DNS resolvers to show you cache freshness — which resolvers have picked up your changes and which are still serving stale records, with TTL countdowns for each.

When to use them: After any DNS change to verify it took effect globally. As a periodic health check. When you need a quick comprehensive audit without running a dozen commands manually.

MXToolbox

MXToolbox specializes in email-related DNS diagnostics. It checks MX records, tests SMTP connectivity, validates SPF/DKIM/DMARC, and runs blacklist checks against your mail server IPs. It's particularly useful for email deliverability troubleshooting since it tests the full email path, not just DNS records.

Google Public DNS Flush

Google offers a public cache flush tool for their 8.8.8.8 and 8.8.4.4 resolvers. If you've made a DNS change and want Google's resolvers to pick it up immediately rather than waiting for the TTL to expire, you can flush specific records from their cache.

When to use it: When you've made a critical DNS change and can't afford to wait for TTL-based cache expiry. Note that this only flushes Google's resolvers — other resolvers (Cloudflare 1.1.1.1, ISP resolvers, etc.) still need to wait for their cache to expire naturally.

Cloudflare 1.1.1.1 Debug

Cloudflare provides a diagnostic page at 1.1.1.1/help that shows your current DNS configuration, whether you're using DNS-over-HTTPS or DNS-over-TLS, which Cloudflare data center is serving your requests, and whether DNSSEC validation is enabled. It's useful for verifying that encrypted DNS is working correctly on your network.

Choosing the Right Tool for the Job

With this many tools available, knowing which one to reach for is half the battle. Here's a decision framework based on what you're troubleshooting:

Building Your DNS Toolkit

You don't need every tool listed here installed on every machine. Here's a practical starting point:

On every workstation: dig, host, nslookup (usually pre-installed), bookmarks for DNSChkr and your preferred online tools.

On DNS servers and infrastructure: Add tcpdump, mtr, named-checkzone, and dnstop. These help you monitor, debug, and validate in production.

For DNSSEC deployments: Add drill and delv. These are essential for validating the chain of trust and debugging signature issues.

For capacity planning: Add dnsperf. Run baseline tests before and after infrastructure changes.

The most important thing isn't having the fanciest tools — it's understanding the DNS resolution chain well enough to know where to look. Start with dig +trace to see the full path, then use targeted tools to zoom in on the specific layer where things go wrong. Parent delegation issues need different tools than caching issues, which need different tools than network-level problems.

Master dig first. It handles 80% of troubleshooting scenarios. Add the specialized tools as you encounter problems that dig alone can't explain.