NXDOMAIN

NXDOMAIN is a DNS response indicating that the requested domain name does not exist. An authoritative server or recursive resolver returns this result when it cannot find the queried name in the relevant DNS namespace. The response concerns the name itself, not merely a missing record type.

What an NXDOMAIN response means

DNS uses response codes to explain the outcome of a query. This code, formally named “Non-Existent Domain,” tells the requester that the queried hostname cannot be resolved because no matching name exists. A web browser may translate the result into a message such as “server IP address could not be found.”

The result differs from a valid domain that lacks a particular record. If a hostname exists but has no requested record type, the server can return a successful response with an empty answer. That distinction matters when troubleshooting mail, certificate validation, service discovery, and other systems that query records beyond A or AAAA.

Common causes of NXDOMAIN

A typing error is the simplest cause. A missing character, incorrect subdomain, or wrong top-level domain sends the resolver to a name that was never configured. Applications can create the same problem by building hostnames incorrectly or retaining outdated service addresses.

DNS configuration errors are another common source. The required record may not exist, the domain may use the wrong nameservers, or a zone may not be loaded on every authoritative server. An expired or deleted domain can also disappear from the delegated namespace.

Negative caching can preserve the response after an administrator creates or corrects the record. Resolvers cache negative answers according to values published in the zone’s SOA record. Until that cache expires, some users may continue seeing the earlier result even though the authoritative data is correct.

Local controls can deliberately return NXDOMAIN. Security software, parental controls, corporate filtering, and some internet providers use DNS policies to block known malicious or restricted names. A resolver-specific failure therefore does not always indicate a problem with the domain’s authoritative configuration.

How to diagnose NXDOMAIN

Check the exact hostname first. Compare spelling, punctuation, and the expected domain suffix. Test the same name with a command-line tool such as dig or nslookup and record which resolver produced the answer.

Query the authoritative servers directly. If they also return NXDOMAIN, inspect the zone and confirm that the name exists. If the authoritative servers return the correct record while a recursive resolver does not, the likely causes are negative caching, resolver policy, or an inconsistent delegation.

Trace the delegation from the DNS root when necessary. Confirm that the registry points to the intended authoritative servers and that every listed server answers consistently. The RFC 8020 specification explains how resolvers can use a non-existence response to stop searching below a confirmed nonexistent name.

NXDOMAIN and DNS caching

Negative caching reduces unnecessary DNS traffic. Without it, resolvers would repeatedly ask authoritative servers for the same nonexistent name. The cache duration comes from the zone’s SOA settings and may be limited by resolver policy.

Administrators planning to create a previously nonexistent hostname should account for this delay. Lowering the negative cache value in advance can help, but changing it after resolvers have cached the old response does not clear those copies. Existing entries remain valid until their original cache period ends.

How to fix the error

Create the missing DNS record when the hostname should exist. Verify that the record is present on all authoritative servers, that the domain’s delegation is correct, and that the zone is valid. Keep the old service available during related DNS propagation when a migration is involved.

If only one network or resolver returns NXDOMAIN, test with another resolver and review local filtering. Flush the device cache only after confirming the authoritative data. Local cache clearing cannot change records stored by an internet provider or public resolver.

Monitor the exact hostname until recursive resolvers return the intended answer. Consistent responses from the authoritative layer establish that the configuration is fixed; remaining differences should disappear as negative caches expire.