An A–Z list of the errors you meet when DNS breaks. Three kinds of entries sit side by side: response codes (RCODE) that every DNS answer carries, Extended DNS Errors (EDE, RFC 8914) that modern resolvers add to explain a failure, and the messages that browsers, operating systems and command-line tools print instead. Each entry says what it means, the usual cause and what to check next.
To see the raw code, query directly: dig example.com prints status: NXDOMAIN in the header and, if the resolver sends one, an EDE: line in the OPT pseudosection. The DNS Lookup tool shows the same status. For the three most common codes in depth, read NXDOMAIN, SERVFAIL, REFUSED: what your DNS error actually means.
No entry matches.
The server rejected the DNS Cookie (RFC 7873) the client sent, usually because the server secret rotated or an anycast node doesn't share it. Clients retry with the fresh cookie the server returned, so a single BADCOOKIE is harmless. Repeated failures point to anycast nodes with different cookie secrets or a middlebox rewriting the OPT record.
TSIG failures on signed messages, typically zone transfers, NOTIFY or dynamic updates between servers. BADSIG: the signature doesn't verify (wrong secret). BADKEY: the key name or algorithm is unknown to the other side. BADTIME: the clocks differ by more than the allowed fudge (300 seconds by default). Compare key name, algorithm and secret on both servers byte for byte, and check NTP.
The server doesn't support the EDNS version in the query. Every deployed client uses EDNS version 0, so seeing BADVERS usually means a broken server or middlebox rather than a real version mismatch. Test with dig +edns=0 example.com @server; if that also fails, the server's EDNS handling is faulty.
The resolver's operator refused to resolve the name because it's on a blocklist: malware, phishing or ads filtering on resolvers such as Quad9, AdGuard or a corporate DNS firewall. The answer is often NXDOMAIN or a sinkhole address. Check the domain's reputation, then ask the resolver operator for removal if it's a false positive.
The resolver is returning a failure it cached earlier instead of trying again. Typical after a short outage of the authoritative servers: the problem is fixed but some resolvers still answer SERVFAIL for a few minutes. Confirm the authoritative servers answer now, then wait or flush the resolver's cache.
Printed by Windows nslookup at start-up, before your query. nslookup looks up the PTR record of its own DNS server's IP and that reverse name doesn't exist, typically for a router at 192.168.x.1. It's cosmetic: the query below still runs. To silence it, add a PTR record for the server's address in your local DNS.
The resolver withholds the answer because of an external requirement such as a court order or national blocking list, not the operator's own policy (that would be Blocked) or the user's choice (Filtered). Using another resolver usually returns the real answer, subject to local law.
dig got no answer at all from any server it tried (newer versions print communications error to … timed out). Not a DNS answer, a network failure: the server is down, UDP/TCP port 53 is blocked, or the address is wrong. Try dig @1.1.1.1 to rule out your local resolver, check the path with Traceroute and port 53 with Port Check.
curl: (6) Could not resolve host: example.com means the system resolver returned no address: NXDOMAIN, no A/AAAA record, or no reachable DNS server. Run dig example.com to see which. In containers, check /etc/resolv.conf inside the container; a host-only resolver such as 127.0.0.53 isn't reachable from there.
nslookup waited (2 seconds by default) and got no reply from the DNS server. A single timeout followed by an answer is just a slow or lossy path; repeated timeouts mean the server is unreachable, overloaded or blocked by a firewall. Try another server with nslookup example.com 1.1.1.1, and raise the wait with nslookup -timeout=10 to tell slow from dead.
Windows maps DNS response codes to error numbers: 9001 FORMAT_ERROR (FORMERR), 9002 SERVER_FAILURE (SERVFAIL), 9003 NAME_ERROR (NXDOMAIN), 9004 NOT_IMPLEMENTED (NOTIMP), 9005 REFUSED. 9501 DNS_INFO_NO_RECORDS is NODATA: the name exists but has no record of that type. Resolve-DnsName shows 9003 as "DNS name does not exist". Read the matching entry below; clear the local cache with ipconfig /flushdns.
Chrome couldn't reach the configured DNS server at all, as opposed to getting a negative answer. Usual causes: a DNS server address that no longer exists (old router, uninstalled VPN), a VPN or security product intercepting DNS, or a broken DNS-over-HTTPS setting. Check the adapter's DNS servers, disable VPN or filtering software to test, and run ipconfig /flushdns.
Chrome's DNS probe failed and it also found no working network connection. Look at connectivity first (Wi-Fi, cable, captive portal, router), not DNS settings. If other apps work, a firewall or VPN may be blocking Chrome specifically.
Chrome got an NXDOMAIN answer: the resolver says the name doesn't exist. Check the spelling first. Then, if it's your domain: is it registered and not expired or on clientHold (see WHOIS), do the nameservers at the registrar match the ones hosting the zone (DNS Lookup, type NS), and was the record created recently (negative caching, see NXDOMAIN)? Clear Chrome's own cache at chrome://net-internals/#dns.
The parent zone has a DS record, but no DNSKEY in the zone matches it, so the chain of trust breaks and validating resolvers return SERVFAIL. Classic causes: moving DNS providers without removing the old DS, or a key rollover that published the new DS before the new key. Compare DS at the parent with DNSKEY in the zone using the DNSSEC Checker; remove or update the DS at the registrar.
DNSSEC validation failed: signatures exist but don't verify against the chain of trust. Validating resolvers (Google, Cloudflare, Quad9, most ISPs) return SERVFAIL, while non-validating ones still answer, so the domain works on some networks and not others. Look for the more specific EDE (Signature Expired, DNSKEY Missing, RRSIGs Missing) and run the DNSSEC Checker.
The resolver couldn't decide whether the answer is secure, insecure or bogus, for example because it couldn't fetch a DNSKEY or DS it needed. Often a side effect of an unreachable or slow authoritative server rather than a signing mistake. Check that every nameserver answers DNSKEY queries, including over TCP for large responses.
"DSO-TYPE not implemented": a reply to a DNS Stateful Operations request (RFC 8490, used over long-lived TCP/TLS sessions) whose type the server doesn't know. You won't meet it in ordinary lookups; it only matters when building DSO-based software such as DNS push notifications.
The browser couldn't turn the host name into an IP address. It's the generic form of the DNS_PROBE_FINISHED_* errors: the name doesn't exist, has no A/AAAA record, or the resolver failed. Check the name with DNS Lookup; if it resolves there but not in the browser, flush the OS cache and chrome://net-internals/#dns, and check the browser's Secure DNS setting.
The name was filtered because the client asked for filtering: a family-safe or ad-blocking resolver profile chosen by the user or network admin (for example CleanBrowsing family filter, NextDNS profiles). Switch profile or resolver if the block is wrong.
The resolver deliberately returned an answer different from the real one, by policy: a sinkhole address for a malware domain, a walled-garden page or a captive portal. If you see it for a name that should be normal, compare with another resolver and ask the operator why the name is rewritten.
"Format error": the server couldn't parse the query. Today it almost always means broken EDNS handling: an old server, load balancer or firewall that chokes on the OPT record, an unknown EDNS option or a large UDP size. Since DNS Flag Day 2019, major resolvers no longer retry without EDNS, so such domains just fail. Test the authoritative server with dig +norec example.com @ns1.example.com and again with +noedns; if only the EDNS query fails, upgrade or reconfigure the server or middlebox.
Node's dns.lookup() (used by http, fetch and most clients) calls the system resolver. ENOTFOUND = the name doesn't resolve: NXDOMAIN or no A/AAAA record. EAI_AGAIN = temporary failure: the DNS server timed out or returned SERVFAIL; retrying may work. In Docker or Kubernetes, check the container's /etc/resolv.conf and cluster DNS before the domain itself.
The authoritative server returned data the resolver considers invalid or unusable, for example a malformed record or an answer that contradicts the delegation. Query each nameserver directly and compare: one server serving a broken copy of the zone is the usual cause.
The Linux C library's text for EAI_NONAME, printed by ping, ssh, wget and others: the name has no address. Either NXDOMAIN, no A/AAAA record, or the name isn't in /etc/hosts and no DNS is configured. Check with getent hosts example.com (uses the same path as applications) and dig example.com (DNS only); a difference points at /etc/nsswitch.conf or /etc/hosts.
The resolver hit an unrecoverable network error while talking to another server, such as ICMP unreachable or a refused TCP connection. Points at routing or a firewall in front of the nameserver. Check the path to each nameserver IP with Traceroute.
The resolver couldn't get a usable answer from any authoritative server for the zone: all timed out, refused or were unreachable. The answer to you is SERVFAIL. Check that every NS listed at the parent answers for the zone (lame delegation after a provider move is common), that UDP and TCP 53 are open, and that the servers aren't rate-limiting the resolver.
A DNSKEY referenced by the DS record doesn't have the Zone Key flag set (flags 256 or 257 have it; 0 doesn't), so it can't validate the zone. Usually a hand-built or tool-converted key with wrong flags. Regenerate the key with your DNS software and publish a matching DS.
Not a separate code: status is NOERROR but the answer section is empty. The name exists, just not with the record type you asked for, for example a domain with an A record but no MX. Very different from NXDOMAIN (name doesn't exist at all). Common in mail debugging: a missing MX makes senders fall back to the A record. Check each type with DNS Lookup.
The query succeeded. That doesn't mean you got a record: check the answer section, because an empty one is NODATA. If NOERROR comes with the wrong data, look at caching (DNS Propagation) or at which nameserver answered.
Windows nslookup's wording for NXDOMAIN: *** dns.server can't find example.com: Non-existent domain. Same meaning and same checks as NXDOMAIN. If it appears only at start-up, before your query, see "Can't find server name for address".
The server you asked isn't authoritative for the zone and doesn't offer recursion, so it can't answer. Usually you queried an authoritative-only server for someone else's domain, or the parent delegates to a server that no longer hosts the zone (lame delegation). Point clients at a recursive resolver, or fix the NS records.
The server isn't ready to answer yet: it's still starting, loading zones or priming its cache. Should clear within seconds to minutes. If it persists, check the server's logs for a zone that fails to load.
The server doesn't support the requested operation or query type, for example ANY on servers that restrict it (RFC 8482), or a transfer or update request on a server that doesn't allow it. Use the specific record type instead of ANY.
Two meanings depending on context. In dynamic DNS UPDATE (RFC 2136): the server isn't authoritative for the zone named in the update, so send it to the primary. With TSIG (RFC 8945): the request isn't authorized, usually a missing or wrong TSIG key on a zone transfer or update. Check allow-transfer / allow-update and the key on both sides.
"Not implemented": the server doesn't support the kind of request (opcode), for example NOTIFY, UPDATE or IXFR sent to a server or appliance that only answers plain queries. Occasionally returned by broken middleboxes for EDNS queries. Check what the request type was and whether that server should handle it.
In dynamic UPDATE: a name in the update isn't inside the zone being updated. Usually the client sent records for host.other.example to the zone example.com. Fix the zone or record names in the update.
The response claims a name or type doesn't exist but carries no NSEC/NSEC3 proof, so a validating resolver can't trust the denial. Usually a signer or server that strips NSEC records, or a partially signed zone. Re-sign the zone and check with the DNSSEC Checker.
"Non-existent domain": an authoritative server said the name doesn't exist. For your own domain, check: the record was really published in the zone that's being served; the name is spelled exactly (no doubled www.www); the NS at the registrar match your DNS host; the domain isn't expired or on hold (WHOIS). A just-created name can stay NXDOMAIN in caches for the SOA minimum TTL (negative caching). Full walkthrough: NXDOMAIN, SERVFAIL, REFUSED guide.
In dynamic UPDATE: a prerequisite said "this record set must exist", and it doesn't. The update is rejected as a whole. Common with ACME/Let's Encrypt DNS clients or DHCP-driven updates that expect an old record to be present. Check the current zone content before the update.
A catch-all: the resolver has an explanation that doesn't fit any defined code and puts it in the free-text part of the EDE, for example EDE: 0 (Other): (…) in dig output. Read that text; it usually names the actual problem.
The resolver refuses to serve you: your address isn't on its access list. Typical when using a company or ISP resolver from outside its network, or a resolver that only serves its own customers. Use the resolver your network assigns, or a public one.
The server understood the query and declined to answer by policy. Asked a recursive resolver: you're not on its allowed client list. Asked an authoritative server: it doesn't host that zone (often a leftover NS record after a provider change) or refuses the request type, such as a zone transfer. Make sure every NS at the registrar actually serves the zone: query each one with dig +norec example.com @nsX. More: NXDOMAIN, SERVFAIL, REFUSED guide.
The zone is signed (DS at the parent, DNSKEY present) but the answer came without signatures, so validation fails. Typical causes: a secondary nameserver serving an unsigned copy of the zone, or a load balancer or DNS proxy that strips RRSIG records. Query each NS with dig +dnssec and compare.
nslookup's report of a failed lookup, followed by the reason: ** server can't find example.com: NXDOMAIN (name doesn't exist), : SERVFAIL (resolver failed), : REFUSED (server declined), : NXDOMAIN for an IP is a missing PTR record. Read the matching entry. On Windows the NXDOMAIN wording is "Non-existent domain".
The resolver tried and couldn't produce an answer. It's not a statement that the name doesn't exist. The usual causes, in order: DNSSEC validation failure (works on non-validating networks, fails on Google/Cloudflare/Quad9; check the DNSSEC Checker), no nameserver answering, lame delegation, or an expired zone on a secondary. Look for an EDE code next to it; it often names the cause. Then query the authoritative servers directly. Full walkthrough: NXDOMAIN, SERVFAIL, REFUSED guide.
The RRSIG's expiration time has passed. Signatures are re-made periodically by the signer; if signing stopped (cron job, service, or a provider's automation failed), the zone keeps working for days and then fails everywhere validation is on. Re-sign the zone and fix the automation; check expiry dates with the DNSSEC Checker.
The RRSIG's inception time is in the future from the resolver's point of view. Usually the signing server's clock is ahead, or the resolver's clock is behind. Check NTP on the signer; signers normally backdate inception by an hour to absorb small skew.
The resolver couldn't refresh the record from the authoritative servers, so it served an expired copy from cache (serve-stale, RFC 8767). You got an answer, but the authoritative side is having trouble. Check that the nameservers respond before the stale window runs out, typically one to three days.
Like Stale Answer, but the cached item was a negative answer: the resolver couldn't reach the authoritative servers and repeated an expired NXDOMAIN. If you just created the name, the real fix is on the authoritative side; the resolver can't see your new record until it can reach the servers.
The Linux C library's text for EAI_AGAIN: the resolver didn't give a definite answer. The DNS server timed out, returned SERVFAIL, or none is configured. Not the same as "Name or service not known" (definite no). Check /etc/resolv.conf; with systemd-resolved, run resolvectl status and resolvectl query example.com. On servers it's often a firewall blocking outbound port 53 or a DNS server that's down.
Defined for DNS over QUIC (RFC 9250): the server won't process a query sent in 0-RTT early data, because early data can be replayed. The client should resend after the handshake completes. Only relevant if you build or operate DoQ software.
The UDP answer had the TC (truncated) flag set because it didn't fit, so dig repeated the query over TCP. Normal for large answers: DNSSEC keys, long TXT/SPF records, many A records. A problem only if the TCP retry then fails: TCP port 53 must be open to every authoritative server (RFC 7766). Test with dig +tcp example.com @ns1.example.com.
The zone is signed with an algorithm the resolver doesn't support or has disabled, so it treats the zone as unsigned (no protection, but the answer is still served). Seen with RSA/MD5, DSA, and increasingly RSA/SHA-1 (algorithms 5 and 7), which are being phased out for signing. Re-sign with ECDSA P-256 (13) or Ed25519 (15); NODA flags banned algorithms.
The DS record at the parent uses a digest type the resolver doesn't support, typically SHA-1 (type 1) or GOST (type 3). If no other DS is usable, the zone is treated as unsigned. Publish a DS with SHA-256 (type 2) at the registrar and remove the old one.
The zone's NSEC3 parameters use more hash iterations than the resolver accepts (RFC 9276). Depending on the resolver, the zone is treated as insecure or answers become SERVFAIL. Set NSEC3 iterations to 0 and use an empty salt, as RFC 9276 recommends; check the current value with dig NSEC3PARAM example.com.
You asked a server that doesn't do recursion, usually an authoritative nameserver. Harmless if you meant to query it directly, and the answer for its own zones is fine. If you expected a full answer for any domain, you're pointing at the wrong server: use a recursive resolver. Add +norec to silence the warning.
"Name exists when it should not." In dynamic UPDATE, a prerequisite required a name to be absent and it's present. Also returned when a DNAME substitution would create a name longer than 255 bytes (RFC 6672). For updates, check the zone's current state; for DNAME, shorten the target.
In dynamic UPDATE: a prerequisite required a record set not to exist, and it does. The whole update is rejected. Common when two clients race to create the same record. Read the current record first, then update.
Sources: RFC 1035 (RCODE 0–5), RFC 2136 (6–10), RFC 8490 (11), RFC 6891 and RFC 8945 (16–22), RFC 7873 (23), RFC 8914 (EDE 0–24), RFC 9250 (EDE 26), RFC 9276 (EDE 27), IANA DNS Parameters registry. Check a whole domain at once with NODA.
