Diagnosing NXDOMAIN Errors: What DNS Failure Codes Really Tell You
Direct Answer: NXDOMAIN indicates the DNS server explicitly reports that the queried domain does not exist, returning a non‑existent domain response. Unlike NOERROR or NXP, NXDOMAIN confirms the domain name is completely absent from the DNS hierarchy, not merely missing a specific record.
Learn how to read NXDOMAIN and related DNS failure codes, diagnose resolution issues in production, and fix them with practical steps.
How NXDOMAIN Is Generated During DNS Resolution
When a client asks “what is foo.example.com?”, the resolver follows a chain of queries: root → TLD → authoritative → possibly glue. Each step returns a DNS message with a 2‑byte RCODE. If any intermediate server knows the exact zone but cannot find a matching record, it returns NXDOMAIN (RCODE 3). The response includes the original QNAME and the class (IN). This differs from NOERROR (RCODE 0) where the answer section is empty, or NODATA (RCODE 0 with empty answer) where the domain exists but the requested record type is missing.
The process looks like this:
Client query – dig foo.example.com A +short.
Root server – returns NS for .com.
TLD server – returns NS for example.com.
Authoritative server – receives A query for foo.example.com.
Authoritative response – if the zone does not contain foo.example.com, it returns RCODE=3 (NXDOMAIN) with AA=1.
The resolver logs the NXDOMAIN, caches it for the TTL specified in the authority section (often 1–24 hours), and propagates the failure upward. Understanding where the NXDOMAIN originates helps you decide whether to check the DNS zone, the glue records, or the client’s resolver configuration.
Real‑World Incident: 2 a.m. Pager Alert on Launch‑Day
At 02:14 UTC on 2023‑09‑12, our SaaS platform went live with a new sub‑domain api.preview.app. Within seconds, users in Europe began seeing “Unable to resolve host api.preview.app” in their browsers. The incident page logged:
[2023-09-12 02:14:02] NXDOMAIN for api.preview.app (RCODE=3)
[2023-09-12 02:14:04] TTL=3600 cached at resolver 10.0.12.5
[2023-09-12 02:15:10] Edge cache miss, retry from client
The root cause was a mis‑configured glue record in the preview.app zone. The zone file contained:
$ORIGIN preview.app.
@ 3600 IN NS ns1.preview.app.
@ 3600 IN NS ns2.preview.app.
ns1 3600 IN A 203.0.113.10
But the glue for ns2.preview.app was missing (should have been 203.0.113.11). Without glue, recursive resolvers could not reach the authoritative name servers, resulting in a SERVFAIL that the authoritative server then turned into NXDOMAIN for the whole sub‑domain.
About the author
Admin SarangAI · AI Tools Editor
Part of the SarangAI editorial team covering AI tools, product releases, emerging technology trends, and practical web utilities for developers and creators.
Added missing glue record ns2.preview.app. IN A 203.0.113.11.
Forced a zone transfer (AXFR) and verified the updated zone with nslookup.
Cleared the local resolver cache (dig @8.8.8.8 api.preview.app).
Updated the CDN edge cache purge list and ran a full purge.
Notified the on‑call team and opened a ticket (INC‑2023‑0912‑001).
After step 3, the DNS lookup returned the correct IP (198.51.100.23), and the CDN purge restored service for all users.
Step‑by‑Step Remediation: Fixing an NXDOMAIN Outbreak (7 steps)
Verify the zone – dig @ns1.preview.app ANY preview.app +noall +answer. Expected result: NS records for ns1 & ns2 and correct SOA.
Check glue records – Use dig +short ns2.preview.app A. Correct output should be 203.0.113.11. If missing, edit the zone file and re‑transfer.
Force a DNS propagation check – Run the free DNS propagation checker on SarangAI for preview.app. The tool will show which resolvers still report NXDOMAIN.
Clear recursive caches – dig @8.8.8.8 preview.app A and dig @1.1.1.1 preview.app A. If they now return an address, proceed.
Update secondary DNS – If you use BIND, run rndc refresh preview.app and confirm the secondary zone file matches.
Purge CDN/edge caches – curl -X POST https://api.example.dev/v1/purge?zone=preview.app -H "Authorization: Bearer $TOKEN". Expect a 200 OK.
Validate end‑to‑end – Use the SarangAI's SSL chain checker on api.preview.app. Successful verification means the hostname resolves and the TLS chain is intact.
Each step produces a concrete result (NS record present, glue resolved, propagation cleared, cache refreshed, CDN purge acknowledged, SSL chain valid). Following this checklist eliminated the NXDOMAIN in under thirty minutes during the incident.
Common Mistakes When Diagnosing DNS Failures
Wrong assumption: “NXDOMAIN = typo” – Incorrect: Even a correctly spelled domain can return NXDOMAIN if the zone was deleted or the name servers are down. Correct: Verify the zone exists and the authoritative name servers are reachable before blaming the query.
Ignoring glue – Incorrect: For delegations, forgetting glue records leads to SERVFAIL that may be interpreted as NXDOMAIN by some resolvers. Correct: Always include A/AAAA records for each NS in the parent zone.
Relying on a single resolver – Incorrect: A single resolver may cache an old NXDOMAIN for the full TTL, masking a fix. Correct: Test from multiple sources (different networks, tools like dig @8.8.8.8, dig @1.1.1.1, and the free DNS lookup tool).
Misreading NOERROR vs. NODATA – Incorrect: An empty answer with NOERROR is often assumed to be NXDOMAIN. Correct: Use dig +noquestion +nocmd +answer to see if the authority section contains “non‑existent domain” or just an empty answer.
Skipping TTL awareness – Incorrect: After fixing a zone, you may see NXDOMAIN for hours because the old record is still cached. Correct: Clear local caches (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) and respect the published TTL when planning rollouts.
Quick Reference: DNS Response Code Comparison
Response Code
Meaning
Typical Cause
TTL Impact
NOERROR
No error; answer section may be empty
Valid domain, no record returned
Respects published TTL
NXDOMAIN
Non‑existent domain
Domain deleted, typo, zone missing
Cached for full TTL (often 1‑24 h)
SERVFAIL
Server failure
Recursive resolver bug, network outage
Cached briefly (minutes)
NODATA
Domain exists, no data for record type
A record missing, CNAME missing
Cached for TTL
REFUSED
Query refused
Access control list block
Cached short (seconds)
Understanding these codes helps you decide whether to edit the zone, adjust firewall rules, or wait for caches to expire.
Using SarangAI Tools in Your Workflow
When an NXDOMAIN appears, the free DNS propagation checker on SarangAI instantly shows which resolvers still return the failure. Pair this with a small dig loop to automate daily health checks:
If the status line reports NXDOMAIN, the script can trigger a Slack alert or open a ticket in your incident management system. For TLS issues, SarangAI's SSL chain checker validates that the certificate chain matches the resolved hostname, catching mis‑configurations that often accompany DNS problems.
Key Takeaways
NXDOMAIN means the domain name is completely absent from DNS, not just missing a record.
The incident on 2023‑09‑12 showed a missing glue record caused NXDOMAIN for an entire sub‑domain; fixing it took 27 minutes.
Follow the 7‑step remediation checklist: verify zone, check glue, run SarangAI DNS propagation checker, clear caches, refresh secondary DNS, purge CDN, validate SSL chain.
Common pitfalls include assuming NXDOMAIN = typo, ignoring glue, relying on a single resolver, misreading NOERROR vs NODATA, and forgetting TTL caching.
Use the DNS response code table as a quick reference and wrap dig in a small script for automated, repeatable checks.
Frequently Asked Questions
What does an NXDOMAIN response actually tell you about the domain?
An NXDOMAIN response tells you that the queried domain name is explicitly unknown to the authoritative server – the zone does not contain that name at any label. It is not a temporary failure; it indicates the domain does not exist in the DNS hierarchy.
How can you differentiate NXDOMAIN from a SERVFAIL or NOERROR with an empty answer?
NXDOMAIN carries RCODE 3 and includes an authority section stating the queried name does not exist. SERVFAIL (RCODE 2) means the server could not process the query due to a problem, with no authority info. NOERROR (RCODE 0) with an empty answer section means the domain exists but no matching record was found.
Why does an NXDOMAIN persist after you’ve restored a deleted domain?
The previous NXDOMAIN is cached by recursive resolvers for the TTL originally supplied (often 1‑24 hours). Until the cache expires or you flush it, clients will still see the old failure.
Which tools can help you verify that NXDOMAIN is resolved globally?
The free DNS propagation checker on SarangAI scans multiple public resolvers, and a dig loop can script bulk checks across resolvers, giving you a real‑time view of propagation status.
How does the TTL in an NXDOMAIN response affect troubleshooting?
A long TTL (e.g., 24 hours) means stale NXDOMAIN information will linger, masking a fix. Shorten the TTL before a deletion or migration, and always clear local caches to speed up validation.
