Dr.Who
← blog

Should you enable DNSSEC? The benefits and the real risks

· dnssec · dns · security · registrar · spoofing

dnssecdnssecurityregistrarspoofing

Enable DNSSEC if your DNS host or registrar offers one-click managed signing — they handle the key rollovers and the registrar DS record stays in sync automatically, so you get the security with almost no operational risk. Be cautious if you would have to manage keys by hand: a botched rollover, an expired RRSIG, or a DS record that no longer matches your DNSKEY returns SERVFAIL, which knocks your domain completely offline for everyone behind a validating resolver. The blast radius of a mistake is often larger than the threat DNSSEC mitigates, so the decision hinges entirely on who operates the keys.

What DNSSEC actually buys you

DNSSEC cryptographically signs every DNS answer for your zone. A validating resolver can then verify that the A, MX, or TXT record it received is exactly what you published and was not altered in transit. That defeats cache poisoning and on-path DNS spoofing — the attacks where someone injects a forged answer to silently redirect your traffic.

The chain of trust runs from the root down: the parent zone (your TLD) publishes a DS record that fingerprints your DNSKEY, your DNSKEY signs your records as RRSIG, and the resolver walks that chain to the trust anchor. Break any link and validation fails closed.

It is also not optional everywhere — NIST SP 800-81 and OMB mandates require DNSSEC for US federal civilian agency domains. If you sell into that market, it is table stakes.

What it does not buy you

DNSSEC authenticates DNS data; it does not encrypt it. Anyone on the path can still see which domains you look up — DNSSEC only guarantees the answer was not forged. For privacy you need DNS over HTTPS or DNS over TLS, and for the actual web traffic you still need a TLS certificate. DNSSEC complements TLS; it does not replace it.

The real risk: SERVFAIL

This is the part vendors gloss over. Every signature has an expiry, every key eventually rolls, and the parent's DS record must always match your current DNSKEY. Miss any of those and validating resolvers return SERVFAIL instead of your records — your site, mail, and APIs go dark for roughly the third of users behind a validating resolver (most large ISPs, 8.8.8.8, and 1.1.1.1 all validate).

Check the chain with the AD (Authenticated Data) flag:

dig +dnssec example.com
dig DS example.com @8.8.8.8

If dig +dnssec shows RRSIG records and the AD flag is set, validation works. If a validating resolver returns SERVFAIL but dig +cd (checking-disabled) returns the record, the chain is broken — almost always a stale DS at the registrar or an expired signature.

The verdict

Turn it on when your provider runs it for you. Cloudflare, Route 53, and most modern registrars offer managed DNSSEC: you click a button and they automate signing, rollovers, and DS publication. That is the sweet spot — real protection, near-zero chance of self-inflicted downtime.

Hold off, or staff for it, if enabling DNSSEC means hand-editing key files and pasting DS records into a registrar portal on every rollover. The failure mode is total outage, and it tends to strike weeks later when a signature quietly expires.

Check your domain's DNSSEC chain →

Further reading