SERVFAIL after turning on DNSSEC: signed, broken, or off

Your domain returns SERVFAIL from public resolvers since DNSSEC went on, and it probably still resolves from your own desk. The DS record at your registrar promises a key your name servers aren’t serving, or the signatures they do serve have expired, so a validating resolver refuses the answer while a non-validating one hands it out as before. The records themselves are fine, and the fault sits in the proof of them, which you can correct or withdraw. The error code tells you which, and both repairs take minutes.

Read the error before you touch anything

Ask a validating resolver that returns Extended DNS Errors. 1.1.1.1 does, and so does 8.8.8.8, and the EDE line at the bottom is the diagnosis:

$ dig +dnssec yourdomain.example A @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40917
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for yourdomain.example.)

Code 9 means the parent holds a DS that matches no key in your zone. With code 7, a signature has expired. Code 10 tells you the parent holds a DS while your zone serves no signatures at all, and code 6 is the general “bogus” verdict a resolver gives when it can’t be more specific, so you’ll work through the same three checks to narrow it down.

Before that, confirm the records themselves are still there by asking the same resolver to skip validation:

$ dig +cd yourdomain.example A @1.1.1.1
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1
yourdomain.example.  300  IN  A  203.0.113.10

With +cd (checking disabled) the answer comes straight back, which proves your zone is being served and only the chain of trust is failing. Use +cd for diagnosis only. No browser or mail server sends it, so it shows you where the fault is without changing anything. The chain itself, DS to DNSKEY to RRSIG, is laid out on the DNS and DNSSEC page if the terms are new.

It works from your desk and nowhere else

An office or ISP resolver that doesn’t validate hands out your records whatever the chain says, so from inside the building the site loads and mail flows, and the first ticket reads as a customer problem. Anyone behind a validating resolver, which includes the large public resolvers and the big mail providers, gets nothing usable. From a laptop on the outside it looks like this:

$ curl -sI https://yourdomain.example
curl: (6) Could not resolve host: yourdomain.example

On Windows, nslookup reports the same state as *** UnKnown can't find yourdomain.example: Server failed. Neither message mentions DNSSEC, so most people spend the first day of a broken chain looking at the web server.

The mail side takes longer to surface. A sending server that can’t resolve your MX defers the message and retries, and a Postfix sender logs each attempt as:

status=deferred (Host or domain name not found. Name service error for name=yourdomain.example type=MX: Host not found, try again)

That “try again” is the reason nobody notices for days. Senders keep retrying for the length of their queue lifetime and only then return the message. Your outbound mail suffers as well, because receivers that validate hit the same SERVFAIL when they look up your SPF and DMARC records, and a receiver treats a lookup that fails with a temporary error as a temporary failure at their end. The email delivery page covers what a receiver does with a lookup it can’t complete.

The census puts a size on the fault. Of the 316,600,902 domains where the DNSSEC check ran in the September 2026 census, 21,732,692 (6.9%) are signed with a chain that validates, and 173,606 (0.05%) are signed and broken, meaning a validating resolver refuses to hand out their addresses, and most of those owners probably haven’t noticed yet.

The free scan below asks a validating resolver outside your network and reports the chain as valid, broken or unsigned, so it settles “works for me” in one line.

EDE 9: the DS names a key you no longer serve

This is the fault you get after moving DNS hosting, and it’s the most common one. Compare what the parent says about you with what your name servers serve:

$ dig +short DS yourdomain.example @1.1.1.1
2371 13 2 1F987CC6583E92DF0890718C42D45A7C4B6B2F1A3B4C5D6E7F8091A2B3C4D5E6

$ dig +multi DNSKEY yourdomain.example @ns1.your-dns-host.example
yourdomain.example. 3600 IN DNSKEY 257 3 13 (
        mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+Gq
        JxpVXckHAeF+KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==
        ) ; KSK; alg = ECDSAP256SHA256 ; key id = 51920

The DS carries key tag 2371 and the zone serves key id 51920. The parent is vouching for a key that left with your old provider, and nothing your new host does in its own zone can change that, because the DS lives at the registrar. If the key tags do match and you still see EDE 9, the digest was mistyped when someone pasted it into the registrar form. A type 2 digest is 64 hex characters, and one dropped or doubled character is enough.

Either replace the DS with the one the new host shows in its panel, which will carry key id 51920, or delete the DS so the zone goes back to unsigned. Replacing keeps DNSSEC; deleting is the faster recovery, and the section on withdrawing the DS explains why you might do that first and re-sign afterwards.

EDE 7: signatures that ran out

Ask an authoritative server directly for the signature and read the two timestamps:

