How to Troubleshoot DNS

DNS turns names (example.com) into IP addresses. When something is "randomly broken," DNS is usually the first thing worth ruling out — here's a systematic way to do that instead of guessing.

How resolution normally works

1. Browser/app cache — checked first, if the name was resolved recently
2. OS resolver cache — checked next
3. Recursive resolver (your router, ISP, or 1.1.1.1/8.8.8.8) — does the actual lookup on your behalf
4. Root servers → TLD servers (.com, .io, ...) → authoritative nameservers for the domain
5. The authoritative server returns the record, which gets cached at every layer above for its TTL

Anything along that chain can be the actual problem, which is why "just retry" often doesn't help — you need to find which layer is wrong.

Step 1: confirm it's actually DNS

curl -v https://1.2.3.4 -H "Host: example.com"

If hitting the IP directly (with the right Host header, or --resolve for HTTPS/SNI) works, the problem is DNS, not the app or network path.

Step 2: query directly and read the answer

dig example.com

Check: - Did you get any answer, or NXDOMAIN (domain doesn't exist as far as this resolver is concerned)? - Is the returned IP the one you expect? - What's the TTL? A long TTL means a stale/wrong record could stick around for a while.

Step 3: ask the record's own authoritative servers

Bypass every cache in between and ask the source directly:

dig example.com NS          # who is authoritative for this domain?
dig example.com @ns1.example.com   # ask that nameserver directly

If the authoritative server already has the wrong answer, the problem is at the source (DNS provider config), not propagation. If the authoritative server has the right answer but your resolver doesn't, it's a caching/propagation issue.

Step 4: check the record type

A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (verification/SPF/DKIM) all behave differently. A classic mistake: a CNAME at the zone apex, or a client resolving AAAA first and hanging on a broken IPv6 path even though A is fine.

dig example.com A
dig example.com AAAA
dig example.com MX

Step 5: check local overrides and cache

• /etc/hosts (or Windows equivalent) — a stale manual entry silently overrides everything
• Local resolver cache — flush it (sudo systemd-resolve --flush-caches, sudo dscacheutil -flushcache on macOS, etc.) before assuming "propagation" is still in progress
• Browser DNS cache — chrome://net-internals/#dns for a quick check in Chrome

Step 6: consider propagation and TTL, last

"DNS propagation" is really just caches at every layer above expiring on their own schedule (governed by TTL). If the authoritative record is correct and you've ruled out local caching, it's genuinely a matter of waiting out old TTLs — not something you can force, other than lowering the TTL before the next planned change.

Quick reference

Symptom	Likely cause
NXDOMAIN everywhere, including at authoritative NS	Record doesn't exist / typo / zone misconfigured
Correct answer at authoritative NS, wrong answer locally	Caching/propagation — wait out the TTL or flush cache
Works on IP directly, fails on hostname	DNS resolution issue, not app/network
Works over IPv4, hangs over IPv6	Broken/missing AAAA record or IPv6 path