NXDOMAIN vs NODATA vs REFUSED

Where the response code lives

The RCODE is a 4-bit field in the DNS message header defined in RFC 1035, and EDNS extends it for newer codes. In dig output you see it as status: on the header line. The ones you will meet in day-to-day work are below.

Because the same code can have several causes, many resolvers now attach an Extended DNS Error (EDE) as defined in RFC 8914, Extended DNS Errors. Recent versions of dig print it in the OPT pseudo-section as a line such as EDE: 18 (Prohibited). When an EDE is present, read it first; it often names the exact reason.

NXDOMAIN: the name does not exist

An NXDOMAIN answer is a statement about the name itself, for every record type. If typo.example.com returns NXDOMAIN for an A query, it will also return NXDOMAIN for AAAA, MX and TXT. The authoritative server includes the zone's SOA record in the authority section so resolvers know how long to cache the negative answer.

$ dig typo.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50213
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.    300  IN  SOA  ns1.example.com. hostmaster.example.com. 2026101501 7200 900 1209600 300

Common causes are simple: a typo in the name, a record that was never created, a record created in the wrong zone, or a record that was deleted. A frequent zone-file mistake is a missing trailing dot. Writing www CNAME host.example.net inside the example.com zone actually points at host.example.net.example.com, so the CNAME resolves but its target returns NXDOMAIN.

RFC 8020, NXDOMAIN: There Really Is Nothing Underneath, also tells resolvers that an NXDOMAIN for a name means nothing exists below it. If b.example.com does not exist, neither does a.b.example.com. Wildcards change the picture: with a *.example.com record in place, most missing names return the wildcard's data instead of NXDOMAIN. Wildcard DNS Risks explains why that can hide mistakes.

NODATA: the name exists, the type does not

A NODATA response has NOERROR status and no requested-type RRset at the final name. It may contain CNAME answers; an SOA normally supports negative caching. It means "this name is real, but there is nothing of that type here".

$ dig www.example.com AAAA

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11873
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.    300  IN  SOA  ns1.example.com. hostmaster.example.com. 2026101501 7200 900 1209600 300

Typical cases:

• An IPv4-only host queried for AAAA. This is normal and expected.
• A TXT or MX query for a name that only has an A record.
• An empty non-terminal: a name like _domainkey.example.com that has no records of its own but exists because selector1._domainkey.example.com does. Every type returns NODATA rather than NXDOMAIN.
• A CNAME whose target exists but has no records of the requested type. The answer section then holds the CNAME and nothing else.

NODATA is easy to miss because many tools only print the answer section. In dig, always look at the status and the ANSWER count, or use +noall +comments +answer to keep the header visible.

REFUSED: the server will not answer

REFUSED is about the server's willingness, not the name's existence. It typically appears in three situations:

• An authoritative server asked about a zone it does not serve. If a delegation lists a server that no longer hosts the zone, that server may answer REFUSED. This is one form of lame delegation, covered in Lame Delegation and DNS Delegation and Glue Records.
• A recursive resolver that only serves certain clients. Corporate and ISP resolvers usually limit recursion to their own networks. Asking from outside returns REFUSED, which is the correct behavior: open resolvers get abused for amplification attacks.
• A denied operation. Zone transfer requests (AXFR) from unauthorized addresses, and dynamic updates without the right key, are commonly refused.

Ask an authoritative server about a zone it does not host:

$ dig +norecurse example.org SOA @ns1.example.com

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 30412
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

A resolver that gets REFUSED from one authoritative server does not treat it as an answer about the name. It tries the zone's other name servers, and if all of them refuse, the client usually sees SERVFAIL. So a REFUSED you see from your own tests is often the hidden cause behind a SERVFAIL your users report.

Comparing the outcomes

Negative caching is why fixing an NXDOMAIN does not always take effect immediately: resolvers that saw the old answer keep it for the negative TTL. Negative Caching and the SOA Minimum explains how that TTL is calculated.

A quick troubleshooting workflow

1. Query your usual resolver and note the status, answer count, and any EDE line.
2. Query the same name and type at each authoritative server with +norecurse. Check that the aa flag is set and the status matches.
3. If the authoritative servers answer correctly but your resolver does not, you are looking at a cached negative answer or resolver policy. Wait out the negative TTL or flush the resolver's cache.
4. If the authoritative servers return NXDOMAIN or NODATA, that is the zone's real answer. It may be correct: an IPv4-only host has no AAAA record, for example. If you expected a record, check the name and type you asked for, trailing dots, and which zone the record was added to.
5. If any authoritative server returns REFUSED or does not answer, fix the delegation or the server configuration.

How DNS Panopticon helps

Domain Visualizer resolves a domain's records live through two public DNS-over-HTTPS resolvers and reports several results that are NODATA in practice: an apex with no A or AAAA record, MX hosts that do not resolve to an address, and name server hostnames with no address, which it flags as a potentially lame delegation. When the two resolvers return different answers for the same name and type, it reports resolver variance. In Advanced mode it also probes a made-up hostname under the domain that should not exist, and if that resolves it reports that wildcard DNS is active, which means mistyped names will not return NXDOMAIN.

Zone Analyzer helps with the "is it really in the zone?" question. Load a zone export and filter by hostname to confirm whether a record exists and which zone it was placed in, or filter on the data column to find targets that accidentally end in your own zone name because of a missing trailing dot.