It’s one of the most panic-inducing moments in DNS management. You deploy DNSSEC, everything looks fine — then your phone starts ringing. Your website is down. Users are getting SERVFAIL errors. Support tickets are piling up. And the culprit? Broken DNSSEC records.
The irony is real: the very security feature designed to protect your domain can take it completely offline if misconfigured. And the challenge is that DNSSEC failures are often invisible to the untrained eye. No flashing red alerts. No obvious error messages. Just your domain quietly becoming unreachable to millions of validating resolvers around the world.
Here’s the good news. Broken DNSSEC is fixable. Almost always. And once you understand the common failure patterns, you’ll be able to diagnose and resolve them quickly — sometimes in minutes.
This guide will walk you through exactly why DNSSEC records break, what the warning signs look like, and the step-by-step process to fix broken DNSSEC records and get your domain back online.
By the Numbers: According to research by ICANN, DNSSEC misconfiguration is responsible for approximately 4–5% of all DNS resolution failures globally. For popular domains, even brief DNSSEC outages can affect millions of users and cost thousands in lost revenue per hour.
Why Do DNSSEC Records Break in the First Place?
Before you can fix the problem, you need to understand what you’re dealing with. DNSSEC adds cryptographic signatures to DNS records, creating a chain of trust from the root zone down to your domain. When any link in that chain is broken, missing, or mismatched, validating resolvers reject your DNS responses entirely.
Here are the most common reasons DNSSEC records break:
1. Expired Signatures (RRSIG Expiry)
Every DNSSEC signature has an expiration date embedded in the RRSIG record. When that date passes, validating resolvers treat the signature as invalid — even if the underlying data is perfectly correct. This is the number one cause of DNSSEC outages worldwide.
It often happens when:
- Automatic key signing is disabled or fails silently in the background.
- A DNS provider change breaks the automated signing pipeline.
- No monitoring is in place to alert on signature expiry.
- The zone was signed manually and nobody set a reminder to re-sign.
2. DS Record Mismatch
The Delegation Signer (DS) record, published in your parent zone (e.g., .com or .org), is a fingerprint of your zone’s Key Signing Key (KSK). If your DS record doesn’t match your current KSK — which commonly happens after a key rollover — every validating resolver will refuse to trust your zone.
This mismatch is the most common consequence of botched key rollovers. The new KSK is in place, but nobody updated the DS record at the registrar. Result: complete DNSSEC failure.
3. Missing DNSKEY Records
If your DNSKEY records — the public keys your zone uses for signing — are deleted, fail to publish, or disappear during a provider migration, resolvers have nothing to validate signatures against. Your RRSIG records are pointing to keys that don’t exist.
4. Zone Re-Signing Failures
DNSSEC zones need to be re-signed periodically. If your DNS provider’s automated re-signing job fails (due to configuration errors, software bugs, or service disruptions), your signatures quietly expire in the background — and you won’t know until users start reporting problems.
5. Provider Migration Without DNSSEC Handoff
Switching DNS providers is one of the riskiest moments for DNSSEC. If you move your zone without properly coordinating the DNSSEC configuration — particularly the DS record update — you’ll almost certainly break validation. Many organizations discover this the hard way.
⚠️ Warning: DNSSEC failures are “fail-closed” by design. Validating resolvers don’t fall back to accepting unsigned responses — they return SERVFAIL. This means your site is completely unreachable to anyone using a DNSSEC-validating resolver (including Cloudflare 1.1.1.1 and Google 8.8.8.8), which together handle a significant portion of global DNS traffic.
Warning Signs: How to Know Your DNSSEC Is Broken
DNSSEC failures don’t always announce themselves loudly. Watch for these red flags:
- SERVFAIL errors: Users report they can’t reach your site, and dig queries return SERVFAIL instead of the expected A or AAAA record.
- Inconsistent resolution: Your site works for some users but not others — typically because non-validating resolvers still serve your domain while validating ones refuse.
- DNSViz shows red: The DNSViz visualization tool shows broken chain links, expired signatures, or missing records highlighted in red.
- Sudden drop in traffic: Analytics show a sharp, unexplained drop in organic and direct traffic — a classic symptom of DNSSEC-related inaccessibility.
- Monitoring alerts firing: DNSSEC-aware monitoring tools flag signature expiry windows (typically 7–14 days before expiry).
The moment you suspect a DNSSEC issue, your first stop should be a diagnostic tool. Don’t guess — verify.
Your Diagnostic Toolkit: Verify Before You Fix
Attempting to fix broken DNSSEC records without proper diagnosis is like prescribing medicine without examining the patient. These tools will tell you exactly what’s wrong:
- DNSViz (dnsviz.net): The gold standard. Provides a visual map of your DNSSEC chain with color-coded indicators. Red nodes = problems. Hover over issues to see detailed explanations.
- Verisign DNSSEC Analyzer: Produces a detailed text-based report of your zone’s DNSSEC configuration, including signature validity windows and DS record status.
- Zonemaster (zonemaster.net): Excellent for testing both DNS correctness and DNSSEC health. Particularly useful when migrating providers.
- dig command-line tool: For hands-on diagnostics. Run
For a quick command-line check, run: dig +dnssec yourdomain.com and dig DS yourdomain.com @8.8.8.8 to inspect your DS records against the parent zone.
How to Fix Broken DNSSEC Records: Step-by-Step
Now for the part you’re here for. Below are the specific fixes for each failure type. Work through whichever applies to your situation.
Fix 1: Expired RRSIG Signatures
If your signatures have expired, the fix is re-signing the zone. How you do this depends on your DNS provider:
- Managed DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS): Log into your provider’s dashboard and look for the option to disable and re-enable DNSSEC signing. This forces a full zone re-sign with fresh expiry dates.
- Self-managed BIND or PowerDNS: Manually trigger a re-sign using
For BIND, run: rndc sign yourdomain.com. For PowerDNS, use: pdnsutil rectify-zone yourdomain.com followed by pdnsutil sign-zone yourdomain.com.
After re-signing, verify with DNSViz that new RRSIG records are in place with valid future expiry dates.
Fix 2: DS Record Mismatch After Key Rollover
This requires updating the DS record in your registrar’s portal to match your current KSK. Here’s the process:
- Retrieve your current KSK fingerprint — your DNS provider’s DNSSEC settings page will show this, or you can extract it via: dig DNSKEY yourdomain.com
- Generate the correct DS record from your DNSKEY. Most providers do this automatically and display it for you to copy.
- Log into your domain registrar (not your DNS host — these are often different!) and navigate to the DNSSEC or DS Record settings.
- Delete the old DS record and enter the new one. Use Algorithm 13 (ECDSA P-256) or Algorithm 8 (RSA/SHA-256) if given a choice — avoid the deprecated Algorithm 5.
- Save and allow propagation. DS record changes can take up to 24–48 hours to propagate globally, though most updates are visible within 1–2 hours.
Fix 3: Missing DNSKEY Records
If DNSKEY records have been accidentally deleted or didn’t migrate correctly, you’ll need to re-establish them:
- Through your DNS provider dashboard, disable DNSSEC completely.
- Wait for the DS record TTL to expire so parent zone changes propagate.
- Re-enable DNSSEC signing — this generates a fresh DNSKEY pair.
- Update your registrar with the new DS record.
- Verify the full chain with DNSViz before declaring the fix complete.
Fix 4: DNSSEC Failures During Provider Migration
Provider migrations are the trickiest scenario because timing is everything. Here’s the safest sequence:
- Before switching: lower your TTL values to 300 seconds (5 minutes) at least 24 hours in advance.
- At your current provider: disable DNSSEC and remove the DS record from your registrar. Wait for the DS record TTL to expire fully.
- Complete the nameserver migration to your new provider.
- At the new provider: enable DNSSEC signing and retrieve the new DS record.
- Submit the new DS record to your registrar to re-establish the chain of trust.
- Verify with DNSViz and gradually restore TTL values once everything checks out.
Pro Tip: After any DNSSEC fix, always test from multiple geographic locations using tools like WhatsMyDNS.net. DNSSEC propagation isn’t instant, and what’s working from your location may still be broken elsewhere. Give it at least 30–60 minutes before declaring victory.
Prevention: How to Stop DNSSEC From Breaking Again
Fixing broken DNSSEC records once is a painful experience. Doing it repeatedly is a systems failure. Here’s how to build a DNSSEC operation that stays healthy:
- Monitor signature expiry: Set up automated alerts at least 14 days before RRSIG expiry. Tools like Nagios, Zabbix, and Datadog all support DNSSEC monitoring plugins. Some providers offer native alerting.
- Use managed DNSSEC when possible: Cloudflare and AWS Route 53 handle automatic re-signing and key rollovers on your behalf. If you’re self-managing DNSSEC, ensure your signing automation is tested and monitored.
- Document your key rollover procedure: Don’t rely on memory. Maintain a written runbook for KSK and ZSK rollovers, including which team member owns each step and what registrar credentials are needed.
- Never migrate DNS providers without a DNSSEC plan: Follow the disable-migrate-re-enable sequence every time, without exception.
- Run regular DNSViz checks: Schedule a weekly automated check against DNSViz or Zonemaster and pipe results into your SIEM or alerting system.
Frequently Asked Questions
1. How long does it take to fix broken DNSSEC records?
It depends on the failure type. Expired signatures can be re-signed in minutes, but the fix takes time to propagate — typically 1 to 4 hours for most resolvers to pick up fresh signatures. DS record updates at the registrar can take up to 24–48 hours for full global propagation, though most resolvers see the update within 1–2 hours. The diagnostic and fix steps themselves usually take 15–45 minutes for an experienced administrator.
2. Will disabling DNSSEC completely fix a DNSSEC outage?
Yes — but it’s the nuclear option and should only be used when the alternative is extended downtime you can’t resolve quickly. To fully disable DNSSEC, you must remove the DS record from your registrar (not just disable signing at your DNS provider). Once the DS record is gone and its TTL has expired, validating resolvers stop checking for DNSSEC and your domain becomes reachable again. After stabilizing, you should re-enable DNSSEC properly with a tested configuration.
3. Why do some users see my site but others get SERVFAIL?
This split behavior is the classic symptom of a DNSSEC failure. Users whose DNS resolvers perform DNSSEC validation (like Cloudflare 1.1.1.1 or Google 8.8.8.8) will receive SERVFAIL because the validation fails. Users whose resolvers don’t validate DNSSEC will still resolve your domain normally — they’re simply ignoring the broken signatures. This is also why you might not notice a DNSSEC problem immediately if your own resolver happens to be non-validating.
4. Can a registrar or DNS provider cause my DNSSEC to break?
Absolutely, and this happens more than providers like to admit. Registrar platform updates have accidentally cleared DS records. DNS provider migrations have left signing pipelines broken. Provider-side bugs have caused re-signing jobs to silently fail. This is exactly why independent monitoring matters — don’t rely solely on your provider’s own health dashboards. External monitoring tools that test your DNSSEC chain from the outside catch problems your provider’s internal alerts might miss.
5. Is it safe to run a domain without DNSSEC while I fix it?
Temporarily, yes — if the alternative is complete inaccessibility. A domain without DNSSEC is in the same security state as most of the internet was before DNSSEC existed. It’s not ideal, but it’s operational. The risk is that without DNSSEC, your DNS responses are unverified and theoretically spoofable. For most domains, the operational risk of extended downtime outweighs the brief security trade-off of running unsigned while you restore a correct configuration. That said, fix it as fast as humanly possible and don’t let “temporary” become permanent.
Don’t Wait for DNSSEC to Break. Act Now.
DNSSEC failures don’t send you a warning email. They just happen — quietly, at 2 AM on a Friday, right before your biggest traffic day of the year. The organizations that handle DNSSEC outages in minutes instead of hours are the ones that prepared before the crisis.
Whether you’re actively dealing with broken DNSSEC records right now or trying to prevent the next incident, here’s your action plan:
- Run a DNSViz check on your domain right now — even if everything seems fine. Know your baseline.
- Check when your RRSIG records expire: dig +dnssec yourdomain.com | grep RRSIG
- Verify your DS record at your registrar matches your current KSK. Don’t assume — verify.
- Set up external DNSSEC monitoring with alerting at least 14 days before expiry.
- Write (or update) your DNSSEC runbook today, while you’re thinking about it.
- If you’re currently broken: follow the step-by-step fix guide above, starting with diagnosis before you touch anything.
Your domain is the front door to everything your business does online. Make sure the lock on that door actually works.
