DNS Resolution Failure
A practical incident runbook for determining whether a DNS failure is local, recursive, authoritative, network-related, or caused by stale data.
Incident objective
Establish scope first, then collect enough data to explain where resolution is failing.
Quick triage
Confirm scope
One hostname, one client, one resolver, one network, or everyone?
Identify the resolver
Determine which recursive resolver the client is actually using.
Compare direct queries
Query the recursive and authoritative sides independently.
Inspect the path
Check UDP/TCP 53 reachability, firewall changes, and packet loss.
Check freshness
Compare SOA serials, TTLs, negative caching, and recent DNS changes.
Verify recovery
Repeat the original query and compare with an independent path.
Core commands
dig example.com
dig @resolver.example example.com
dig +trace example.com
dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com SOA
ss -lntup | grep ':53'
tcpdump -ni any port 53Evidence to capture
Client side
Hostname, resolver IP, response code, timestamp, TCP/UDP behavior.
Resolver side
Cache state, logs, upstream errors, resource pressure.
Authoritative side
SOA serial, NS delegation, zone health, authoritative answers.
Network side
Firewall changes, packet loss, MTU issues, blocked TCP/53.
Do not do this first
A restart can hide the failure mode, flush useful state, and make root-cause analysis harder.
Recovery verification
# Original client path
dig example.com
# Explicit recursive resolver
dig @resolver.example example.com
# Independent path
dig +trace example.com