DNS problems: a diagnosis order that finds the cause fast

The diagnosis that saves the most time: before touching anything, work out which layer is broken. "The site is down" usually means one of four very different failures: your machine cached something stale, your resolver is having a moment, the domain's records are wrong, or the server behind the name is actually down. Each layer has a ten-second test.

Quick checks, in order

1. Is it down for everyone, or just you? Try the site on another network (phone on mobile data). If it loads there, the problem is yours — skip to step 4. If it fails everywhere too, go to step 3. 2. Can you reach other sites? If nothing resolves, your connection or resolver is the problem, not the site. 3. What does the name resolve to? A DNS lookup tool (or nslookup example.com in a terminal) shows what the name currently points at. If it returns nothing or an old address while the host's dashboard says the records are right, the records or their propagation are the story — the custom-domain connection order covers the record side. 4. Is your own cache stale? This is the classic "I fixed it but still see the old site": flush your machine's cache — on Windows ipconfig /flushdns; on macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; on Linux, resolvectl flush-caches where systemd-resolved runs. Then retry with a fresh browser tab.

The causes behind each symptom

Old site, new server: a cached record or a not-yet-propagated one. DNS records carry a TTL — how long any resolver may keep them — so changes become visible resolver by resolver, not everywhere at once. Nothing is "stuck"; it is expiring. New site, no resolution at all: missing or malformed records, wrong nameservers, or a domain whose registration lapsed — check the registrar first. Works on one device only: that device's cache or its configured DNS server. Intermittent, weird, ads redirecting: try a different reputable resolver (your router's default may be poorly maintained); changing resolvers on the device is a two-minute test that isolates the problem layer instantly.

Common mistakes

Changing records repeatedly while propagation is mid-flight (now nobody knows which version any resolver has — make one change, then wait out the TTL). Blaming the host before the lookup (step 3 exists so you don't). And the big one: assuming DNS when it's actually the browser — the browser-problem triage catches the cached-page-and-extension family, and the restart reflex clears more "DNS problems" than any setting.

When it's them, not you

If lookups from multiple networks and resolvers all fail on one specific name, the domain's authoritative nameservers are the failing layer — that's registrar/hosting support, with the lookup output in hand. If everything everywhere fails, it's your ISP. Bring evidence: which layer, which test, which timestamp. Support escalates diagnosis, not desperation — and if DNS itself is the mystery, start there.