DNSSEC: What It Actually Protects Against and Why Most Domains Skip It

DNSSEC signs DNS records cryptographically — protecting against cache poisoning (Kaminsky's 2008 attack) but doing nothing about registrar account compromise, BGP hijacking, or misconfigured records. Here's how DNSSEC's chain of trust works (root → TLD → domain), why expired RRSIG signatures cause SERVFAIL for DNSSEC-validating resolvers including Google and Cloudflare, and why only ~3-5% of .com domains have DNSSEC despite most TLDs being signed.

DNSSEC adds cryptographic signatures to DNS records — but it solves a specific problem (records being tampered with in transit) while doing nothing about the problems that cause most real-world DNS failures: misconfiguration, registrar account compromise, and the BGP hijacking that redirects traffic before DNS is ever involved

The previous articles on this site covered DNS record types, DNS security threats, DNS propagation and TTLs, DNS over HTTPS, and the four-layer DNS cache. This article addresses DNSSEC in practice — what it actually protects against, the operational complexity it introduces, and why many organisations choose not to implement it despite its theoretical security benefits.

What DNSSEC actually protects against

DNSSEC (DNS Security Extensions) adds digital signatures to DNS responses. A DNSSEC-validating resolver verifies that the record received matches a signature made by the authoritative nameserver — detecting if the record was tampered with between the authoritative server and the resolver.

The specific attack DNSSEC addresses: DNS cache poisoning.

Kaminsky's attack (2008): Dan Kaminsky discovered a vulnerability allowing an attacker to inject false DNS records into resolvers' caches without controlling the authoritative nameserver. By flooding a resolver with forged responses during a query, an attacker could redirect a domain's traffic to an attacker-controlled IP for all users of that resolver.

DNSSEC's protection: if DNSSEC is deployed for a zone, the resolver can verify the signature on any record. A forged record without a valid signature is rejected. Kaminsky's attack doesn't work against DNSSEC-validating resolvers querying DNSSEC-signed zones.

What DNSSEC doesn't protect:

Compromised authoritative nameserver (attacker can sign with the real key)
Registrar account compromise (attacker changes NS records legitimately)
BGP hijacking (traffic is redirected before DNS resolves)
Malicious ISPs or DNS providers (they hold the keys)
Misconfigured DNS records (DNSSEC signs whatever is in the zone, including mistakes)

The chain of trust: how DNSSEC validates

DNSSEC builds a chain of trust from the DNS root downward:

Root zone: signed by ICANN. All DNSSEC-validating resolvers have the root zone's public key (KSK — Key Signing Key) built in as a trust anchor.
TLD zone (.com, .uk, .org): root zone contains a DS (Delegation Signer) record for each signed TLD, creating a cryptographic link.
Domain zone (example.com): the TLD zone contains a DS record for example.com, which is the hash of example.com's DNSKEY. Records in the example.com zone are signed by example.com's ZSK (Zone Signing Key).

Validation flow: a resolver asks for mail.example.com. It receives the A record plus an RRSIG (Resource Record Signature). It follows the chain: verifies the RRSIG using example.com's DNSKEY, verifies the DNSKEY using the DS record in the .com zone, verifies that DS record using the .com zone's own signature, ultimately traced back to the root trust anchor.

SERVFAIL on validation failure: if the chain breaks at any point (expired signature, misconfigured DS record, wrong key), DNSSEC-validating resolvers return SERVFAIL — treating the domain as completely unresolvable rather than returning an unverified answer.

DNSSEC operational complexity: the practical challenges

DNSSEC introduction significantly increases DNS operational complexity:

Key management: DNSSEC zones have two key types — ZSK (Zone Signing Key, signs zone records, rotated more frequently) and KSK (Key Signing Key, signs the DNSKEY record, rotated less frequently). Rotation of either requires careful coordination with the parent zone to avoid validation failures during the transition.

Signature expiration: DNSSEC signatures (RRSIG records) have an expiry date — they must be regularly re-signed before expiration. If re-signing fails (automation error, key storage issue), the zone becomes SERVFAIL for all DNSSEC-validating resolvers. This is an invisible, silent failure with no obvious symptom except "the domain stopped working."

DNSSEC signing outage incidents: several major organisations have experienced DNSSEC-related outages. In 2016, the Swedish .se TLD went SERVFAIL for several hours due to an expired RRSIG. Individual domain operators have similarly experienced outages from automation failures.

TTL and negative caching: DNSSEC-signed negative responses (NSEC/NSEC3 records for nonexistent names) are cached with their TTL. This can slow DNS propagation for newly added records in signed zones.

DNSSEC adoption: who has implemented it and who hasn't

DNSSEC adoption statistics (2024 approximate):

TLD signing: most major TLDs (.com, .net, .org, .uk, .de, .nl, etc.) are signed
Resolver validation: Google's public DNS (8.8.8.8) and Cloudflare's (1.1.1.1) both validate DNSSEC
Domain signing: approximately 3-5% of .com domains have DNSSEC enabled

Why adoption remains low among domain operators:

Hosting providers and registrars have varying support — not all provide easy DNSSEC management
Perceived complexity and outage risk outweighs the benefit for most operators
The primary attack DNSSEC prevents (cache poisoning) has been largely mitigated by other means (DNS randomisation, 0x20 bit encoding, DANE)

Who benefits most from DNSSEC: domains with high-value DNS records (financial institutions, government, healthcare), email authentication infrastructure (DANE TLSA records for email encryption), and high-profile targets for DNS-based attacks.

How to use the DNS Lookup on sadiqbd.com

Check DNSSEC signing: query for DNSKEY records to see if a domain has DNSSEC enabled; query for RRSIG records to verify signatures are present on specific record types
Diagnose SERVFAIL: if a domain returns SERVFAIL and DNSSEC is enabled, expired RRSIG records or a DS record mismatch at the parent zone are the most likely cause — the lookup tool shows the current state to identify which layer is broken
Compare propagation: query the same record from different vantage points (different resolvers) to see propagation status — DNSSEC validation failures may appear on some resolvers but not others depending on their caching state

Frequently Asked Questions

If my domain has DNSSEC enabled and my RRSIG expires, does my website stop working for everyone? Yes — for resolvers that validate DNSSEC, which now includes most major public resolvers. Expired RRSIG records cause DNSSEC-validating resolvers to return SERVFAIL. Google (8.8.8.8), Cloudflare (1.1.1.1), and most ISP resolvers validate DNSSEC. Resolvers that don't validate (some corporate and legacy ISP resolvers) continue to work. The result: your domain appears to work for some users but completely fails for others — one of the most confusing failure modes in DNS. If you enable DNSSEC, ensure your signing automation (via your DNS provider's DNSSEC automation, or a tool like OpenDNSSEC) is reliable and monitored, with alerts for upcoming signature expiration.

Is the DNS Lookup free? Yes — completely free, no sign-up required.

Try the DNS Lookup free at sadiqbd.com — query any DNS record type for any domain instantly.