DNSSEC — what it signs, and what it does not protect you from
DNSSEC proves a DNS answer came from the owner of the zone, unaltered. It does not encrypt the query, and it says nothing about what your website serves.
DNSSEC, and the three things people assume it does
DNSSEC answers one question: did this DNS answer come from the owner of the zone, unaltered, or did somebody substitute it on the way? That is a genuinely useful property, and it is considerably narrower than the name suggests. This page says what is signed, what is not, and how a signing setup fails — because it fails in a way that looks like an outage.
What is actually signed
Each record set in a signed zone carries an RRSIG: a signature made with a key the zone publishes as a DNSKEY. The zone's parent holds a DS record, which is a hash of that key. A validating resolver starts at the root — which it trusts by configuration — and follows the chain down from one DS to the next zone's key until it reaches yours. If every link checks, the answer is authentic.
Non-existence is signed too, with NSEC or NSEC3. Without that, an attacker could simply make an answer disappear rather than forge one.
The stages, and where each one bites
| Stage | What it is | What goes wrong |
|---|---|---|
| Sign the zone | RRSIG over each record set, made by the zone-signing key | Signatures expire. A zone that stops being re-signed goes bad on a timer rather than immediately. |
| Publish the keys | DNSKEY inside the zone | A key published in the zone but not at the parent is the most common half-finished setup: signing exists and validates nothing. |
| Delegate trust | DS at the registry, matching that key | A DS pointing at a retired key makes the entire zone fail validation. |
| Authenticated denial | NSEC / NSEC3 | NSEC lets anyone walk the zone and enumerate its names; NSEC3 hashes them, which is why it is normally preferred. |
| Roll the keys | Replacing signing keys on a schedule | Doing the parent and the zone in the wrong order, or too quickly for the old TTL, is the classic self-inflicted outage. |
What DNSSEC does not do
| What people assume | What is true |
|---|---|
| It encrypts my DNS queries | It does not. Answers are signed, not sealed — anyone on the path can still see which names are being asked about. Encrypting the transport is a separate job, and a separate protocol. |
| It proves my website is legitimate | It proves the DNS answer is. A perfectly signed A record can point at a server serving anything at all. |
| It replaces TLS | It does not touch the connection to your site. You still need a certificate, and a padlock, for the same reason you always did. |
| It hides my domain's records | The reverse. Authenticated denial of existence makes the shape of the zone provable, which is precisely why NSEC3 exists. |
| It stops my domain being hijacked | It stops forged answers in flight. It does nothing about a compromised registrar account, a reused password, or an unlocked domain that gets transferred away. |
That last row is the one worth sitting with. DNSSEC protects the path between a resolver and an authoritative server. Ownership — your account, your registrar, the transfer lock — is a different system with different controls, and it is the one that decides who actually holds your name.
The failure mode to know before you enable it
Validation fails closed. If a validating resolver cannot build the chain — wrong DS, missing signature, expired signature — it does not shrug and return the answer anyway. It returns a failure, and the name does not resolve for anyone behind that resolver.
So a DNSSEC mistake is not a degraded state; for part of the internet it is a total one. It also presents unevenly, which is what makes it hard to diagnose: resolvers that validate go dark, resolvers that do not are perfectly fine, and "the site is down for some customers" is a far worse ticket than "the site is down".
Three rules follow, and they are all about ordering and patience. Never remove a DS record and repoint nameservers in the same step. Always wait out the old TTL after changing what the parent says. Never retire a key before its replacement is visible everywhere it needs to be.
Moving a signed zone
This is where transfers and DNSSEC collide. A signed zone cannot be moved by moving nameservers alone, because the parent's DS still points at the previous operator's key. Either the gaining side publishes the same key, or the DS has to come out of the registry first — and that removal has to be visible before the delegation moves. See also: the domain transfer guide.
How to check it
Ask for the signatures and look for the authentic-data flag:
$ dig example.com A +dnssec
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, ...The ad flag means the resolver validated the answer. Its absence on a zone you believe is signed is the symptom to chase, and an online validator will usually tell you which link in the chain is broken rather than only that one is.
The honest summary
DNSSEC removes one real attack — answer substitution — and it removes it well. It is worth having on, and on domains registered through Zeso it is available on every name, alongside anycast DNS and WHOIS privacy, with the signing and the DS publication handled so that the failure modes above are ours to manage rather than yours.
What it is not is a security badge for your website. It says nothing about what your server serves, and a green validation result beside a defaced page is still a green validation result.