NXDOMAIN vs SERVFAIL: what each DNS error means.

Published 2026-09-15 · 5 min read · Kirk Diamond

The short version

NXDOMAIN: the name does not exist

NXDOMAIN (rcode 3) comes from the servers that are authoritative for the zone. They have looked, and there is no such name. Because it is authoritative, resolvers cache it, for as long as the SOA record's minimum TTL says (this is "negative caching"). That is the sting: create the missing record and a resolver that already asked will keep saying NXDOMAIN until its negative cache entry expires, which on many zones is an hour or more.

Common causes, in the order I meet them:

• A typo in the name you are querying, or in the record that was created (ww instead of www).
• The record was created in the wrong zone. If app.example.com is delegated to its own nameservers, adding it in the parent example.com zone does nothing.
• The record was never created. Deploy pipelines that provision a load balancer but rely on a human to add the DNS entry produce this every week.
• A CNAME points at a target that does not exist, so the target returns NXDOMAIN and the whole chain fails.
• The zone itself is gone: the domain expired, or the registrar's nameservers were changed and the new provider has no zone yet. In that case every name under it is NXDOMAIN.

The response will usually include the zone's SOA record in the authority section. The DNS lookup tool shows this as "No answer. The authority section says", which tells you which zone answered and therefore where the record needs to go.

SERVFAIL: the resolver gave up

SERVFAIL (rcode 2) is generated by the recursive resolver (your ISP's, Cloudflare's, the one in your office router) when it cannot complete the lookup. The authoritative servers may be fine. The name may exist. The resolver simply did not get an answer it could return. Causes:

• DNSSEC validation failed. The zone is signed, the signatures are wrong or expired, or the DS record at the parent does not match the zone's key. Validating resolvers (Cloudflare, Google, Quad9, most ISPs now) return SERVFAIL rather than serve data they cannot trust. This is the single most common SERVFAIL cause on well-run domains, and it usually happens after a DNS provider migration when the old DS record is left in place at the registrar.
• Authoritative servers unreachable. They are down, firewalled, or the NS records point at hosts that no longer run DNS.
• Lame delegation. The NS records name a server that answers but is not configured for the zone, so it refuses (REFUSED) and the resolver treats that as failure.
• Broken CNAME chain that the resolver cannot follow within its limits, or a loop.
• Timeouts under load, or an authoritative server that drops EDNS or TCP queries so large responses never arrive.

How to tell them apart in practice

Ask more than one resolver. If Cloudflare, Google and Quad9 all say NXDOMAIN, the name does not exist and there is nothing to debug on the resolver side. If one resolver says SERVFAIL and another returns an answer, the failing one is most likely validating DNSSEC and the working one is not (or has a cached answer from before the break). If all of them say SERVFAIL, the authoritative side is broken for everyone.

Then go to the source. Look up the NS records for the zone and query one of those servers directly by entering its IP as the resolver. An authoritative server never returns SERVFAIL for DNSSEC reasons (it does not validate), so if it answers correctly and public resolvers do not, you have a DNSSEC problem. Check the DS record at the parent against the DNSKEY in the zone.

dig +dnssec example.com A @1.1.1.1      # SERVFAIL?
dig +cd example.com A @1.1.1.1          # +cd disables validation; an answer here confirms DNSSEC
dig example.com DS @a.gtld-servers.net  # what the parent says the key should be
dig example.com DNSKEY @ns1.example.com # what the zone actually has

Fixing each one

NXDOMAIN: create the record in the right zone, then wait out the negative cache or ask the resolver operator to flush (Cloudflare and Google both have public purge pages). Lower the SOA minimum TTL before a launch if you expect to be creating records at the last minute.

SERVFAIL from DNSSEC: either fix the signatures (re-sign the zone, publish the right DNSKEY) or, if you have moved provider and the new one does not sign, remove the DS record at the registrar. Removing DS is the fast fix; it takes effect when the parent's TTL on the DS record expires, typically a day for TLDs.

SERVFAIL from unreachable servers: check the NS records point at hosts that answer on UDP and TCP port 53 from the public internet, and that each one is actually configured for the zone.

The other codes you will see

• NOERROR with an empty answer: the name exists but not with that record type. Asking for AAAA on an IPv4-only host does this. Not an error.
• REFUSED: the server will not answer you. Querying an authoritative-only server for a name it does not host, or a resolver that is not open to your address.
• FORMERR: malformed query. Usually an EDNS incompatibility with an old server.