What is DNSSEC and Should You Care?

Why DNS needs signatures in the first place

The original DNS protocol was designed in 1983 and authenticated nothing. A response packet arrives at your resolver claiming to be the answer for example.com, and the resolver takes it at face value. For most of the internet's history that was fine, because spoofing a response required either being on-path or guessing the right transaction ID and source port within a tight window.

Dan Kaminsky's 2008 disclosure changed that. He showed that with the right query pattern you could brute-force the 16-bit transaction ID in seconds and inject forged answers into any resolver's cache — a class of attack now called cache poisoning. Operators patched around it with source-port randomization, but the underlying weakness — DNS having no notion of authenticity — remained. DNSSEC is the long-term fix that closes it cryptographically rather than statistically.

With DNSSEC enabled, every response carries a signature (RRSIG) that the resolver can verify against a key it can also obtain from DNS (DNSKEY), which is in turn vouched for by a key one zone up (DS), all the way to a single trust anchor at the root that every validator has baked in. A forged answer either lacks a signature or carries one that won't verify — and the resolver throws it away.

The chain of trust, in pictures

The trickiest mental model in DNSSEC is the chain of trust: each zone signs the keys of the zone below it, so verifying a single answer ends up traversing every link from the leaf domain back up to the root. The widget below makes the moving parts concrete — click any zone to see what records live there and what role they play.

Two practical consequences worth internalising: first, DS records live in the parent zone, not the child. To enable DNSSEC for your domain you publish the DS at your registrar (who passes it to the TLD), not at your own name server. Second, the root's KSK is the single point of trust for the entire internet — operating its rotations is famously handled by ICANN with multiple human key holders and a ceremony recorded on video twice a year.

What gets signed, and what doesn't

DNSSEC signs record sets (RRsets), not individual answers. When you query example.com A, the answer comes back with an RRSIG that covers the entire A RRset for that name. The signature is computed over the canonical form of the records plus some metadata (validity window, signer name, key tag), so an attacker cannot drop or substitute even a single IP.

What DNSSEC does not protect:

• Confidentiality. DNS queries themselves are still readable on the wire. That is what DNS-over-HTTPS and DNS-over-TLS are for; they are orthogonal to DNSSEC and you want both.
• The last mile. The signature is between the authoritative server and the recursive resolver. From the resolver to your laptop you are back to plaintext DNS unless you also run DoH/DoT or your OS does validation locally.
• Unsigned zones. If a zone has no DS at its parent, DNSSEC says “this is provably unsigned” — not “the answer is bad”. The resolver still returns it. Most domains on the planet are still unsigned, which limits the floor of protection.

Does your resolver actually validate? Find out.

There is a meaningful gap between “DNSSEC is deployed for your domain” and “DNSSEC protects your laptop”. The protection only kicks in if the resolver between your device and the root is doing the validation. ISPs in the US and EU mostly do; many mobile carriers do not; corporate DNS varies wildly; public resolvers like 1.1.1.1, 8.8.8.8, and Quad9 all validate by default. The widget below runs the standard test — fetching a host whose signatures are intentionally broken and seeing whether your resolver lets it through.

Adoption: who's signed, who isn't

The root has been signed since 2010 and every active TLD has been signed since around 2018. At the leaf, however, adoption is uneven. ccTLDs in northern Europe lead — .se, .nl, .cz, and .br sit between 50 % and 90 % signed at the second level. .com, despite being the largest namespace by far, hovers near 5 %. The picture is starkly different for big providers: Cloudflare-hosted domains, Route 53 with a one-click toggle, and many enterprise platforms have lifted that number in their own customer bases.

On the resolver side, validating is more widespread than signing. The major public DNS providers all validate; APNIC's monthly measurement puts global validating-resolver share around the one-third mark, with very high adoption in Iceland, Sweden, the Czech Republic, Greece, and Taiwan, and stubbornly low numbers in much of the rest of the world.

Common gotchas when you enable it

• Mismatched DS at the parent. The single most common DNSSEC outage is publishing a new DS at the registrar without keeping the old one around long enough for caches to expire — or vice versa. Rolling keys safely requires a controlled overlap window.
• Expired signatures. RRSIGs have a hard validity window (typically a few days to a few weeks). If your signing pipeline stops, every signed answer goes invalid and your zone disappears from validating resolvers. Monitoring for “signatures expiring in N days” is mandatory.
• NSEC vs NSEC3 zone walking. NSEC records reveal the full sorted set of names in a zone. Use NSEC3 with a high enough iteration count if you do not want curious clients enumerating your zone via DNSSEC.
• Algorithm rollover. Moving from RSASHA256 to ECDSA P-256 or Ed25519 is a full key change, not a re-sign. The procedure is well documented but it is the one place DNSSEC operators most often get it wrong.