DNS ResolutionLevel 1 — BasicHigh severity5-10 minutes

DNS Resolution: Why Won't This Domain Resolve?

A step-by-step manual walkthrough for diagnosing DNS resolution failures using nslookup, dig, and ping.

Tools required: nslookup, dig (optional), ping

Overview

When a browser says a site 'can't be reached' or 'DNS_PROBE_FINISHED_NXDOMAIN', the first question is whether the problem is DNS (name-to-IP translation) or something further along (TCP, TLS, HTTP). This guide isolates DNS as the variable by checking resolution using your machine's configured resolver first, then a known-good public resolver, so you can tell 'the domain is genuinely broken' apart from 'my local DNS is misbehaving'.

Prerequisites

  • Access to a command prompt / terminal
  • The domain name you want to check

Step-by-Step Manual Check

1

Check what DNS server your machine is actually using

OSI Layer 3

Before testing resolution, confirm which resolver your machine will query. A misconfigured or unreachable local resolver is one of the most common causes of 'random' resolution failures.

ipconfig · windows
ipconfig /all | findstr /i "DNS Servers"

On macOS use: scutil --dns | grep 'nameserver[' — on Linux use: cat /etc/resolv.conf

Healthy result

DNS Servers . . . . . . . . . . . : 192.168.1.1
                                    8.8.8.8
A valid, reachable IP address (your router or a public resolver like 8.8.8.8/1.1.1.1).

Problem result

DNS Servers . . . . . . . . . . . : 169.254.x.x
Or no DNS servers listed at all — this indicates the machine never got a valid DHCP lease/DNS config.

What it means

If your configured resolver is unreachable or an APIPA (169.254.x.x) address, fix your network connection first — DNS testing beyond this point isn't meaningful until this is resolved.

If unresolved, escalate to: Level 1 — Basic

2

Resolve the domain using your default (local) DNS resolver

OSI Layer 7

This tests resolution exactly as your applications/browser will experience it.

nslookup · cross-platform
nslookup example.com

Replace example.com with the domain you are diagnosing.

Healthy result

Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    example.com
Address:  93.184.216.34
A returned IP address means your local resolver successfully resolved the name.

Problem result

*** UnKnown can't find example.com: Non-existent domain
or
DNS request timed out.
    timeout was 2 seconds.

What it means

'Non-existent domain' (NXDOMAIN) means the DNS record genuinely doesn't exist — check for typos, or the domain/record may have been deleted or never created. A 'timed out' error means your resolver never responded at all — that points to a local/network resolver problem, not a problem with the domain itself. Continue to Step 3 to tell these apart.

If unresolved, escalate to: Level 1 — Basic

3

Resolve the domain using a known-good public DNS resolver

OSI Layer 7

By explicitly querying a public resolver (Google's 8.8.8.8), you remove your local/ISP resolver from the equation. If this succeeds where Step 2 failed, the problem is your local DNS configuration, not the domain.

nslookup · cross-platform
nslookup example.com 8.8.8.8

Healthy result

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    example.com
Address:  93.184.216.34

Problem result

** server can't find example.com: NXDOMAIN
If a trusted public resolver also can't find it, the record genuinely does not exist publicly.

What it means

Public resolver succeeds + local resolver fails (Step 2) = your local DNS/router/ISP resolver is the problem — flush the cache (see the Local Machine Fixes guide) or switch to 8.8.8.8/1.1.1.1 in your adapter settings. Both fail = the domain's DNS records are actually broken; escalate to whoever manages the domain's authoritative DNS.

If unresolved, escalate to: Level 2 — Intermediate

4

Check the authoritative record directly with dig (optional, more detail)

OSI Layer 7

dig gives more diagnostic detail than nslookup, including the TTL and which server actually answered — useful when escalating to Level 2/3.

dig · cross-platform
dig example.com +short

Windows users need dig installed separately (e.g. via BIND tools) or can use Resolve-DnsName example.com in PowerShell instead.

Healthy result

93.184.216.34
A plain IP address with no errors printed.

Problem result

(empty output, or) ;; connection timed out; no servers could be reached

What it means

Empty output with no error usually means no A/AAAA record exists for that exact hostname (check for a required 'www.' prefix or CNAME). A connection timeout means dig itself can't reach any DNS server — a local network/firewall issue, not a domain issue.

If unresolved, escalate to: Level 2 — Intermediate

5

Confirm end-to-end reachability once resolution succeeds

OSI Layer 3

A successful DNS answer doesn't guarantee the host is actually reachable. Ping confirms basic IP-layer reachability once you know the correct IP.

ping · cross-platform
ping example.com

Healthy result

Pinging example.com [93.184.216.34] with 32 bytes of data:
Reply from 93.184.216.34: bytes=32 time=14ms TTL=56
(low, consistent latency; 0% loss)

Problem result

Request timed out.
or
Ping request could not find host example.com.

What it means

If DNS resolved (Steps 2-4 succeeded) but ping times out, that's expected for many web servers that block ICMP — it is NOT proof of an outage. Move to the 'Diagnosing Website Reachability' (HTTP) guide instead to test the actual service. If ping itself says it 'could not find host', DNS resolution silently failed again — repeat Step 2.

If unresolved, escalate to: Level 1 — Basic

Interpreting the Results

Work top-to-bottom: local resolver config -> local resolver query -> public resolver query -> authoritative record detail -> reachability. The moment one step diverges from 'healthy', that's your root cause layer. Most DNS 'random flakiness' reports resolve at Steps 1-3 (local machine/resolver), not at the domain's actual DNS records.

Common Causes

SymptomLikely CauseFix
Works on phone (cellular) but not on office Wi-FiOffice DNS server/resolver issue or DNS-based content filteringTest with 8.8.8.8 explicitly (Step 3); if that works, report it to the network team.
NXDOMAIN on every resolver, including 8.8.8.8Domain's DNS records are missing/misconfigured, or the domain has expiredEscalate to the domain/DNS zone owner.
Resolves fine but ping failsHost blocks ICMP (normal for many web servers) — not a faultUse the HTTP reachability guide instead.

Automated by

Diagnostic Suite - Network Security Diagnostic & Fix (Option 1)

The automated suite runs the equivalent of Steps 2-3 above (local + public resolver comparison) automatically and produces the dns_score shown in the Live Diagnostics report.