DNSSEC Validation Fails After Enabling at Registrar

You turned on DNSSEC and resolvers now return SERVFAIL. The DS at the registrar does not match the DNSKEY at your nameservers, breaking the chain.

Published: May 24, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

You enabled DNSSEC at your registrar — clicked the toggle, pasted the DS record, felt secure. Then your site went dark on Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) while ISP resolvers still seemed fine. dig returns status: SERVFAIL and dnssec-status: bogus. The site is “up” — your origin is fine, your DNS records are fine — but every validating resolver on the public internet is refusing to hand out the answer because the DNSSEC chain of trust is broken. This is one of the most painful DNS failure modes because non-validating resolvers will keep working, so your laptop on a corporate network sees the site fine while real users get nothing.

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 digest type is 1 (SHA-1) when only 2 (SHA-256) is accepted by modern resolvers.

How to spot it: Run a check at dnsviz.net/d/yourdomain.com/dnssec/ — it draws the chain and flags algorithm mismatches in red.

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 returns ; validating @0x...: bogus.

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.8

delv prints the validation chain step by step. The line that says ; bogus identifies the exact link that breaks. Capture this output before you change anything — it is your before/after evidence.

You can also run:

dig +cd yourdomain.com @8.8.8.8

+cd (checking disabled) bypasses validation. If this returns the right answer but the non-+cd query returns SERVFAIL, the records are correct but DNSSEC is broken — confirming this article’s diagnosis.

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 SHA-256 digest. Use the resulting DS at the registrar.

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.1

You 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 have a flush form:

Google: https://developers.google.com/speed/public-dns/cache?name=yourdomain.com
Cloudflare: https://one.one.one.one/purge-cache/

Submit your domain. This shortens the SERVFAIL window for users on those resolvers.

Verify

dig +dnssec yourdomain.com @8.8.8.8 returns ANSWER section + RRSIG records + ad flag.
delv yourdomain.com @8.8.8.8 prints ; fully validated.
dnsviz.net/d/yourdomain.com/dnssec/ shows a green chain end-to-end from . to your zone.
A 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-monitor or a dnsviz cron 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.

Tags: #Troubleshooting #DNS #dnssec #Debug