DNS Troubleshooting from the Command Line

DNS is Broken and You Need to Fix It in 5 Minutes

DNS failure is the worst because it feels random. Sometimes it works. Sometimes it doesn’t. Your DNS resolver is lying to you and you need to find out why.

You don’t have time to open the network settings GUI. You need CLI tools that actually tell you what’s happening.

Step 1: Verify the Machine Has a Resolver

First, is your system even configured to talk to a DNS server?

cat /etc/resolv.conf

Look for nameserver lines:

nameserver 8.8.8.8
nameserver 8.8.4.4

If that file’s empty or missing (systemd-resolved might be managing this), check:

systemctl status systemd-resolved
systemd-resolve --status

You should see actual nameservers configured. If you see nothing, your system doesn’t know where to ask. That’s the problem.

Step 2: Can You Actually Reach a DNS Server?

dig @8.8.8.8 google.com

That @8.8.8.8 forces the query to Google’s public DNS. If this works, your network connectivity to DNS is fine. If it times out or fails, your network is broken (not DNS specifically).

You can also use:

nslookup google.com 8.8.8.8

Same thing, older tool, sometimes more readable output.

Step 3: Check Your Configured Resolver

Now test with whatever resolver your system is using:

dig google.com

Compare this to the forced Google query. If one works and one doesn’t, you’ve found the problem: your configured resolver is down or misconfigured.

Step 4: Dig Deep (Literally)

The dig tool is your best friend. It shows you everything:

dig example.com

Full output looks like:

; <<>> DiG 9.18.0
; (1 server found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.      IN  A

;; ANSWER SECTION:
example.com.    3600  IN  A  93.184.216.34

;; Query time: 45 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

What matters:

ANSWER SECTION: The actual IP address you got
status: NOERROR: No error (good)
Query time: How long it took (45ms is normal)
SERVER: Which resolver answered (192.168.1.1 is your router)

If you see status: NXDOMAIN, the domain doesn’t exist. SERVFAIL means the DNS server couldn’t reach the upstream resolver. TIMEOUT means the server isn’t responding.

Step 5: Trace the Query Path

Sometimes you need to see which nameservers are being asked:

dig example.com +trace

This shows the full chain from root nameservers down to the authoritative answer:

; <<>> DiG 9.18.0 example.com +trace
.        86400  IN  NS  a.root-servers.net.
.        86400  IN  NS  b.root-servers.net.
...
com.      172800  IN  NS  a.gtld-servers.net.
...
example.com.    172800  IN  NS  ns.icann.org.
...
example.com.    3600  IN  A  93.184.216.34

This tells you: root → .com registry → example.com’s nameserver → answer. If it breaks somewhere, you see exactly where.

Step 6: Reverse Lookups (IP to Name)

Sometimes you need to find the hostname for an IP:

dig -x 93.184.216.34

The -x flag reverses the lookup. Useful for identifying mystery hosts on your network.

Step 7: Check Specific Record Types

Websites use different record types. If A records resolve but mail doesn’t work, check MX:

dig example.com MX          # Mail servers
dig example.com NS          # Nameservers
dig example.com CNAME       # Aliases
dig example.com TXT         # TXT records
dig example.com SOA         # Start of Authority

Your mail config says “send to MX record” but DNS returns nothing? Now you see it.

Real Troubleshooting Example

# Is the domain resolvable at all?
dig example.com

# Gets no answer? Try a known-good resolver:
dig @1.1.1.1 example.com

# Still nothing? Domain might be down. Check root:
dig example.com +trace

# Got an answer from Google but not your local resolver?
# Your local resolver is misconfigured or down.

# Which resolver is your system using?
cat /etc/resolv.conf

# Try a different one:
dig @8.8.8.8 example.com

If Google DNS works but your configured resolver doesn’t, update /etc/resolv.conf to use a different resolver temporarily, or restart systemd-resolved:

sudo systemctl restart systemd-resolved

Quick Reference

dig example.com              # Basic lookup
dig @8.8.8.8 example.com    # Force resolver
dig example.com +trace      # Show full chain
dig example.com MX          # Mail records
dig -x 1.2.3.4              # Reverse lookup
nslookup example.com        # Alternative tool
cat /etc/resolv.conf        # Check config
systemd-resolve --status    # systemd DNS status

Advanced: Check DNS Propagation

You just changed a DNS record. Propagation can take hours. Check if it’s live everywhere:

# Check multiple public resolvers:
for resolver in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "=== $resolver ==="
  dig @$resolver example.com A +short
done

# Output:
# === 8.8.8.8 ===
# 93.184.216.34
# === 1.1.1.1 ===
# 93.184.216.34
# === 9.9.9.9 ===
# 93.184.216.100  <-- Not updated yet!

Quad9 (9.9.9.9) hasn’t updated. Give it a few more hours.

Debug DNSSEC Issues

Some domains use DNSSEC (signed DNS). Validation can fail silently:

# Check DNSSEC status:
dig example.com +dnssec

# Look for "ad" flag in output:
# ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1

# "ad" = DNSSEC validated, good
# No "ad" = Either unsigned or validation failed

# Check which nameserver is responsible:
dig example.com NS

DNSSEC misconfigurations are a common DNS problem. Misconfigured certificates make a domain unreachable for validating resolvers.

Troubleshooting Mail Server DNS

Mail servers use MX records and domain verification:

# Check MX records:
dig example.com MX

# Check SPF and DKIM:
dig example.com TXT

# Output should show:
# example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"

# Check reverse DNS (important for mail):
dig -x 93.184.216.34

# Mail servers reject mail from IPs without valid reverse DNS

If mail from your server gets marked as spam, the problem is usually missing reverse DNS or SPF/DKIM validation. These dig queries prove it.

The Common Cycle: Troubleshoot, Fix, Verify

Most DNS problems follow this pattern:

Something breaks (website unreachable, email bounces)
Check A/MX records (dig example.com A, dig example.com MX)
Trace the path (dig example.com +trace)
Fix the problem (update nameserver, fix zone file, etc.)
Verify with multiple resolvers (different public DNS servers)
Wait for cache to expire (TTL varies, usually 300-3600 seconds)

Each step uses one or two dig commands. No GUI, no waiting. You understand the problem in minutes.

DNS isn’t magic. It’s just queries and responses. When something breaks, these commands show you exactly where the break is. Most of the time it’s a misconfigured resolver or a network path failure. dig proves which one in seconds.