A Practical Guide to DNS Debugging
Every engineer eventually has a DNS problem. The frustrating part is not that DNS is complicated, it is that problems often look like something else entirely. A service times out, a deployment fails, a certificate will not renew. You spend an hour checking application logs before someone says “have you checked DNS?”
The Tools
Forget nslookup. Use dig. It gives you more information and its output is easier to parse programmatically.
# Basic query
dig example.com A
# Query a specific nameserver
dig @8.8.8.8 example.com A
# Trace the full resolution path
dig +trace example.com A
# Check all record types
dig example.com ANYThe +trace option is the most useful. It walks the entire delegation chain from root servers down to the authoritative nameserver. If there is a broken delegation or a misconfigured zone, trace will show you exactly where it breaks.
Common Patterns
Stale cache: You updated a DNS record but the old value persists. Check the TTL on the old record. If you set a 24-hour TTL, resolvers are within their rights to serve the old value for 24 hours. Before making DNS changes, lower the TTL first, wait for the old TTL to expire, then make your change.
CNAME at apex: You cannot put a CNAME on a bare domain (example.com). It breaks other record types. Some providers offer an ALIAS or ANAME record as a workaround, but this is not a universal standard.
Missing reverse DNS: Some services reject connections from IPs without PTR records. If your outbound email is being rejected or your SSH connections are slow, check reverse DNS.
One Last Tip
When debugging, always check from multiple locations. Your local resolver cache, your ISP resolver, and a public resolver like 1.1.1.1 or 8.8.8.8 might all give different answers. That difference is usually the clue you need.