DNS Resolution Debugging Step by Step

Application can't connect to a service. The error might be DNS-related but it's unclear whether the problem is DNS resolution, caching, or the DNS server itself.

Systematic DNS debugging:

# 1. Basic resolution
dig example.com A          # Query A record
dig example.com AAAA       # IPv6
dig example.com MX         # Mail servers
dig example.com ANY        # All records

# 2. Query specific DNS server
dig @8.8.8.8 example.com   # Google DNS
dig @1.1.1.1 example.com   # Cloudflare DNS
dig @ns1.example.com example.com  # Authoritative

# 3. Trace the full resolution path
dig +trace example.com
# Shows: root -> TLD -> authoritative -> answer

# 4. Check TTL and caching
dig +noall +answer +ttlunits example.com
# Low TTL = recent change, might be propagating

# 5. Check what YOUR system resolves
getent hosts example.com   # Uses system resolver (includes /etc/hosts)
nslookup example.com       # Uses DNS only

# 6. Check local DNS config
cat /etc/resolv.conf       # DNS servers used
cat /etc/hosts             # Local overrides
resolvectl status          # systemd-resolved status

# 7. Check if DNS is the problem
curl -v --resolve example.com:443:1.2.3.4 https://example.com
# Bypasses DNS - if this works, DNS is the issue

# 8. Check propagation globally
# Use dig against multiple servers:
for ns in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "=== $ns ==="
  dig @$ns +short example.com
done

Common issues:

• Different results from different DNS servers = propagation in progress
• SERVFAIL = authoritative server is down or misconfigured
• NXDOMAIN = domain doesn't exist (typo? expired?)
• getent differs from dig = /etc/hosts override

DNS failures are often misdiagnosed as network or application issues. Systematic DNS debugging quickly identifies whether the problem is resolution, caching, propagation, or server-side.

Debugging DNS resolution failures