How to Diagnose DNS Resolution Issues (A Step-by-Step Approach)

"The domain isn't resolving" can mean a lot of different things — an actual DNS failure, a misconfigured record, a propagation delay, or sometimes nothing to do with DNS at all. Here's a systematic way to narrow it down.

Step 1: confirm it's actually a DNS problem

Before assuming DNS is broken, rule out the simpler explanations: is the site actually down at the application/server level? Is there a typo in the domain you're testing? Is a firewall or VPN interfering? A quick way to separate "DNS problem" from "server problem" is checking whether the domain resolves to an IP address at all — if it does, and that IP is reachable, DNS is doing its job and the issue is elsewhere.

Step 2: check the authoritative answer, not just your local cache

This is the step most people skip, and it's the one that actually matters. Your computer's DNS resolver might be serving a stale cached answer, giving a false impression that "DNS is wrong" when the authoritative data is actually already correct (or vice versa). Query the domain's actual authoritative nameservers directly, bypassing every intermediate cache.

This is exactly what the Nameserver Intelligence section of a DNSDecode scan does — it identifies the domain's authoritative nameservers, queries each one directly, and reports whether it responded authoritatively and how quickly. If the authoritative servers themselves are giving the wrong answer, the problem is at the DNS provider, not propagation.

Step 3: check for delegation mismatches

A very common real-world cause: DNS records are being edited in the wrong place. If a domain's nameservers point to Cloudflare, but changes are being made in the registrar's own (unused) DNS panel, those changes will never take effect — the registrar's zone isn't the one anyone is actually querying. A full domain scan surfaces exactly which nameservers are authoritative, which is the fastest way to catch this.

Step 4: check for SERVFAIL specifically

A SERVFAIL response is different from "no record" — it means the authoritative infrastructure encountered an actual error while trying to answer, most commonly a broken DNSSEC chain (see our DNSSEC guide) where a validating resolver refuses to trust a response it can't verify. If some users can reach a domain and others can't, and the ones who can't are on DNSSEC-validating resolvers (which includes most major ISPs), a broken signature chain is a prime suspect.

Step 5: check for a multi-provider conflict

If a domain's nameservers were recently changed — a migration between DNS providers, for instance — it's possible for some resolvers to still be pointed at the old provider's nameservers (which may no longer have the records at all) while others have picked up the new delegation. This looks exactly like a propagation issue but is actually a delegation-level split; comparing what different public resolvers return (see our propagation guide) will usually reveal it.

Step 6: rule out DNS entirely

If the authoritative nameservers are answering correctly, consistently, across resolvers — DNS is doing exactly what it's supposed to, and the problem is downstream: the server at that IP address isn't responding, a firewall is blocking the connection, or there's an application-level issue. At that point, DNS troubleshooting is done; the investigation moves to the server and network layer.

Putting it together

Rather than checking each of these manually with separate tools, run a full DNSDecode scan on the domain — it checks DNS resolution, authoritative nameserver responses, DNSSEC status, and cross-resolver propagation in one pass, and surfaces the findings that actually explain what's going wrong, ranked by severity, instead of a wall of raw records to interpret yourself.