DNSSEC basics: cryptographically signing your DNS

What DNSSEC actually defends against

DNS, by default, is unauthenticated. A resolver asks “what’s the A record for example.com?” and trusts whatever answer comes back. An attacker positioned anywhere on the path between the resolver and the authoritative nameserver — a hostile coffee shop wifi, a hijacked router, a BGP rerouter — can forge a response and send your users to a fake IP.

DNSSEC fixes this by cryptographically signing every record. The resolver doesn’t just get an answer; it gets an answer plus a signature it can verify against a chain of trust rooted at the DNS root zone. Forge an answer and the signature won’t verify; the resolver throws it away.

DNSSEC does not encrypt your DNS — anyone watching the wire still sees the query and the answer. For that you want DoT (DNS over TLS) or DoH (DNS over HTTPS). DNSSEC is purely about authenticity.

The chain of trust

DNSSEC works because every layer signs the layer below it:

1. The root zone is signed by ICANN. Its public key is hardcoded into every DNSSEC-aware resolver.
2. The root zone publishes a DS record for .com — a hash of .com’s signing key.
3. .com is signed. It publishes DS records for each customer domain that has DNSSEC enabled.
4. Your zone (example.com) is signed. Its signatures verify against the key whose hash is in the DS record published by .com.

If any link is broken — wrong DS at the parent, expired signatures, mismatched keys — every DNSSEC-aware resolver returns SERVFAIL. Your domain becomes unreachable for anyone whose resolver checks DNSSEC (which today includes most of Google’s 8.8.8.8, Cloudflare’s 1.1.1.1, Quad9, and many ISPs).

The records DNSSEC adds to your zone

• DNSKEY — the public keys used to sign your zone. Typically two: a Key Signing Key (KSK) and a Zone Signing Key (ZSK).
• RRSIG — signatures, one per record set per signing key. Every A, MX, TXT etc. gets its own RRSIG.
• DS — a hash of your KSK, published at the parent zone (.com, .net, etc.) via your registrar.
• NSEC / NSEC3 — authenticated denial-of-existence records. They prove “no such name” without enabling zone walking.

You don’t write these by hand. Your DNS provider generates and rotates them; you publish the DS at your registrar to complete the chain.

Turning DNSSEC on, step by step

1. Enable DNSSEC at your DNS provider. Cloudflare, Route 53, NS1, DNSimple, Hurricane Electric — almost all support it. The provider generates KSK and ZSK, signs your zone, and shows you the DS record values.
2. Copy the DS record to your registrar. This is the only manual step. The registrar publishes it at .com (or whatever TLD).
3. Verify the chain. Wait for the parent zone to refresh (usually under an hour). Then test with dig +dnssec example.com and look for the ad flag, or use DNSViz for a visual chain diagram.
4. Don’t skip step 3. Many providers will report DNSSEC as “active” on their side while the DS at the registrar still hasn’t been entered. The chain is broken and resolvers won’t validate — but no warning will fire until your old DNS responses fall out of cache and queries start failing.

The two failure modes that take domains offline

Failure 1: broken DS

You enabled DNSSEC at your DNS provider, but never published the DS at the registrar (or published the wrong values). Validating resolvers consider your zone broken because the chain doesn’t reach them. Non-validating resolvers (older home routers) work fine — which is why this often goes undetected until a customer on a major ISP complains.

Failure 2: missed key rollover

Keys rotate periodically. ZSK rolls every ~30 days; KSK rolls every 1–2 years. A KSK roll requires updating the DS at the registrar. If you miss it, the chain breaks. Most DNS providers handle ZSK rolls silently and prompt you at KSK rolls — but if you ignore the prompt, you eventually have a hard outage.

DNSCheckPro tracks both. We re-verify the chain on every snapshot and flag a missing DS, mismatched keys, or signatures within 7 days of expiration. We also alert on the registrar-side DS so you don’t miss a KSK roll.

Should you enable DNSSEC?

For most domains the answer is yes. It’s free at every reputable DNS provider, the operational overhead with modern automation is near-zero, and it removes a class of attack that would otherwise be invisible to you.

Skip DNSSEC if:

• Your DNS provider doesn’t support it (consider switching).
• Your registrar can’t accept DS records (consider switching).
• You can’t commit to monitoring it (because the failure mode is “domain offline” — silent broken DNSSEC is worse than no DNSSEC).

If you enable it, monitor it. We watch the chain so a missed KSK roll doesn’t become your worst Monday morning.

Related reading: DNS records explained covers the records DNSSEC signs. WHOIS vs RDAP covers the other half of “is my domain healthy” — registration expiry.