NXDOMAIN is a DNS response code (RCODE 3) returned by an authoritative nameserver when the queried domain name does not exist in the DNS namespace at all. It is one of several distinct negative responses in DNS, each with different meanings and caching behaviour.
When a resolver asks an authoritative server for any record type under a name — say, the A record for typo.example.com — and no such name exists anywhere in that zone, the server returns RCODE 3 (NXDOMAIN). This tells the resolver definitively that the name does not exist, regardless of what record type was requested. It is not just that the A record is missing; the name itself is absent from the zone.
NXDOMAIN responses include an authority section containing the zone's SOA record. This SOA is what resolvers use to determine how long to cache the negative answer.
These two negative outcomes are frequently confused but are meaningfully different:
Both responses include the SOA record in the authority section and are negatively cached by resolvers. Applications that distinguish between "name does not exist" and "record type does not exist" need to check the RCODE, not just whether the answer section is empty.
Resolvers cache NXDOMAIN responses to avoid querying authoritative servers repeatedly for the same nonexistent name. The caching duration is taken from the Minimum TTL field of the SOA record included in the negative response, capped by the SOA record's own TTL.
This has an important practical consequence: if you query for a name that does not yet exist and receive an NXDOMAIN, then add that name to DNS, resolvers that cached the NXDOMAIN will continue returning the negative answer until their cached entry expires. There is no way to actively invalidate a cached NXDOMAIN — you must wait for the negative TTL to elapse.
Some ISPs and recursive resolver operators intercept NXDOMAIN responses and replace them with synthetic answers pointing to search portals or advertising pages. From the client's perspective, a query for a nonexistent name returns an IP address instead of NXDOMAIN. This practice — sometimes called NXDOMAIN hijacking or DNS hijacking — breaks applications that rely on receiving a genuine NXDOMAIN to detect mistyped names or probe for nonexistent hosts.
DNSSEC validation does not directly prevent NXDOMAIN hijacking by the resolver itself, since the hijacking happens at the resolver level. Using an encrypted resolver (DNS-over-HTTPS or DNS-over-TLS) to a trusted provider eliminates ISP-level hijacking but shifts trust to that provider.
Check how a domain name resolves with the DNS tool
Open DNS Lookup