Run test

SERVFAIL

A standard DNS response code meaning the resolver could not complete your query — which, unlike most DNS errors, is sometimes exactly what should happen. Run the check below to see whether your resolver validates DNSSEC before assuming anything is broken.

Updated 6 min read

Checking your DNS from this browser…

Runs in your browser against public resolvers. No IP address is stored — just the day, the network operator you're connected through, a country code, and the results above, to build a picture of DNS behaviour per network. Privacy policy.

What SERVFAIL means

SERVFAIL is one of DNS's standard response codes, distinct from NXDOMAIN in a way that matters: NXDOMAIN says "I looked, and this name definitively does not exist." SERVFAIL says "I could not give you an answer I'm willing to stand behind." The underlying causes are almost entirely different — an authoritative server timing out or being misconfigured, a problem on the resolver's own side, or, the reason this page exists, a broken DNSSEC signature that a security-conscious resolver refuses to pass along.

The check above tests that last path directly: it loads a domain with a deliberately broken DNSSEC signature through your resolver and watches whether the lookup goes through or gets blocked. It does not identify which resolver you're using and does not measure how long it took to fail — only whether validation happened.

The counter-intuitive part: SERVFAIL can mean your resolver is doing its job

DNSSEC works by chaining cryptographic signatures from the root down through each zone. A resolver that validates checks that chain on every lookup, and if it's broken — an expired signature, a DS record at the registrar that no longer matches the zone's live keys, a misconfigured rollover — the only correct move for that resolver is to refuse the answer rather than hand you something it can't vouch for. That refusal is what you see as SERVFAIL.

If that's what happened, the SERVFAIL isn't a symptom of your resolver being broken — it's your resolver refusing to serve a result it cannot verify is genuine, which is the exact protection DNSSEC exists to provide. The fault sits with whoever runs the domain's DNS, not with your setup, and no configuration change on your end produces a "working" result without also giving up that protection. Switching to a resolver that doesn't validate DNSSEC will make the red error disappear — by silently accepting whatever answer arrives, verified or not. That isn't a fix; it's turning off a safety check because it told you about a problem.

  • A DNSSEC validation failure. Your resolver working correctly, refusing a signature it can't verify.
  • An authoritative server timeout or misconfiguration. The domain's own DNS servers not answering the resolver's query at all.
  • A resolver-side outage or bug. Rarer, and usually short-lived and widespread rather than tied to one domain.
  • A broken delegation. NS records for the zone pointing at servers that no longer exist or answer.

How to tell which one you've got

  1. See whether the check above found your resolver validating DNSSEC

    If it did, treat that as the likely explanation before anything else: this SERVFAIL is very probably your resolver correctly refusing a domain whose signature doesn't check out. The fix isn't on your device — it's whoever administers that domain's DNS needing to repair their signing chain.

  2. If it found your resolver not validating

    then the SERVFAIL isn't a DNSSEC story at all, which points the fault upstream at the domain's own authoritative servers — unreachable, overloaded, or misconfigured. Wait a few minutes and retry; if it keeps happening, this is one for the site's operator, not something changing your own DNS settings will touch.

  3. Confirm directly, rather than relying on the general read above

    The check on this page infers DNSSEC behaviour from a proxy domain built to fail. To see the specific domain's own signature status, run a dedicated DNSSEC lookup against it directly.

    Run a DNSSEC check

  4. If you administer the domain yourself

    check that the DS record published at your registrar matches the DNSKEY currently live in your zone. A mismatch there — usually left behind by a key rollover that didn't complete on both sides — is the single most common cause of a SERVFAIL that only affects validating resolvers.

    Look up the domain's records

SERVFAIL — frequently asked questions

What does SERVFAIL mean?

SERVFAIL (Server Failure) is a standard DNS response code meaning the resolver could not complete your query and give you a trustworthy answer. It's a different statement from NXDOMAIN, which says the name definitively doesn't exist — SERVFAIL says the resolver tried and failed, for reasons that can range from an unreachable authoritative server to, in the case this page is about, a DNSSEC signature it refused to trust.

Is SERVFAIL the same as NXDOMAIN?

No. NXDOMAIN is DNS confirming a name has no record anywhere — a completed, negative answer. SERVFAIL is DNS failing to produce any answer it's willing to stand behind, which is a very different kind of problem with a very different set of causes, including one, DNSSEC validation, where the resolver failing is arguably it doing exactly what it should.

If I switch my DNS resolver, will the error go away?

Often, yes — which is precisely the trap. A resolver that doesn't validate DNSSEC will simply pass through whatever answer it receives, verified or not, so switching to one can make a validating resolver's honest SERVFAIL disappear by silently removing the check that produced it. That isn't a fix; it's turning off a safety feature to stop it from telling you about a problem. It only makes sense to switch if the check above showed your resolver not validating DNSSEC at all — then the SERVFAIL was never a validation story, and a different resolver is a reasonable troubleshooting step for the actual cause.

Why would a working resolver refuse to give me an answer?

Because DNSSEC exists to let a resolver detect when a domain's records can't be verified as genuine — an expired signature, a broken chain of trust, or a misconfigured zone. A resolver that takes that verification seriously has exactly one correct response when it fails: refuse to hand you the unverifiable answer. That refusal is what shows up as SERVFAIL. It's the resolver protecting you, not malfunctioning.

What does the check on this page actually test, and what can't it tell me?

It loads a domain with a deliberately broken DNSSEC signature through your resolver and reads whether the lookup goes through (not validating) or gets blocked (validating), alongside the same known-good-domain and public-resolver checks used on every diagnostic on this site. It does not identify which resolver you're using, and it does not measure how long it took to fail — only whether validation happened.

Why does it come and go?

SERVFAIL is frequently tied to state that changes on its own: a signature nearing its expiry window, an authoritative server that's intermittently overloaded, or a key rollover in progress at the domain's registrar. None of those are things your own device controls, which is why the error can clear on its own just as it appeared on its own.