Common DNS Failures and a Troubleshooting Checklist

When a site suddenly stops loading, the cause almost always falls into one of two buckets: a DNS resolution failure (you can't get the right IP) or a server / network failure (you have the IP but can't reach it). Making that call first saves a lot of guesswork.

Step 1: Is it DNS or the server?

Start by checking whether the name resolves at all:

# Linux / macOS
dig +short example.com
# Windows
nslookup example.com

• No IP, or an obviously wrong IP → it's a DNS problem; keep going.
• Correct IP resolves, but the site still won't open → it's most likely a server or network problem. Hit the IP directly with ping <IP> and curl -v http://<IP> to test the service itself.

Step 2: Verify the records are correct

Check what's actually configured on the authoritative DNS:

dig A example.com          # A record (IPv4)
dig AAAA example.com       # AAAA record (IPv6)
dig CNAME www.example.com  # alias
dig +trace example.com     # trace resolution from the root down

Compare the results against what you entered in your domain control panel: the hostname (@ vs. www), the record type, and the target value. Watch for typos, stray spaces, or a missing trailing dot.

Step 3: Has the change propagated (TTL)?

If you edited a record but nothing changed, the usual culprit is a cached TTL that hasn't expired. Bypass your local cache and ask a public resolver directly:

dig @8.8.8.8 example.com +short    # Google DNS
dig @1.1.1.1 example.com +short    # Cloudflare DNS

If @8.8.8.8 already shows the new value but your machine still shows the old one, it's a caching issue. Flush the local cache:

# Windows
ipconfig /flushdns
# Linux (systemd)
sudo systemd-resolve --flush-caches

Lowering the TTL (say, to 300 seconds) before you make a change lets the next edit take effect faster.

Step 4: Do the NS records point to the right place?

If the record looks right in your panel but the world can't see it, check whether the domain's NS records actually point to the DNS provider you're editing:

dig NS example.com +short

Switching DNS providers at your registrar but forgetting to update the NS delegation is the classic "I changed it and nothing happened."

Step 5: CNAME chains and DNSSEC

• Broken CNAME chain: a CNAME must point to a name, not an IP, and can't sit on the root (@). Overly long chains or targets that no longer resolve will fail. Use dig +trace to inspect each hop.
• Misconfigured DNSSEC: when signatures don't match the records, a validating resolver returns SERVFAIL outright. Confirm with:

dig example.com +dnssec

If DNSSEC is the suspect, verify the DS record at your registrar first, and temporarily disable it to isolate the problem if needed.

Step 6: Resolves fine but still unreachable (blocking)

If dig returns the correct IP everywhere yet one network still can't connect, you may be looking at IP-level blocking or a routing issue, not DNS. Compare from a different location or over mobile data; run traceroute example.com (tracert on Windows) to see which hop drops. Changing DNS won't help here — you need a different IP or route.

Quick reference

| Symptom | Suspect first | Key command | |---|---|---| | No IP resolves at all | Wrong NS / missing record | dig NS, dig A | | Edit doesn't take effect | TTL cache | dig @8.8.8.8, ipconfig /flushdns | | Returns SERVFAIL | DNSSEC / authority failure | dig +dnssec, dig +trace | | Resolves but won't open | Server / blocking | ping, curl -v, tracert |

Summary

Troubleshooting DNS is about working in layers: decide whether it's a resolution or a connectivity problem, then check the record contents, cache propagation, NS delegation, and CNAME/DNSSEC in turn, and finally rule out non-DNS issues like blocking. Master the three staples — dig (or nslookup on Windows), a dig @8.8.8.8 comparison, and dig +trace — and most "the domain won't load" cases resolve in minutes.