DNS Error Codes: A Guide from NXDOMAIN to REFUSED

You've opened the terminal, run dig, and instead of an A record, a three-letter code came back. In that moment two questions fill your mind: what exactly does this code mean, and is the problem on my server or somewhere else? A DNS error code is actually the resolver's official response, not a vague message. If you know which layer each code comes from, you'll find the direction of your investigation in seconds.

Where DNS error codes come from

Every DNS response has a four-bit field called RCODE. A value of zero means NOERROR, and any other value means something along the way didn't go right. This code can be produced by the authoritative server, by an intermediate resolver, and in some cases by your own local resolver. This is the key point: a DNS error code doesn't always come from the server that owns the domain.

To see the raw code, use the dig options:

dig +noall +comments example.com A
dig +short example.com A
dig @1.1.1.1 example.com A +norecurse

The status: line in the comments section is the RCODE. If you use +norecurse, the resolver won't serve the answer from its cache, and you'll see behavior closer to authoritative. To check a domain's DNS records from multiple points, the online DNS record lookup tool is faster than going back and forth in the terminal.

NXDOMAIN: the name doesn't exist

This code means the authoritative server definitively says that no such name is defined in this zone. Note carefully: NXDOMAIN is about the name, not the record type. If mail.example.com exists but has no AAAA record, the response isn't NXDOMAIN; it's NOERROR with an empty answer section.

Three common causes:

• You created the record in the wrong zone, for example under www.example.com.example.com instead of www.
• The domain points to a different nameserver and you're editing in the wrong panel.
• You deleted the record and the old TTL is still alive in resolver caches.

Here's where people go wrong: the user sees NXDOMAIN, immediately creates a new record, and a few hours later has two conflicting records in the zone. The sign is that responses alternate between two different IPs, and some users see the site while others don't. Before making any change, first confirm with dig NS example.com which nameserver is authoritative.

SERVFAIL: the resolver couldn't complete the answer

SERVFAIL is the most ambiguous DNS error code, because it doesn't state the cause. The resolver tried and didn't reach a result. In practice, four causes account for most cases:

1. DNSSEC is broken. The signature has expired, or the DS record at the parent doesn't match the zone key.
2. The authoritative server doesn't respond on port 53 from your IP, or it times out.
3. The zone is loaded with different content on two nameservers, and the resolver gets conflicting answers.
4. The intermediate resolver has hit its rate limit.

To separate these cases, query the authoritative server directly:

dig @ns1.example.com example.com A +dnssec
dig +trace example.com

If the direct answer is healthy but you get SERVFAIL from a public resolver, the problem is almost certainly DNSSEC or a nameserver mismatch. If both give SERVFAIL, look into port 53 reachability. The exact order of these checks is covered in the practical DNS troubleshooting guide.

REFUSED, NOTAUTH, and the rest of the codes

REFUSED means the server isn't answering because it isn't allowed to, not because it doesn't know. The most common scenario: the resolver is open and the admin has blocked queries from external networks with an ACL. If dig @server against your own server gives REFUSED but you get an answer from inside the network, it's not a DNS problem; it's an access policy.

NOTAUTH means the server you asked isn't authoritative for this zone at all. You see this when you've entered another server's IP as the nameserver. FORMERR means the query message is structurally malformed and almost always comes down to a software bug or a meddling middlebox. NOTIMP means the server hasn't implemented that query type; it's seen a lot on old servers with SVCB or HTTPS type queries.

Don't confuse a DNS error code with TTL

The biggest misunderstanding is that users mix up NXDOMAIN with "not propagated yet." NXDOMAIN is a definitive answer, not a delay. If you just created the record and still see NXDOMAIN, the old TTL is probably still in the cache. Look at the TTL value:

dig example.com A +noall +answer
example.com.  3600  IN  A  203.0.113.10

The number 3600 means resolvers are allowed to keep the old answer for up to an hour. For high-risk changes, lower the TTL to 300 seconds in advance, apply the change, and raise it again once things settle. There's a cost here that's rarely mentioned: a short TTL multiplies the query load on the authoritative server and, on high-traffic domains, can itself be a source of SERVFAIL. The details of this cycle are explained in the TTL and DNS caching guide.

The right order of investigation

When you get a DNS error code, follow this order and avoid shortcuts:

1. Use dig NS to see which nameservers are actually in place.
2. Query that same nameserver directly and look at the RCODE.
3. If the direct query is healthy, move on to DNSSEC and the resolver cache.
4. If the direct query errors, check the zone and record in the DNS panel.

For .ir domains there's an extra layer: if IRNIC or domestic nameservers are involved, the answer may be correct from outside and incorrect from inside. Investigate this case separately, because the error pattern differs from the normal one.

If you've just registered the domain and it isn't connected to any server yet, first complete the domain search and registration and record setup, then move on to troubleshooting. For projects where DNS and the web server are combined on one machine, a Linux host with full access to the zone file makes things easier, since you can directly observe your own server's behavior with dig @127.0.0.1.

Frequently asked questions

What's the difference between NXDOMAIN and SERVFAIL?

NXDOMAIN is a definitive answer: the name doesn't exist in the zone. SERVFAIL means the resolver couldn't reach an answer and doesn't state the cause. If you get NXDOMAIN, check the record or the zone; if you get SERVFAIL, first check DNSSEC and port 53 reachability.

Why does one resolver answer and another give NXDOMAIN?

It almost always means the domain's nameservers aren't in sync, or one of them hasn't loaded the zone. Test both separately with dig @ns1 and dig @ns2. If the answers differ, it's not a propagation problem, it's a zone mismatch.

Does a REFUSED code mean my DNS has been hacked?

No. REFUSED usually means the server is correctly blocking queries from unauthorized networks. If you have an open resolver, this code is a sign of a properly configured ACL, not a breach. The opposite is what's worrying: a resolver that answers everyone and gets used in reflection attacks.

How long does it take for a DNS error code to clear after changing a record?

It depends on the record's previous TTL, not on the panel's speed. If the TTL was 3600, some users may see the old answer for up to an hour. For sensitive changes, lower the TTL in advance and restore it once things settle.

Keep one rule in mind: read the DNS error code from the primary source, not from the cache. Until you've queried the authoritative server directly, any result you see could belong to a layer that isn't under your control.