DNSSEC contrarian: when not to enable it

DNSSEC has been "the right thing to do" for two decades. ICANN promotes it. SSL Labs / Mozilla Observatory both flag its absence. NIS2 references it. Yet the actual deployment rate, after 25 years, sits at ~5% of .com domains. There's a reason, and it's worth being honest about.

What DNSSEC protects against

DNSSEC signs DNS records. A validating resolver can verify that the example.com IN A 1.2.3.4 answer it received was actually published by example.com's authoritative server, and wasn't tampered with on the wire. The threats:

• Cache poisoning of recursive resolvers (Kaminsky 2008-style)
• On-path DNS injection (a malicious ISP or rogue Wi-Fi)
• Compromised authoritative DNS provider (sort of — see below)

What DNSSEC does NOT protect against

• Domain takeover. If your registrar account gets phished, the attacker rotates your DS records and re-signs with their own key. DNSSEC adds zero protection here — in fact it makes the attacker's job cleaner because they can't be detected as quickly.
• BGP hijacking. Attacker announces your auth name servers' IP space. DNSSEC at the resolver detects this — but only resolvers that validate, and only if your TLD is signed (most aren't a problem since 2010).
• Subdomain takeover. Wholly orthogonal. Your CNAME pointing at a deprovisioned Heroku app is signed properly and still vulnerable.
• Phishing / typosquatting. Attackers buy example-login.com, sign it properly with their own DNSSEC. Validates fine.

The failure mode that costs you

DNSSEC is a double-edged sword: incorrect signatures take you offline. A few real outages:

• Slack 2021-09: botched DNSSEC config caused 24-hour outage for a portion of users. Slack publicly removed DNSSEC after the incident.
• Microsoft Azure DNS 2020: ~3 hour outage attributed to a key rollover that desynced before the TTL refreshed.
• .nl ccTLD 2017: a key rollover ran past the prepublication window. Validating resolvers (mostly enterprise + Comcast) returned SERVFAIL for two hours, taking out roughly 15% of .nl traffic.
• HBO Max launch 2020: DNSSEC chain validation failure on hbomax.com kept users on validating resolvers offline at peak launch hour.

A weak TLS config gives you a finding. A botched DNSSEC config gives you a Twitter incident.

Operational cost: what you sign up for

Running DNSSEC properly involves:

• Two-key model: KSK (Key Signing Key) signs the DNSKEY set; ZSK (Zone Signing Key) signs the records. Different rotation cadences (KSK ~yearly, ZSK ~monthly).
• Pre-publication rollover: new key published with TTL grace period before signing with it; old key kept after rotation until TTL grace expires. Ten failure modes during the dance.
• DS record sync with the registrar: every KSK rotation, you update a record at your registrar (which delegates to the TLD). API support varies. OVH supports it. AWS Route53 has special handling. Some registrars require a ticket.
• Monitoring: validating-resolver test endpoints (dnsviz.net, verisignlabs.com/dnssec-debugger). Alerts on chain expiry — signatures expire, often in 30 days.

When DNSSEC IS the right call

• You're a TLD operator, ccTLD, or critical infra. Your customers depend on you not lying.
• You publish DANE TLSA records (mail server cert pinning via DNS — and DANE requires DNSSEC).
• You're under regulation that explicitly requires it (ANSSI, certain banking compliance frameworks, .gov).
• You operate in a jurisdiction with active state-level DNS poisoning.
• You use a fully-managed DNSSEC provider (Cloudflare DNS, AWS Route53 with their wizard, OVH's Anycast DNS) that abstracts the rotations.

When DNSSEC is NOT the right call

• You self-host DNS on a single bind9 server with no monitoring.
• Your registrar doesn't expose DS update APIs (you'd be one rotation away from outage).
• Your team has no DNSSEC operational experience and limited bandwidth.
• You're chasing a security checklist box without understanding the operational debt.

Our position at UnveilScan

We flag DNSSEC absence as LOW, not HIGH. Compare to SSL Labs which caps your grade at A- without DNSSEC. We think this is wrong: DNSSEC is a future-proofing and TLD-hardening measure, not a basic hygiene defect. We would rather flag a botched DNSSEC config (expired signatures, broken chain, RSA-1024 keys) at HIGH — those are critical because they take you offline.

Our dns checker reports DNSSEC presence and health. tls_extended separately covers DANE if you've gone that far. The score impact of "no DNSSEC" is deliberately small. If we flagged it MEDIUM, every well-run small business website would lose 5 points for not running infrastructure they don't need.