DNSSEC — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about DNS Security Extensions.
DNSSEC took 15 years from concept to root zone deployment¶
The idea of securing DNS with cryptographic signatures was first proposed in RFC 2065 (1997) by Donald Eastlake. The root zone was not signed until July 15, 2010. The delay was caused by a combination of political disputes over who should hold the root zone signing keys, technical challenges with large responses, and the operational complexity of key management across the entire DNS hierarchy.
The root zone signing ceremony is a real, physical event¶
The DNSSEC root zone Key Signing Key (KSK) is managed through formal ceremonies held at two secure facilities (in El Segundo, California, and Culpeper, Virginia). These ceremonies involve Trusted Community Representatives who hold physical smart cards, hardware security modules (HSMs), a safe requiring dual control, and a detailed script that is followed step by step. The entire process is livestreamed and audited.
DNSSEC does not encrypt anything¶
A common misconception is that DNSSEC provides confidentiality. It does not — all DNS queries and responses remain in plaintext. DNSSEC only provides authentication (the response came from the real authoritative server) and integrity (the response was not modified in transit). DNS encryption requires separate protocols: DNS over HTTPS (DoH, RFC 8484) or DNS over TLS (DoT, RFC 7858).
The 2019 root KSK rollover was delayed by over a year due to fear¶
ICANN planned to roll the root zone's Key Signing Key in October 2017 but postponed it to October 2018 because analysis showed that a significant number of resolvers had not picked up the new key via RFC 5011 automated trust anchor updates. The fear was that a botched rollover would break DNS resolution for millions of users. The eventual rollover went smoothly, but the anxiety was justified by the stakes.
NSEC "walking" lets anyone enumerate an entire DNS zone¶
DNSSEC's NSEC records prove that a name does not exist by providing the next existing name in the zone. This creates a chain that can be followed to enumerate every record in the zone — a massive privacy problem for domains that don't want their full contents listed. NSEC3 (RFC 5155, 2008) was created to fix this by hashing the names, but it only slows enumeration; it doesn't prevent it against offline dictionary attacks.
CloudFlare discovered that DNSSEC causes larger DDoS amplification¶
DNSSEC-signed responses are typically 5-10 times larger than unsigned responses due to the added RRSIG, DNSKEY, and NSEC/NSEC3 records. This makes DNSSEC-enabled domains more effective as DNS amplification attack reflectors. A 60-byte query can generate a 3,000+ byte response, giving attackers a 50:1 amplification factor. This security-vs-security tradeoff is one of DNSSEC's most uncomfortable realities.
Algorithm rollover has broken major domains¶
Changing the cryptographic algorithm used for DNSSEC signing (e.g., from RSA/SHA-1 to ECDSA P-256) requires a carefully orchestrated multi-step process. Several high-profile domains have botched this process, causing their domains to become unresolvable for DNSSEC-validating resolvers. The complexity of algorithm rollovers is one of the main reasons many DNS operators avoid DNSSEC entirely.
Only about 30% of DNS queries are validated with DNSSEC¶
Despite being available since 2010, DNSSEC validation adoption remains partial. As of the mid-2020s, roughly 30% of DNS queries worldwide pass through validating resolvers (primarily driven by Google Public DNS and Cloudflare's 1.1.1.1). On the signing side, only about 5-10% of .com domains are signed. This chicken-and-egg problem has persisted for over a decade.
DANE was supposed to fix the CA system but never gained traction¶
DNS-Based Authentication of Named Entities (DANE, RFC 6698) uses DNSSEC-authenticated TLSA records to bind TLS certificates to domain names, potentially replacing Certificate Authorities. The idea was elegant: if DNSSEC secures DNS, and DNS records specify the correct certificate, you don't need to trust hundreds of CAs. In practice, DANE adoption for HTTPS has been negligible, though it has found a niche in email (SMTP with DANE).
CDS and CDNSKEY records finally automated the parent-child trust chain¶
One of DNSSEC's biggest operational headaches was updating DS records in the parent zone when rolling keys — this typically required manual action through the domain registrar's web interface. RFC 7344 introduced CDS and CDNSKEY records that allow child zones to signal key changes to the parent automatically. This automation, slowly adopted by registrars since 2017, has significantly reduced the operational burden.