DNS_PROBE_FINISHED_NXDOMAIN

DNS_PROBE_FINISHED_NXDOMAIN: what it means and how to fix it

The domain name itself doesn't resolve to an address at all — a layer below HTTP, below even opening a connection.

Quick answer

Your browser tried to look up the domain name and was told, definitively, that it doesn't exist — not "temporarily unreachable," but "no such name." DNS's own wire protocol has a specific response code for exactly this: RCODE 3, "Name Error." Per RFC 1035 §4.1.1: "this code signifies that the domain name referenced in the query does not exist." Chrome's DNS_PROBE_FINISHED_NXDOMAIN is its own name for receiving exactly that response.

This is overwhelmingly a typo, a domain that was never registered, or your own DNS cache holding onto something stale — genuinely the site owner's fault only in a minority of cases (an expired registration, a broken DNS migration). Double-check the spelling first, then try a different DNS resolver before assuming it's on their end.

Before assuming it's the site's fault
  • 1. Re-check the spelling — NXDOMAIN fires just as confidently for a typo as for a domain that was never registered.
  • 2. Try a public resolver directly (8.8.8.8 or 1.1.1.1) instead of whatever your network hands you by default.
  • 3. Try a different network entirely (cellular data instead of Wi-Fi) — if it resolves there, the problem was local to your original network's DNS.
If you own the domain

Diagnosing a real NXDOMAIN on your own domain

  1. 1

    Check registration status first. An expired domain that hasn't been renewed is the single most common self-inflicted cause — check your registrar directly, not just the DNS provider.

  2. 2

    Check the zone itself for the missing record. Especially after switching DNS providers — a record that existed at the old provider has to be re-created at the new one; nothing carries over automatically.

  3. 3

    Check nameserver delegation at the registrar. If your registrar is still pointing at your old DNS provider's nameservers after a migration, your new provider's records are never even consulted, no matter how correct they are.

  4. 4

    Give a fresh record time to propagate. A just-created record can take time to reach every resolver depending on the TTL involved — real, but usually resolved within minutes to a few hours, not a sign of an ongoing problem.

Checking resolution directly, bypassing local cache 
dig example.com @8.8.8.8

# or, checking delegation itself
dig example.com NS

Querying a public resolver directly (rather than your system's default) rules out a local caching issue and shows you exactly what the rest of the internet actually sees.

What HeimPulse actually catches here

Worth being precise about this: HeimPulse doesn't monitor DNS records directly — there's no alert for an approaching domain renewal or a changed nameserver on its own. What it does do honestly: resolving DNS is an unavoidable first step of every single HTTP request an HTTP check makes, so if your domain stops resolving entirely, any existing check against it fails the same way a connection failure would — no response, an HTTP status code assertion failing with the underlying resolution error, and the check reading as a full outage. That's a real, useful side effect of monitoring the endpoint at all — not a dedicated DNS-monitoring feature, and it's worth knowing the difference before assuming one covers the other.

Frequently asked questions

Is DNS_PROBE_FINISHED_NXDOMAIN the same as the site being down?

No — it's a layer below that question entirely. "The site is down" implies a server exists and isn't responding. NXDOMAIN means DNS couldn't even find an address to try connecting to. The server, if one exists, was never contacted, because the domain name itself didn't resolve to anything.

How do I tell if it's my computer or the actual domain?

Try a different DNS resolver — for example, running a lookup against 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) instead of your default one. If those also fail to resolve the domain, it's not your local DNS cache or ISP; the domain itself has a real problem. If they succeed where your normal browsing fails, it's a local DNS/cache issue on your end, and flushing your DNS cache or switching resolvers usually clears it.

Does HeimPulse monitor DNS records directly?

No — there's no dedicated DNS-record monitoring feature (no alert for an expiring domain, a changed MX record, or a broken NS delegation specifically). What it does do: every HTTP check has to resolve DNS as part of sending the request, so if a domain stops resolving entirely, any HTTP check against it fails immediately as a side effect — not because DNS is being watched on purpose, but because resolution is a precondition of the request succeeding at all.

What does a HeimPulse check actually show for this?

The same thing it shows for a connection failure: no HTTP response was ever received, so an HTTP status code assertion (if configured on the endpoint) fails with a message describing the underlying resolution error, not a status code — because there's no status code to report. It reads as a full outage, which for a domain that no longer resolves, it is.

Full uptime monitoring feature → · All error explainers →

Know the moment your endpoint stops resolving at all.

Free plan, no credit card, set up in a few minutes.