Diagnose an NXDOMAIN response

NXDOMAIN means the responding DNS server says the queried domain name does not exist in the DNS context it evaluated. It is not the same as an existing name that lacks the requested record type, and one resolver’s answer is not proof that every resolver or authoritative server agrees. DNS resolution can use cached data or follow referrals toward an authoritative source, so preserve the identity and role of the server that returned the answer [1].

Scope the symptom

Capture the exact query before interpreting it:

• fully qualified name, including every label;
• record type and class;
• response code;
• resolver or server that replied;
• answer, authority, and additional sections;
• remaining TTL and observation time; and
• network or DNS view, such as public, corporate, VPN, or local.

Check spelling, trailing labels, search-suffix behavior, and whether the user meant the apex, www, or another hostname. The DNS owner controls child-zone data; the registrar or registry path controls registration and the parent delegation.

Read-only checks

1. If the registered domain itself may be absent or expired, review the Domain Registration Lookup pathway and capture the available status, dates, and delegated nameservers.
2. Use the DNS Lookup pathway to query the exact name and type through named public resolvers. Record each response separately.
3. Query the zone’s parent-facing NS data, then query every intended authoritative server directly for the exact name and type.
4. Repeat with SOA or another known-existing name only to determine whether the zone itself is reachable. Do not treat that different query as proof about the original name.
5. Inspect the authority section of an authoritative negative response for the SOA record and its negative-cache lifetime.
6. Query another type at the same owner name to distinguish an absent name from an existing name with no data of the requested type.

RFC 2308 distinguishes NXDOMAIN from NODATA and specifies how authoritative negative answers are cached [3].

Interpret the observations

Observation	Supported interpretation	Responsible owner
Every authoritative server returns NXDOMAIN	The intended authority currently publishes the name as absent	DNS-zone owner
Authoritative servers agree on an answer, but one resolver returns NXDOMAIN	That resolver may hold a negative cache entry or use a different view or policy	Recursive resolver or network owner
Authoritative servers disagree	Zone publication or synchronization is inconsistent	DNS provider
Parent referral is absent or points elsewhere	The query may not be reaching the intended child zone	Registrant, registrar, or registry path
NOERROR with no requested RRset	The name may exist while that record type does not	DNS-zone owner

Negative answers can remain cached after a record is added. Their lifetime is not reset by editing the authoritative zone [2].

Likely causes

• a typo, unintended search suffix, or wrong owner name;
• the record was never created or was removed;
• a negative answer was cached before the record existed;
• some authoritative servers have not loaded the same zone version;
• the parent delegates to a different nameserver set than expected;
• the registration expired, is on hold, or lacks a usable delegation;
• split-horizon DNS intentionally serves another view; or
• resolver policy supplied a synthetic or stale negative answer.

An Extended DNS Error can add diagnostic context such as a stale NXDOMAIN, but it does not replace the base response code and may not be present [4].

Safe next actions

• Read-only: correct the queried name or type and repeat the same recorded checks.
• Reversible: if every intended authority agrees the record is absent, have the DNS-zone owner add the reviewed RRset from the zone’s source of truth. Preserve the prior export and avoid unrelated edits.
• Availability-impacting: if authoritative servers disagree, stop record changes and have the DNS provider restore consistent publication first.
• Ownership-impacting: if registration or parent delegation is wrong, use the authorized registrar account and a reviewed recovery or delegation procedure. Do not “fix” child records to compensate for the wrong parent.

Wait for observed negative cache lifetimes where applicable. Changing resolvers to bypass a failure can hide resolver-specific policy or DNSSEC behavior; it is not a root-cause fix.

Verification

Repeat the original exact query and record:

1. the parent delegation reaches the intended authorities;
2. every intended authoritative server returns the same response and RRset;
3. selected recursive resolvers refresh to an explainable state as their observed cache lifetimes permit; and
4. the application consumes the name expected by the change.

Verification is complete only for the named observers and times recorded. Do not report a global propagation percentage.

What this evidence does not prove

An NXDOMAIN response does not by itself prove that:

• the domain registration is available, expired, or owned by a particular party;
• every resolver sees the same answer;
• DNSSEC caused the response;
• the intended record exists at a different spelling; or
• a website, certificate, CDN, or origin would work after DNS is corrected.

Next protocol layer

If authoritative DNS is correct but recursive answers differ, continue with different resolvers return different answers. If the response is SERVFAIL, use the SERVFAIL diagnosis path. Once the expected address or alias resolves consistently, verify TLS and HTTP rather than continuing to edit DNS.