You enabled DNSSEC at your registrar, pasted the DS record, and felt secure. Then your site went dark on Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) while your ISP resolver still seemed fine. dig returns status: SERVFAIL. Your origin is up, your A/AAAA records are correct, but every validating resolver on the public internet refuses to hand out the answer because the DNSSEC chain of trust is broken. This is one of the nastiest DNS failure modes: non-validating resolvers keep working, so your laptop on a corporate network sees the site fine while real users get nothing.
Fastest fix: if you cannot resolve the mismatch in minutes and users are down, delete the DS record at your registrar and wait for the parent TTL (a few hours) — your zone reverts to plain unsigned DNS and resolution returns. If you have time to fix it properly, read the EDE code in your dig output (see Step 1) — it names the exact broken link — then regenerate the DS from your live DNSKEY and replace it at the registrar. Both paths are below.
Read the EDE code first (June 2026)
Since around 2022, every major validating resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) attaches an Extended DNS Error (EDE, RFC 8914) to the SERVFAIL. As of June 2026 dig prints it in the OPT PSEUDOSECTION. This one line usually tells you which cause below you are in, so run this before anything else:
dig +dnssec yourdomain.com @1.1.1.1Look for a line like:
; EDE: 6 (DNSSEC Bogus): failed to verify DS yourdomain.com.: using DNSKEY ids = [12345]The DNSSEC-relevant EDE codes and what they mean:
| EDE code | Name | Most likely cause |
|---|---|---|
6 | DNSSEC Bogus | DS does not match DNSKEY, or NSEC3 proof invalid (causes 1, 2, 5) |
7 | Signature Expired | RRSIG lapsed; signer stopped re-signing (silent key expiry) |
8 | Signature Not Yet Valid | Signer clock skew, or you published signatures with a future inception |
9 | DNSKEY Missing | DS at registrar points at a key tag with no matching DNSKEY (cause 4) |
10 | RRSIGs Missing | Zone (or one nameserver) serves records without signatures (cause 3) |
No EDE line at all and a clean answer with the ad flag means validation is already passing — your problem is elsewhere (or it is a stale cache, cause 6).
Common causes
Ordered by likelihood across registrar-DNS-host splits.
1. DS record at registrar does not match DNSKEY at nameservers
The DS record (Delegation Signer) at the parent zone must hash to a key in the child zone’s DNSKEY RRset. If you copied the DS from a stale screenshot, or you rotated keys at the host without updating the registrar, the chain breaks.
How to spot it: dig +dnssec yourdomain.com DNSKEY @8.8.8.8 returns the keys, but dig DS yourdomain.com @8.8.8.8 shows a different digest than dnssec-dsfromkey computes from the DNSKEY.
2. Algorithm or digest-type mismatch
The DS at the registrar may declare algorithm 8 (RSASHA256) while your nameserver actually signs with 13 (ECDSAP256SHA256), or the DS uses digest type 1 (SHA-1), which validating resolvers no longer accept as of 2026 — only digest type 2 (SHA-256) is honored.
How to spot it: Run a check at dnsviz.net/d/yourdomain.com/dnssec/ — it draws the chain and flags algorithm and digest mismatches in red. An EDE: 6 (DNSSEC Bogus): no supported DS / no matching DNSKEY line points here too.
3. Multi-provider DNS split where only one provider signs
You have a primary nameserver that signs (Cloudflare, Route 53 with DNSSEC enabled) and a secondary that does not. Resolvers that randomly hit the unsigned secondary see a missing RRSIG and mark the response bogus.
How to spot it: Query each NS individually: dig @ns1.yourprovider.com yourdomain.com +dnssec. If some return RRSIG and some don’t, you have a split-signing problem.
4. Stale DS still present after key rotation
You rolled keys at the host, the host pushed a new DS to the registrar, but the registrar kept the old DS too (or you removed the new and kept the old). Resolvers fetch all DS records and need at least one to validate; with only an old DS pointing at a retired DNSKEY, validation fails.
How to spot it: dig DS yourdomain.com @8.8.8.8 returns two DS records but dig DNSKEY yourdomain.com only has the new keys. The old DS keytag has no corresponding DNSKEY.
5. NSEC / NSEC3 misconfiguration causing denial-of-existence failure
Even when a name exists, NSEC/NSEC3 records prove what does NOT exist. A misconfigured NSEC3 salt or iteration count on the nameserver makes denial proofs invalid, so validating resolvers reject everything.
How to spot it: dnsviz.net shows NSEC3 errors specifically, or delv yourdomain.com prints a ;; validating ...: no valid signature found / insecurity proof failed line rather than ; fully validated. EDE 6 (DNSSEC Bogus) on a name that exists also points here.
6. TTL has not expired so resolvers cache the bad state
Even after you fix the records, resolvers keep the BOGUS verdict cached for the original TTL (often 1-24h). Users still see SERVFAIL until cache expires.
How to spot it: Records look correct in dig but resolvers still SERVFAIL. Check TTL: dig +noall +answer +ttlunits yourdomain.com.
Before you start
- Note the exact moment you enabled DNSSEC and at which side (registrar or host).
- Save the current DS record from the registrar UI as text — you may need to roll back.
- Identify whether your registrar and your DNS host are the same company; if not, this is almost certainly the cause.
- Have a non-validating resolver handy for sanity checks (your ISP’s resolver typically does not validate).
Information to collect
- Output of
dig +dnssec yourdomain.com DNSKEY @8.8.8.8 +multiline. - Output of
dig +dnssec yourdomain.com DS @8.8.8.8 +multiline. - Output of
delv yourdomain.com @8.8.8.8(gives a clean BOGUS/SECURE verdict). - A screenshot of the registrar’s DS record entry, including algorithm, digest type, key tag.
- The DNS host’s signing algorithm setting (Cloudflare, Route 53, etc.) — check whether it is RSASHA256 vs ECDSAP256.
Step-by-step fix
Ordered cheapest to most disruptive.
Step 1: Confirm the failure mode
delv +rtrace yourdomain.com @8.8.8.8delv does its own validation and prints the chain step by step. A healthy zone ends with ; fully validated. A broken one ends with ;; resolution failed: SERVFAIL plus a reason line such as ;; validating yourdomain.com/A: no valid signature found, broken trust chain, or RRSIG has expired — that reason names the exact broken link. Capture this output before you change anything; it is your before/after evidence.
Then confirm the records themselves are fine and only DNSSEC is at fault:
dig +cd yourdomain.com @8.8.8.8+cd (checking disabled) bypasses validation. If this returns the right answer but the plain query returns SERVFAIL, your records are correct and DNSSEC is broken — exactly the case this article fixes. Cross-check the EDE code from the intro to pick the matching cause before you touch the registrar.
Step 2: Regenerate the DS from the live DNSKEY
Most DNS hosts (Cloudflare, Route 53, DNSimple) expose a “DS record for registrar” panel. Open it. Copy the value freshly. Do not trust the value you pasted six months ago.
If you control the zone manually with BIND:
dnssec-dsfromkey -2 Kyourdomain.com.+013+12345.key-2 forces a SHA-256 (digest type 2) DS. As of June 2026, only digest type 2 is safe: SHA-1 (digest type 1) has been dropped by validating resolvers, so a type-1 DS at the registrar validates nowhere. The +013 in the key filename is algorithm 13 (ECDSAP256SHA256), the recommended algorithm per RFC 8624; algorithm 8 (RSASHA256) still validates but is being phased out. Whatever algorithm your zone actually signs with, the algorithm number in the DS must match it exactly — a DS that says 8 over a zone signed with 13 is EDE 6 Bogus.
Step 3: Replace the DS at the registrar
Log into your registrar. Delete the old DS record. Add the new one from Step 2, matching every field: key tag, algorithm number, digest type, digest. Save.
Some registrar UIs (GoDaddy, older Namecheap flows) ask for the full record as one string. Format:
12345 13 2 ABC123DEF456...(keytag, algorithm, digest-type, digest)
Step 4: Verify the chain from a validating resolver
dig +dnssec yourdomain.com @1.1.1.1You want to see flags: qr rd ra ad — the ad flag (authenticated data) confirms the resolver validated successfully. No ad flag = no validation; SERVFAIL = still broken.
Wait 5-10 minutes between attempts. Public resolvers cache negative DNSSEC results.
Step 5: If chain still bogus, temporarily disable DNSSEC at the registrar
If you cannot fix the mismatch live and users are affected, pull the DS at the registrar:
- Log into registrar.
- Delete the DS record(s).
- Wait for the parent TTL to expire (typically the TLD’s NS TTL, ~6-24h).
After the parent TTL expires, your zone is effectively un-signed at the chain-of-trust level. Resolvers stop validating and serve the records as plain unsigned DNS. Site is back up. Then fix the keys offline and re-enable.
Step 6: Flush negative caches at known public resolvers
Most public resolvers expose a flush form (each is gated by a reCAPTCHA; no domain ownership proof needed):
- Google Public DNS:
https://dns.google/cache(flush both the apex and any failing subdomain) - Cloudflare
1.1.1.1:https://one.one.one.one/purge-cache/— set the record type toDSandDNSKEY, not justA, since those are what got cached BOGUS
Submit your domain on each. This shortens the SERVFAIL window for users on those resolvers; Cloudflare propagates the purge to all data centers within seconds.
Verify
dig +dnssec yourdomain.com @8.8.8.8returns an ANSWER section with RRSIG records, thead(authenticated data) flag in the header, and noEDEline.delv yourdomain.com @8.8.8.8prints; fully validated.dnsviz.net/d/yourdomain.com/dnssec/shows a green chain end-to-end from the root (.) to your zone with no red errors.- A plain (non-
+cd) query from at least two public resolvers (1.1.1.1,8.8.8.8,9.9.9.9) all succeed. - Real users on validating resolvers report the site loads.
Long-term prevention
- Use a registrar and DNS host that integrate via CDS / CDNSKEY (Cloudflare + many TLDs do this) — the registrar auto-pulls the DS from the host, eliminating manual copy errors.
- When you rotate keys, follow a two-step process: (1) push new DNSKEY, wait one TTL; (2) push new DS at registrar, wait one TTL; (3) retire old key.
- Set a calendar reminder for any DNSSEC key with a fixed lifetime — silent expiry is a P1 outage waiting to happen.
- Run
dnssec-monitoror adnsvizcron once a day so chain drift surfaces in alerts, not customer tickets. - Document who owns DNSSEC on your team. Splitting registrar admin and DNS admin between people produces this exact failure repeatedly.
Common pitfalls
- Enabling DNSSEC at the host without ever copying the DS to the registrar. The chain is open at the parent — every validator returns BOGUS the instant the host signs.
- Pasting the DS into the registrar with one digit wrong and assuming “DNS just takes time”. It does not get better on its own.
- Mixing algorithms across keys: some KSKs sign with algorithm 8, ZSKs with 13. Validators get confused; some accept, some reject.
- Leaving the old DS in place “just in case” after rotation. Old DS pointing to a deleted DNSKEY = BOGUS, even if a fresh DS also exists alongside it (depending on resolver logic).
- Forgetting that disabling DNSSEC also needs to wait for the parent TTL before resolvers stop validating. Removing DS does not instantly fix BOGUS.
FAQ
Q: My ISP’s resolver works fine but Google DNS gives SERVFAIL. Is my domain broken?
Yes, for any user on a validating resolver. Your ISP’s resolver is not validating DNSSEC, so it hands out cached records regardless of chain status. Google, Cloudflare, Quad9, and most corporate resolvers validate — those users see SERVFAIL. Treat it as a real outage.
Q: Can I just disable DNSSEC and walk away?
Yes, short-term. Delete the DS at the registrar, wait for the parent TTL, and your zone is back as plain DNS. You lose the integrity protection but recover availability. Re-enable after you understand the original failure.
Q: How long does a BOGUS cache live?
Bound by the SOA minimum TTL or the negative TTL of the failed validation, typically 5 minutes to 1 hour for most resolvers, up to 24 hours on aggressive caching. Use the resolver flush forms above to shorten this.
Q: I see two DS records at the registrar and only one DNSKEY at the host. Is that bad?
It is fine during a rotation (you publish the new DS before retiring the old key) but it must not persist. Once the old key is fully gone from the DNSKEY RRset, remove the matching old DS or you’ll have noise in dig DS output.
Q: My dig output shows EDE: 7 (Signature Expired) — what now?
Your signer stopped re-signing the zone and the RRSIGs lapsed. This is not a DS/registrar problem; the fix is at the DNS host. On a managed host (Cloudflare, Route 53) re-saving any record or toggling signing usually forces a re-sign; on self-hosted BIND, check that dnssec-policy / automatic re-signing is running and that the server clock is correct (EDE 8, Signature Not Yet Valid, is the same problem caused by a clock that is ahead). After it re-signs, flush the resolver caches in Step 6.
Q: It validates from delv and dnsviz but Cloudflare still SERVFAILs. Why?
Almost always a cached BOGUS verdict (cause 6). delv and dnsviz query authoritatively and ignore resolver caches, so they see the fixed state immediately while 1.1.1.1 is still serving the old negative result until its TTL expires. Use the https://one.one.one.one/purge-cache/ form with record types DS and DNSKEY, then re-test.
For related issues, see CAA record blocks cert issuance, SSL cert delay, and name server vs DNS records confusion.
Tags: #Troubleshooting #DNS #dnssec #Debug