Loading...
WebShield Audit
Medium severity
Missing DNSSEC
DNSSEC signs your DNS records cryptographically so validating resolvers can detect tampering or cache poisoning during lookup.
Business risk
Without DNSSEC, a DNS cache-poisoning attack, a misconfigured registrar account, or a BGP hijack during ACME HTTP-01 validation can redirect your domain to an attacker-controlled server. The victim sees the correct URL, the TLS handshake completes (with a cert the attacker just got from a public CA using the hijacked DNS), and nothing visible is wrong. DNSSEC-validating resolvers (about 38% of internet DNS traffic in 2026, including Google Public DNS, Cloudflare, and Quad9) refuse to return unsigned responses when a signed chain is expected, breaking the attack.
Technical details
DNSSEC requires coordination between two parties: your DNS provider (generates zone-signing keys and signs records) and your registrar (publishes the DS record that chains your zone to the parent zone). Algorithm 13 (ECDSA P-256 with SHA-256) is the modern default. If your registrar does not support Algorithm 13, transfer to one that does. Some registrars like Cloudflare handle both sides automatically if you use their DNS. Others require manual DS-record submission.
How to detect it
Two things must be true: your zone is signed (RRSIG records present), and a DS record is published at your registrar chaining up to the parent zone. A `dig +dnssec` query with the `ad` flag in the response confirms validation via a resolver.
Check ad flag and RRSIGs
dig +dnssec yourdomain.com | grep -E "flags|RRSIG"Verify the DS record exists at the parent
dig +short DS yourdomain.com @8.8.8.8Visual chain debugger
https://dnsviz.net/d/yourdomain.com/dnssec/Common pitfalls
- Enabling zone signing at the DNS provider without publishing the DS record at the registrar. Validating resolvers will then treat your zone as insecure (or, worse, BOGUS), breaking DNS lookups. Always do it in order: generate keys → publish DS at registrar → wait for DS propagation → then activate signing.
- Using Algorithm 8 (RSA/SHA-256) where Algorithm 13 (ECDSA P-256) is available. Algorithm 13 has shorter signatures and is the modern standard. Upgrade when your provider supports it.
- Rolling the KSK without a double-DS period. Plan the rollover: new KSK added, new DS added at registrar, wait for TTL, then retire old KSK. Cutting corners causes outages.
- Forgetting that DNSSEC affects every subsequent DNS change. Some older DNS GUIs cannot modify signed zones well - verify your workflow (CNAMEs for third parties, adding TXT for verification) still works after enabling.
- Assuming your registrar supports Algorithm 13. Some legacy registrars (GoDaddy historically, some reseller platforms) only support older algorithms. Transfer to a modern registrar if needed.
Remediation guide
External references
Frequently asked questions
Algorithm 13 or Algorithm 8?
Algorithm 13 (ECDSA P-256 with SHA-256) in all new deployments. Shorter signatures, smaller zone size, better performance. Algorithm 8 (RSA with SHA-256) still works but is larger and slower. Only use Algorithm 8 if your registrar cannot handle 13.
My registrar does not support DNSSEC. What do I do?
Transfer. Cloudflare Registrar, Gandi, Porkbun, Namecheap, Name.com, and Hover all support Algorithm 13 DS records. The transfer is reversible and usually takes 5-7 days.
Will DNSSEC break my email?
No, but a misconfigured DNSSEC rollover can. If your zone goes BOGUS (signatures invalid against the DS), validating resolvers refuse all your records - including MX. Monitor signatures and DS TTLs carefully during key rolls.
Keep going
Verify your fix
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.