NXDOMAIN (DNS RCODE 3): Why the Name Does Not Exist and How to Fix It

NXDOMAIN is the common name for DNS response code 3. RFC 1035 calls it Name Error: «Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist.» dig prints it in the header line:

$ dig nope.example.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4711
;; AUTHORITY SECTION:
example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. ...

It is a statement about the name, not about one record type. If the name exists but has no record of the type you asked for (say, an AAAA query for a host with only an A record), the answer is NOERROR with an empty answer section, the pseudo-code that RFC 2308 calls NODATA. Treating the two the same leads to the wrong fix: NXDOMAIN means create the name or fix the delegation; NODATA means add the missing record type.

Browsers turn NXDOMAIN into their own codes: Chrome shows DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED, Node.js throws getaddrinfo ENOTFOUND, and curl exits with code 6, «Could not resolve host».

A domain on hold is easy to miss: RFC 5731 requires that for clientHold and serverHold «DNS delegation information MUST NOT be published», so the TLD answers NXDOMAIN for every name under the domain while your own nameservers still hold a perfect zone.

Resolvers cache NXDOMAIN like any other answer. Per RFC 2308, the authoritative server includes the zone's SOA record, and the negative TTL is «the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself». If you queried a name before creating it, resolvers that saw the NXDOMAIN keep returning it until that TTL runs out, even though your zone is now correct.

RFC 8020 goes further: a resolver that caches NXDOMAIN for a name SHOULD treat all names below it as non-existent too. Querying example.com during a registrar outage can therefore make www.example.com and api.example.com fail as well. Read the negative TTL from the SOA:

dig +noall +answer SOA example.com
# example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. 2026102001 7200 3600 1209600 300
#                                                    the last number (MINIMUM) is 300 seconds

1. Ask an authoritative server directly, bypassing every cache:

   dig +short NS example.com
   dig @ns1.example.com www.example.com A +norecurse

   If it answers, the zone is right and you are looking at a cache or the wrong provider.
2. Follow the delegation from the root:

   dig +trace www.example.com

   The step that returns NXDOMAIN tells you which layer is wrong: the TLD (domain not delegated, expired or on hold) or your own nameservers (record missing).
3. Compare nameservers at the registrar and the TLD. The NS records in dig +trace at the TLD step must match the provider where you edit the zone (checking DNS records).
4. Check registration status: whois example.com | grep -i status. A clientHold or serverHold status removes the domain from DNS until the registrar lifts it.
5. Create the record under the exact name. In many DNS panels the zone name is appended automatically, so entering www.example.com in the name field creates www.example.com.example.com.
6. Clear caches you control. On systemd-resolved: resolvectl flush-caches; on macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Public resolvers expire the entry when the negative TTL runs out.

dig www.example.com @1.1.1.1 +noall +comments | grep status
# status: NOERROR
dig +short www.example.com @8.8.8.8
# 203.0.113.10

Check at least two public resolvers: one may still serve the cached NXDOMAIN. The DNS lookup queries the name in public DNS and lists every record it returns.

• SERVFAIL — the resolver could not get an answer at all
• DNS_PROBE_FINISHED_NXDOMAIN — NXDOMAIN as Chrome shows it
• getaddrinfo ENOTFOUND — NXDOMAIN or NODATA in Node.js
• Cloudflare error 1016 — the origin host name does not resolve
• TTL — how long answers, including negative ones, are cached