NXDOMAIN Errors — What They Mean and How to Fix Them

If you're here, something is returning NXDOMAIN and you need to fix it. This page explains what NXDOMAIN actually means, the half-dozen common causes, and a systematic diagnostic procedure that finds the real one in under five minutes.

What NXDOMAIN actually means

NXDOMAIN is a specific DNS response code — RCODE 3 in the DNS protocol — that an authoritative nameserver returns when the queried name has no records of any type. It's a definitive answer:

• NXDOMAIN: "I am authoritative for this zone, and I confirm this name has no records." Different name, type doesn't matter.
• NOERROR + empty answer: The name exists, but no records of the queried type. (e.g., querying TXT for a name that has only A records.)
• SERVFAIL: The authoritative server is broken, or DNSSEC validation failed. See SERVFAIL explained.
• REFUSED: The server explicitly refused to answer (often access-control or wrong server).
• timeout: The server didn't respond at all.

NXDOMAIN is the cleanest possible "no" — it doesn't mean the network is broken, just that the name isn't there.

The five common causes

1. Typo in the hostname

By far the most common cause. wwww.example.com instead of www.example.com. example.con instead of example.com.

Diagnose: Re-read the hostname character by character. Try the parent domain: dig example.com — if that resolves but wwww.example.com returns NXDOMAIN, the typo is in the subdomain. Use the dashboard or dig +trace example.com to list the actual records present.

2. The record was deleted or never created

Someone removed the record (intentionally or by mistake), or it was never set up for that subdomain in the first place.

Diagnose: Query the authoritative server directly:

dig www.example.com @ns1.dnscale.eu

If authoritative returns NXDOMAIN, the record genuinely isn't there. Check the zone in the DNScale dashboard. Restore it if needed.

3. You're querying before propagation completed

You just added the record. Some resolvers haven't picked it up yet, especially if you previously queried the name and got NXDOMAIN — that negative answer is now cached.

Diagnose:

• Authoritative returns the record (dig @ns1.dnscale.eu)
• A public resolver still returns NXDOMAIN (dig @8.8.8.8)

That's negative-caching. Wait for the SOA's negative-cache TTL (often 300–3600 seconds) and retry. To avoid this in the future: don't query a name until you've confirmed the record exists in your zone.

See DNS propagation explained.

4. DNSSEC validation failure

If your zone is DNSSEC-signed and the signature chain is broken, validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, and most modern resolvers) will refuse the answer. This usually surfaces as SERVFAIL, but in some failure modes the resolver may behave as if the name doesn't exist.

Diagnose:

dig +cd www.example.com @8.8.8.8     # checking-disabled — bypasses DNSSEC validation
dig www.example.com @8.8.8.8          # default — validates DNSSEC

If the first returns the record and the second returns NXDOMAIN/SERVFAIL, DNSSEC is broken. Common causes: missing or wrong DS record at the registrar, expired signatures (zone hasn't been re-signed), KSK/ZSK rollover gone wrong. See DNSSEC key management.

5. Local resolver problem (browser-only NXDOMAIN)

If only your machine returns NXDOMAIN but other machines work fine, the issue is local: corrupted resolver cache, hosts-file override, VPN-injected DNS, browser-internal cache, or a malfunctioning ISP resolver.

Diagnose:

• Flush local cache: see how to flush DNS cache.
• Bypass local resolver: dig www.example.com @1.1.1.1. If that works, the problem is your local resolver.
• Check /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows) for a stale entry.
• Try a different network (mobile hotspot, home vs office) to isolate ISP-resolver issues.

The systematic diagnostic procedure

Run this in order. The first step that succeeds tells you the cause.

# 1. Authoritative direct (bypasses all caches)
dig www.example.com @ns1.dnscale.eu
 
# 2. A major public resolver
dig www.example.com @8.8.8.8
 
# 3. Another public resolver
dig www.example.com @1.1.1.1
 
# 4. Your local default
dig www.example.com
 
# 5. Check the parent zone delegation
dig +trace www.example.com
 
# 6. Check DNSSEC if zone is signed
dig +cd www.example.com @8.8.8.8
 
# 7. Check the SOA negative-cache TTL
dig SOA example.com @ns1.dnscale.eu

Interpretation:

Browser-specific NXDOMAIN errors

Major browsers surface NXDOMAIN with framework-specific error pages:

• Chrome / Edge: DNS_PROBE_FINISHED_NXDOMAIN
• Firefox: "Hmm. We're having trouble finding that site." with MOZILLA_PKIX_ERROR_INTERNAL_FAILURE in some variants
• Safari: "Safari can't find the server"

These are the same underlying DNS error. The browser doesn't know — it just gets back NXDOMAIN from the OS resolver and renders an error page. The diagnostic procedure above applies regardless of browser.

For the specific case where your browser shows the error but other devices work, see the local resolver section above and fix DNS_PROBE_FINISHED_NO_INTERNET.

Common mistakes when fixing

1. Adding the record but not waiting for propagation, then assuming it's broken when a resolver still returns NXDOMAIN. Wait at least the negative-cache TTL.
2. Forgetting the trailing dot in zone-file format. www.example.com (without dot) means relative; www.example.com. (with dot) means absolute. DNScale's dashboard handles this; if you're editing zone files directly, be precise.
3. CNAME at the apex. Setting a CNAME at example.com (rather than www.example.com) creates a configuration that some resolvers reject, returning NXDOMAIN-like behaviour. Use A records or ALIAS at the apex. See DNS CNAME record.
4. Wildcard collisions. A wildcard *.example.com matches subdomains, but explicit subdomain entries override it. If you have *.example.com → 192.0.2.1 and someone queries mistake.example.com, the wildcard answers — there's no NXDOMAIN. If you removed the wildcard expecting a name-not-found response and got an unexpected answer, this is why.
5. Hosts-file override. A stale /etc/hosts entry can mask DNS-level fixes. Always check.

When NXDOMAIN is the right answer

It's worth remembering that NXDOMAIN isn't always a bug. Legitimate uses:

• Subdomain takeover protection: explicitly leaving subdomains as NXDOMAIN to prevent attackers from claiming them via a third-party service.
• NXDOMAIN as deletion signal: removing a record is the correct way to retire a service.
• DNSSEC NSEC/NSEC3 proofs: signed authoritative nameservers prove negative answers cryptographically; the NXDOMAIN response carries signed denial-of-existence records.

If you confirm a name is supposed to be NXDOMAIN, leave it alone.

Related guides

• SERVFAIL errors — causes and fixes
• DNS propagation explained
• How to flush DNS cache
• Fix DNS_PROBE_FINISHED_NO_INTERNET
• DNS TTL best practices
• DNSSEC key management

References

• IETF RFC 2308 — Negative caching of DNS queries
• IETF RFC 5155 — DNSSEC NSEC3 hashed authenticated denial of existence
• IETF RFC 8499 — DNS terminology