$ dig +dnssec +multi yourdomain.example A @ns1.your-dns-host.example
yourdomain.example. 300 IN A 203.0.113.10
yourdomain.example. 300 IN RRSIG A 13 2 300 (
        20260829000000 20260815000000 51920 yourdomain.example.
        oB1iN9M2hcJ7xKQ5eZ...
        )

The first timestamp is the expiry, and 29 August 2026 has passed. Signatures on a signed zone are short-lived by design, and something has to keep renewing them. When the renewal stops, the zone carries on serving stale signatures until the day they expire, at which point the domain disappears for validating resolvers with no change to any record you can see in a control panel.

Signers stop for ordinary reasons: a self-hosted signing job died and nobody restarted it, or someone exported the zone to a plain text file, edited it and imported it back without the signing pipeline. A secondary server can also fall behind the primary and serve last month’s copy with last month’s signatures, in which case only the resolvers that happened to pick that server fail, and the fault looks intermittent. Query each authoritative server by name, because a healthy primary with a stale secondary passes the first check.

An operator running Unbound will see the same fault from the resolver side as validation failure <yourdomain.example. A IN>: signature expired, and that is worth searching for in any resolver logs you’re sent.

The repair is to get fresh signatures served from all of your name servers, and until you can, the DS should come down.

EDE 10: a DS at the parent and no signatures in the zone

Registrars keep DS records across changes of name server, and transfers between registrars copy them across. So the zone moves to a host that doesn’t sign, or to one where signing was never switched on, and the parent carries on promising a signed zone. The resolver fetches your DNSKEY set, or finds none, and finds no RRSIG on anything:

$ dig +dnssec DNSKEY yourdomain.example @ns1.your-dns-host.example
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

An authoritative answer with no DNSKEY and no RRSIG, while the parent holds a DS, is this fault exactly. There is one repair, and it’s the DS coming down at the registrar. If you want the zone signed, enable signing at the new host first, confirm signatures are served, then publish the DS that host gives you. In that order: a DS published before the signatures exist puts you straight back into EDE 10.

The reverse case arrives under the same “DNSSEC” ticket. If dig +short DS yourdomain.example @1.1.1.1 returns nothing, the parent holds no DS and the world treats your zone as unsigned, whatever your DNS host’s panel says about signing. That is the “off” state, and it’s safe. A scanner will report “not signed”, and since nothing is failing you can take your time about turning it on properly.

Withdraw the DS first, then repair

For anything you can’t fix inside the hour, delete the DS at the registrar. A zone with no DS at the parent is an unsigned zone to a validating resolver, and unsigned resolves. This is the same state most of the internet is in, and it is where you were before the change that broke things.

Recovery isn’t instant, and you can’t hurry it. Validating resolvers cache the DS for as long as your TLD’s DS TTL says, and they will keep failing you until that copy expires. Read the TTL off the DS record before you delete it:

$ dig DS yourdomain.example @1.1.1.1
yourdomain.example.  86400  IN  DS  2371 13 2 1F987CC6...

That number is seconds, and it’s the longest any resolver should hold the old DS. Give whoever raised the ticket that figure up front, so another hour of SERVFAIL after “I’ve fixed it” doesn’t come as a surprise to them.

Once the domain resolves from outside again, re-sign at your own pace. Enable signing at the DNS host, confirm every authoritative server returns RRSIGs with a future expiry, wait longer than your zone’s longest TTL, then publish the DS the host gives you, copying it exactly. Verify from outside with dig +dnssec yourdomain.example A @1.1.1.1 and look for ad in the flags line.

Then put a check on that ad flag, because a broken chain raises no alert of its own and the next expiry won’t announce itself either.

What else went quiet while it was down

Automated certificate renewal fails on a broken chain, because the certificate authority’s own validation resolvers validate DNSSEC and see the same SERVFAIL. The error the client returns is:

DNS problem: SERVFAIL looking up A for yourdomain.example

If the chain was broken for long enough, the renewal window may have closed and the certificate will expire on schedule a few weeks later, which is a second outage with a different cause on the same domain. Check the expiry date on the certificate the site is serving now, and rerun the renewal once resolution is back. The TLS page covers what the browser shows when that one lands.

Anything that checked your domain during the outage recorded a failure. Third-party scanners, supplier questionnaires, mail providers’ reputation systems and uptime monitors all queried a validating resolver and all got nothing. Some of those will want a rescan before they mark you clear, so after resolution returns, run the same outside checks you used to diagnose the fault, and keep the output, since a customer may still turn up with a screenshot from last week and want to see the domain resolving now.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.