Guides · DNS
DNS Not Resolving? A Step-By-Step Checklist
A domain won't resolve — is it your machine, your resolver, or the domain itself? This ordered checklist isolates the layer at fault using the error code and a public resolver, then points to the exact fix.
By Cody · 8 min read · Published
The short version
When a name will not resolve, the fastest path to the fix is to figure out which layer is at fault: your machine, the resolver you are using, or the domain's own nameservers. Two checks split the whole problem apart — the error code you get back, and whether a public resolver succeeds where you failed.
Work the checklist below in order. Each step either clears a layer or points at the culprit, so you stop guessing and go straight to the thing that is actually broken.
Step 1 — Is it you, or is it the domain?
Before anything else, query the name against a public resolver you know is healthy — Cloudflare's 1.1.1.1 or Google's 8.8.8.8. This one test decides everything that follows:
- Public resolver works, your machine doesn't → the fault is local: your configured resolver, cache, hosts file, or a VPN. Jump to the local-layer step.
- Public resolver also fails → the fault is upstream at the domain's nameservers or its delegation. Read the error code next.
Step 2 — Read the error code
The status the resolver returns tells you what kind of failure you are dealing with:
| Error | Meaning | Where to look |
|---|---|---|
NXDOMAIN | The name authoritatively does not exist. | Typo, missing record, or expired/deleted domain. |
SERVFAIL | The resolver could not get a clean answer. | Broken authoritative server, delegation, or DNSSEC. |
| Timeout / no response | Nothing answered in time. | Nameservers down or unreachable; network / firewall. |
NOERROR but no record | The name exists but the record type you asked for does not. | Wrong record type, or the record was never added. |
For the difference between the two you will meet most, see NXDOMAIN vs SERVFAIL.
Step 3 — Check the authoritative side
If the failure is upstream, go to the source. Query the record directly and confirm three things:
- The record exists — the right type (A, AAAA, CNAME, MX) is actually published for that exact name.
- The delegation is intact — trace the name from the root and check that the parent zone's NS records match the ones your own nameservers publish. See reading a full dig +trace response.
- Every nameserver answers — a lame or unreachable server in the set causes intermittent failure even when the record is correct.
Step 4 — If it changed recently, suspect caching
A record that resolves to the old value is almost always TTL caching, not a hard failure. The authoritative server has the new value, but resolvers keep serving the cached copy until its TTL expires. Confirm the new value directly against the authoritative nameservers, then either wait out the TTL or watch it roll through several resolvers. See DNS TTL explained for how long to expect, and lower the TTL before your next planned change.
Step 5 — Clear the local layer
If Step 1 pointed at your machine, work through the local suspects:
- Stale cache — flush the OS resolver cache and restart the browser.
- Hosts file — check for a leftover entry overriding the real record.
- VPN / corporate resolver — a tunnel or work network may intercept DNS; test with it off.
- Wrong resolver — if your configured resolver is unhealthy, switch temporarily to a public one.
Flush the cache only after confirming the authoritative record is correct — otherwise you just cache the wrong answer again.
Running the checklist in the tools
Start with the DNS lookup tool to read the record and its TTL, and nslookup for a quick status and answer on a single name. When you suspect a resolver disagreement or a change still propagating, the resolver comparison tool shows the same record across several public resolvers at once — the fastest way to confirm whether the answer is consistent everywhere or still rolling out.
The 'is it you or the domain?' test
- Example input
dig @1.1.1.1 example.com A- Example result
;; ->>HEADER<<- opcode: QUERY, status: NOERROR example.com. 86400 IN A 93.184.216.34 # public resolver returns a clean answer, but your machine fails # -> the record and delegation are fine # -> the fault is LOCAL: your resolver, cache, hosts file, or VPN
If the public resolver returns SERVFAIL or NXDOMAIN instead, the problem is upstream at the domain's nameservers — move to Step 2 and read the error code.
Related tools
FAQ
How do I tell if a DNS problem is my machine or the domain?
Query the name against a public resolver like 1.1.1.1 or 8.8.8.8. If the public resolver returns the right answer but your machine does not, the fault is local — your configured resolver, cache, hosts file, or VPN. If the public resolver also fails, the problem is upstream at the domain's nameservers or its delegation. This single test splits every DNS problem into 'you' versus 'them' in one step.
What does NXDOMAIN mean when a site won't load?
NXDOMAIN means the name authoritatively does not exist. The most common causes are a typo in the hostname, a record that was never created (for example a subdomain you forgot to add), or a domain that has expired or been deleted. Because it is an authoritative 'no', retrying will not help — you need to fix the name, add the missing record, or renew the domain.
What does SERVFAIL mean and how is it different from NXDOMAIN?
SERVFAIL means the resolver could not get a clean answer at all, as opposed to NXDOMAIN's definite 'does not exist.' It usually points to a broken authoritative server, a delegation problem, or a DNSSEC validation failure. NXDOMAIN is a firm answer; SERVFAIL is the resolver giving up. The two need different fixes, which is why reading the exact error code early saves time.
I updated a DNS record but it still shows the old value. Why?
Caching. Resolvers hold a record for the length of its TTL, so until that timer expires they keep serving the old value even though the authoritative server has the new one. Check the record directly against the authoritative nameservers to confirm the change is live, then wait out the TTL — or compare several public resolvers to watch the change roll through. Lowering the TTL before a planned change avoids this next time.
How do I flush my DNS cache?
On Windows run 'ipconfig /flushdns'; on macOS run 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder'; on Linux it depends on the resolver (for systemd-resolved, 'resolvectl flush-caches'). Browsers also keep their own cache, so restart the browser too. Flush the cache only after you have confirmed the authoritative record is correct — otherwise you will just re-cache the wrong answer.
Why does the domain resolve for other people but not for me?
That pattern means the domain itself is fine and the problem is local to you or your network. Likely culprits are a stale local cache, an entry in your hosts file overriding the real record, a VPN or corporate resolver intercepting DNS, or your ISP's resolver having a bad cached copy. Testing against a public resolver and checking your hosts file usually pinpoints it.
The nameservers look right but the domain still fails. What next?
Check the delegation, not just the records. Trace the name from the root down and confirm the nameservers the parent zone points to match the ones your domain actually publishes, and that each of those servers answers authoritatively. A parent/child NS mismatch or a lame nameserver produces intermittent or total failure even when the records themselves are correct.
Last reviewed: 2026-07-08.