DNSSEC

Ordinary DNS has no integrity check. When a resolver asks for a domain's A record or TXT record, it has no way to verify that the answer it receives actually came from that domain's real nameservers rather than from an attacker in a position to intercept or inject responses — on a compromised network, a poisoned resolver cache, or a man-in-the-middle position. The resolver just trusts whatever comes back. DNSSEC fixes this by having every DNS answer signed, and by chaining that signature back to a root of trust the resolver already trusts, so a forged answer fails verification instead of being silently accepted.

How the chain of trust works

DNSSEC works by signing zone data with a private key and publishing the corresponding public key in DNS, then repeating that one level up. Your domain's zone is signed with a Zone Signing Key, and a hash of your zone's public key — the DS record — is published in the parent zone (the TLD, e.g. .com) alongside your NS records, signed with the TLD's own key. The TLD's key is in turn vouched for by the DNS root, which resolvers trust by configuration rather than by chaining any further. A resolver that supports DNSSEC follows this chain for every answer: verify the domain's record against its published key, verify that key is the one the parent zone said it should be, verify the parent zone's key against the root. If any link breaks, the resolver returns SERVFAIL instead of the answer, rather than passing along something it can't verify.

Turning it on

Enabling DNSSEC is two separate steps, done in two different places, and both are required:

• •Enable signing at your DNS host (Cloudflare, Route 53, your registrar's own DNS, whichever actually hosts your records) — this generates the keys and starts signing your zone.
• •Publish the resulting DS record at your registrar — the place you bought the domain, which may or may not be the same company that hosts your DNS. This is the step that's easy to miss, because it happens in a completely different dashboard.

Most managed DNS providers walk through both steps as one flow and hand you the exact DS record to paste at your registrar, but the two-dashboard nature of it is exactly why partial DNSSEC setups are common: signing enabled at the host, but the DS record never actually reached the registrar, which means nothing is actually protected — the zone isn't in the trust chain at all, silently.

The failure mode that matters most: this can take your domain offline

Unlike most of the checks on this site, a DNSSEC misconfiguration isn't just a missed opportunity for extra security — it can make your entire domain unreachable. If a DS record is published at the registrar but the corresponding zone signing subsequently breaks (an expired signature, a key rotation done incorrectly, a DNS provider migration that didn't carry the signing setup over), DNSSEC-validating resolvers — which by now includes most major public ones — will refuse to return any answer for the domain at all, for every record type, to every visitor. This is called going "bogus," and it's a genuinely common cause of sudden, mysterious total outages, especially around DNS provider migrations where the new provider doesn't automatically continue signing with the same keys the old DS record referenced.

• •Before migrating DNS providers, remove the DS record at the registrar first, wait for the change to propagate, migrate, then re-enable DNSSEC and publish a new DS record at the new provider. Migrating DNS with an active DS record still in place is the single most common way DNSSEC breaks a domain.
• •Key rotation should be done through your provider's supported rotation flow, not by manually swapping keys — an old DS record pointing at a retired key looks identical to a broken chain from the resolver's point of view.
• •If DNSSEC is not enabled at all, that's a real but modest gap: cache poisoning and on-path DNS forgery are real attack classes, just not the most common ones most domains face day to day.

Proving a name doesn't exist

DNSSEC has to sign negative answers too — proof that a given name genuinely has no record, not just an unsigned absence an attacker could forge just as easily as a fake positive answer. The original mechanism, NSEC, does this by having each signed name point to the next name in the zone alphabetically, which means walking every NSEC record in sequence reveals the entire contents of the zone, one name at a time, even names that were never meant to be publicly enumerable. NSEC3 fixes this by hashing names before chaining them, so proving non-existence no longer means handing over a readable list of everything else in the zone. Almost every modern DNS host defaults to NSEC3 today, but it's worth knowing which one a provider uses if zone enumeration specifically is a concern — an internal subdomain naming scheme, for instance, that you'd rather not have trivially listable.

Enable it deliberately, verify the DS record actually reached the registrar, and treat any future DNS migration as an operation that has to account for it — not something to enable once and never think about again.