DNS Tools
DNS GUIDE

Troubleshoot NXDOMAIN, SERVFAIL and DNS timeouts

DNS errors sound alike but point to very different problems. This guide separates a name that does not exist from a server that could not answer, and gives a method for finding the cause.

Five outcomes that are easy to confuse

Every DNS query ends in a response code or in no response. The distinction between them is the most useful thing to know when something does not resolve, because they implicate different parts of the system. Treating all of them as 'the record is missing' sends people to edit records that were never the problem.

  • NXDOMAIN: the name does not exist, according to an authoritative source. Nothing at or below that name exists.
  • NODATA: the name exists, but there is no record of the requested type. The response is a normal answer with no records in it. A host with only an A record gives NODATA for AAAA.
  • SERVFAIL: the server tried and could not complete the lookup. This is a failure and not an absent record. Causes include unreachable or lame authoritative servers, a broken delegation, and DNSSEC validation failure.
  • REFUSED: the server declined to answer, usually by policy, for example an authoritative server that does not answer queries for a zone it does not host, or a resolver that does not serve your network.
  • Timeout: no answer arrived in time. Nothing at all is known about the record. It may be a dead server, a blocked path, packet loss or an overloaded server.

NXDOMAIN: what to check

  • Spelling and the label: a missing or extra label, a typo, or a name that was never created.
  • The right zone: the record was added in a zone that is not the one the registrar delegates to. The NS Lookup shows the real delegation.
  • Domain expiry or deletion: the parent no longer delegates the domain, so the whole zone vanishes. The NS tool reports no delegation at the parent as a risk.
  • Negative caching: the name was queried before it was created, and resolvers remember the NXDOMAIN for the negative-caching time in the SOA. Check with SOA Lookup and see DNS propagation explained.
  • Filtering resolvers: some resolvers return NXDOMAIN to block a domain, while the authoritative servers answer normally. Comparing resolvers exposes this.

NODATA: what to check

NODATA is often correct. A name can legitimately lack AAAA, MX or TXT. When it is not correct, the record type was entered at the wrong name (an SPF record on a subdomain, a DMARC record on the bare domain), or there is a CNAME elsewhere in the chain that changes where the lookup ends. The CNAME Lookup follows the chain, and the TXT Lookup shows what is actually at a name.

SERVFAIL: working out the layer

  1. Ask more than one resolver. If all fail, the cause is likely in the zone or its delegation. If only some fail, look at DNSSEC validation or resolver policy.
  2. Check delegation with the NS Lookup: does the parent list servers, do they answer authoritatively, are any lame, are any in one network?
  3. Check whether the authoritative servers agree with each other with the SOA Lookup serial comparison; a secondary with a missing or broken copy returns errors.
  4. Run the DNSSEC Checker. A DS at the parent with no matching key, or expired signatures, produces SERVFAIL at validating resolvers while non-validating ones answer.
  5. Compare resolvers with the DNS Resolver Comparison. SERVFAIL from validating resolvers and answers from others is the typical DNSSEC pattern.
  6. Look for a CNAME chain that ends at a server that fails or loops, using the CNAME tool.

REFUSED and timeouts

REFUSED from an authoritative server usually means that server is not configured for the zone, which is a lame delegation, or that it restricts who may query. REFUSED from a resolver means it will not serve you. A timeout is the least informative result. Retry once to rule out packet loss, test another resolver, and test the authoritative servers directly. If only one server times out, the remaining servers keep the zone available, but you have lost redundancy. If all time out, check for a provider outage or a firewall that drops UDP or TCP on port 53; large answers, such as big TXT sets or DNSSEC responses, need TCP, and a network that blocks it causes intermittent failures that look random.

Why the distinction protects you

A lookup tool that reports 'no record' when a server timed out is making a claim it cannot support. The DNS tools on this site report the state of every query, and a failed query is described as 'nothing is known', not 'absent'. When you read any DNS checker, look for whether it separates NXDOMAIN and NODATA from SERVFAIL, REFUSED and timeouts; if it does not, treat its negative results with caution.

Safe changes after diagnosis

Once you know the layer, change one thing at a time and keep the old value. For delegation faults, restore the working delegation before anything else. For a bogus DNSSEC chain, remove the DS at the registrar only as a controlled step, with the TTL wait in mind. For a missing record, add it and then wait for the negative-caching time. Record each change so you can roll back. The DNS change checklist covers the discipline in more detail.

Where to read more

DNS record types explained describes each record, and DNSSEC explained covers the chain of trust behind most SERVFAIL surprises. The DNS Tools page lists every diagnostic.

Written by DNS Tools editorial · Last updated 2026-10-09