DNSSEC in Plain English

DNSSEC is one of those technologies that sounds essential in theory but has significant real-world tradeoffs. This guide explains what it does, when it helps, and why many organizations choose not to deploy it.

What DNSSEC does

DNS was designed without any authentication. When your browser asks "what's the IP address of example.com?", it trusts whatever answer it receives — even if that answer came from an attacker. DNSSEC adds cryptographic signatures to DNS responses so resolvers can verify they haven't been tampered with.

The chain of trust

DNSSEC works through a hierarchical chain of trust, starting from the DNS root zone:

1. The root zone is signed by ICANN (the root key is the "trust anchor" that everything else chains to)
2. The .com zone is signed by Verisign. The root zone contains a DS record that validates .com's signing key
3. Your zone is signed by your DNS provider. The .com zone contains a DS record that validates your signing key
4. Individual records (A, MX, TXT, etc.) in your zone are signed with your zone key. Each record has an RRSIG that resolvers can verify

A validating resolver walks this chain from the root to your domain, verifying signatures at each step. If any signature is invalid or missing, the response is rejected.

What DNSSEC protects against

• Cache poisoning: An attacker forges DNS responses and injects them into a resolver's cache, redirecting traffic to malicious servers
• Man-in-the-middle at the DNS layer: An attacker intercepts DNS queries and returns forged responses
• BGP hijacking of DNS: An attacker reroutes DNS traffic through their network and serves fake responses

What DNSSEC doesn't protect against

• DNS provider compromise: If your DNS provider is hacked, the attacker can sign fake records with your keys
• Registrar takeover: If someone gains access to your registrar account, they can change nameservers and DS records
• Last-mile attacks: DNSSEC doesn't protect the connection between the user and the resolver. DNS over HTTPS (DoH) or DNS over TLS (DoT) addresses this.
• Confidentiality: DNSSEC signatures are public. It doesn't encrypt DNS queries or responses.

The tradeoffs

• Operational complexity: DNSSEC requires key management — key generation, rotation, and emergency procedures if keys are compromised. Misconfigured DNSSEC can make your domain completely unreachable.
• Larger DNS responses: Signatures add significant size to DNS responses, increasing bandwidth and potentially causing issues with firewalls that block large DNS packets.
• Zone walking: NSEC records (used for authenticated denial of existence) allow attackers to enumerate all records in your zone. NSEC3 mitigates this but adds complexity.
• Limited resolver support: Not all DNS resolvers validate DNSSEC. Major public resolvers (Google, Cloudflare) do, but some ISP resolvers don't.

When to deploy DNSSEC

Consider DNSSEC if:

• Your DNS provider manages it automatically (many modern providers handle key management)
• You operate in a regulated industry that requires it
• You need DANE for email TLS certificate pinning
• Your threat model includes DNS-layer attacks

Skip DNSSEC if:

• Your DNS provider doesn't support it or requires manual key management
• You lack operational capacity for key rotation procedures
• The risk of misconfiguration outweighs the risk of DNS attacks for your use case