DNSSEC Explained: How DNS Records Are Authenticated

Classic DNS has no built-in way to authenticate an answer. A resolver sends a query, accepts the first plausible-looking response, and caches it. There is no signature, no proof of origin, and no integrity check — so a forged reply that arrives at the right moment is indistinguishable from the real thing.

That weakness enables cache poisoning (also called DNS spoofing): an attacker injects a fraudulent record into a resolver's cache, and every user of that resolver is then steered to an attacker-controlled server — for a website, a mail host, or anything else the domain points to. Because the poisoned record is cached, a single successful injection can affect many users until the record's TTL expires.

DNSSEC addresses exactly this: it lets a resolver verify that the records it received were published by the domain's real operator and were not modified in transit. A forged answer simply won't carry a valid signature, so a validating resolver can reject it.

DNSSEC is a set of extensions to DNS — defined in RFC 4033, 4034, and 4035 — that add cryptographic signatures to DNS data. A zone operator signs the records in their zone with a private key and publishes the corresponding public key in DNS. A validating resolver can then check each answer's signature against that key and confirm two things:

• Origin authentication — the data really was published by the zone that's supposed to own it.
• Data integrity — the data wasn't altered between being signed and being received.

What DNSSEC deliberately does not do is just as important:

• It does not encrypt anything. DNSSEC-signed records — and the queries that fetch them — travel in the clear. Anyone on the path can still see which domains you look up. Confidentiality is the job of DoH/DoT, not DNSSEC.
• It does not change the answers themselves. A signed A record returns the same address as an unsigned one; DNSSEC just lets the resolver prove that address is genuine.

Think of DNSSEC as a tamper-evident seal on DNS data, not a sealed envelope.

DNSSEC introduces a handful of new record types that work together. You rarely edit these by hand — your DNS host generates them when you sign the zone — but understanding what each one is for makes the rest of DNSSEC much clearer.

Record	Lives in	Purpose
RRSIG	The signed zone	A cryptographic signature over a set of records (an "RRset"). Proves that RRset is authentic and unmodified.
DNSKEY	The signed zone	The zone's public key(s). Resolvers use these to verify the zone's RRSIG signatures.
DS	The parent zone	Delegation Signer: a hash of a child's DNSKEY, published by the parent to vouch for the child's key and link it into the chain of trust.
NSEC / NSEC3	The signed zone	Authenticated denial of existence — a signed, verifiable way to prove that a name or record type genuinely does not exist.

A few details worth holding onto:

• An RRSIG covers an RRset (all records of one type at one name), not a single record, and it carries validity dates — signatures expire and must be refreshed.
• The DS record is the linchpin of delegation: it lives in the parent zone, not the child, which is why publishing it is a separate step from signing (more below).
• NSEC3 (RFC 5155) is a hashed variant of NSEC that makes it harder to "walk" a zone and enumerate every name in it. Both let a resolver trust a "this doesn't exist" answer instead of taking it on faith.

DNSSEC's signatures are only meaningful if you can trust the keys that made them. DNSSEC solves this with a chain of trust that follows the same hierarchy as DNS delegation itself.

At the top sits the root zone, whose key is the trust anchor — a public key that validating resolvers are configured to trust inherently. From there, each level vouches for the one below it:

1. The root zone publishes a DS record for each top-level domain (TLD), derived from that TLD's DNSKEY.
2. The TLD (for example .com) in turn publishes a DS record for your domain, derived from your domain's DNSKEY.
3. Your domain (example.com) signs its own records and publishes its DNSKEY.

A validating resolver walks this chain from the bottom up: it checks your records against your DNSKEY, confirms your DNSKEY matches the DS in the TLD, confirms the TLD's key matches the DS in the root, and confirms the root key against its trust anchor. If every link holds, the answer is trusted. Each DS record in a parent zone is what ties a child's keys into the chain — break that link and validation for the child fails.

Conceptually a zone uses two roles of signing key, which lets operators rotate keys without re-coordinating with the parent every time:

• The Key-Signing Key (KSK) signs only the DNSKEY RRset — the set of the zone's public keys. The KSK is the key the parent's DS record points at, so it's the anchor of the zone within the chain of trust.
• The Zone-Signing Key (ZSK) signs all the other records in the zone (the A, MX, TXT records, and so on).

The payoff: because only the KSK is referenced by the parent's DS, the operator can roll the ZSK frequently and freely without touching anything at the registrar, and roll the KSK on a slower schedule when the DS does need updating. (Some setups simplify this to a single Combined Signing Key — a CSK — that plays both roles; the KSK/ZSK split is conceptual, not mandatory.)

When a DNSSEC-aware (validating) resolver receives a signed answer, it does roughly the following:

1. Fetch the requested RRset along with its RRSIG signature.
2. Fetch the zone's DNSKEY and verify the RRSIG was produced by the matching key and is still within its validity dates.
3. Walk up the chain of trust — confirm the zone's key matches the DS in the parent, and so on up to the root trust anchor.
4. If every signature and link validates, return the answer as authenticated.

And critically, if any step fails — a missing, expired, or mismatched signature, or a broken link in the chain — the resolver does not fall back to the unsigned answer. It treats the data as untrustworthy and returns SERVFAIL to the client. From the user's point of view, the domain simply fails to resolve. That fail-closed behavior is what makes DNSSEC protective, and also what makes a misconfiguration so disruptive.

DNSSEC is narrowly scoped on purpose. Knowing its limits keeps you from relying on it for things it was never meant to do:

• It does not encrypt your queries. Observers can still see which domains you look up. For privacy on the wire you want DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) — separate technologies that solve confidentiality, not authenticity.
• It does not stop DDoS attacks. DNSSEC does nothing to protect your nameservers from being flooded with traffic — and because signed responses are larger, DNSSEC can even be abused as an amplification vector.
• It does not protect a compromised registrar or DNS account. If an attacker takes over your registrar login or DNS host and re-signs the zone with their own keys, the records will validate perfectly — they're "authentically" wrong. DNSSEC authenticates data, not the humans and accounts behind it.
• It does not secure the application layer. It says nothing about TLS certificates, HTTPS, or whether the server you reach is honest once you get there.

DNSSEC answers exactly one question — "did this DNS data really come from the zone that owns it, unaltered?" — and answers it well. It is one layer in a defense-in-depth stack, not a complete one.

Turning DNSSEC on is a two-part operation, and getting only one part done is worse than doing nothing:

1. Sign the zone at your DNS host. Your DNS provider generates the keys, signs your records (producing the RRSIG, DNSKEY, and NSEC/NSEC3 records), and serves the signed zone. This is usually a single toggle in the provider's control panel.
2. Publish the DS record at the registrar (the parent). Your DNS host gives you the DS record (or the DNSKEY details to build it); you enter it at your domain registrar, which passes it to the TLD's parent zone. This is the link that ties your signed zone into the chain of trust.

Both halves must be present and must match. Signing the zone without publishing a DS means no resolver knows to validate you — DNSSEC is effectively off. Publishing a DS that doesn't match your actual keys is far worse: validating resolvers will try to verify, fail, and return SERVFAIL, taking your domain offline for those users.

If your DNS host and your registrar are the same company, this is often a single one-click action; when they're different, you must coordinate the two steps yourself, and a clean key change should propagate the new DS before retiring the old key.

The same fail-closed design that makes DNSSEC protective makes it unforgiving. Any of these can make your domain stop resolving for validating resolvers:

• Expired signatures. RRSIG records have validity dates and must be re-signed before they lapse. If the automated re-signing breaks and a signature expires, validation fails.
• A mismatched DS. If you roll your keys at the DNS host but the DS at the registrar still points at the old key (or vice versa), the chain of trust breaks.
• Moving DNS hosts carelessly. Transferring a signed domain without first coordinating the keys and DS across the old and new providers is a classic way to take a domain down.

Note the failure is selective and confusing: users behind non-validating resolvers see the site fine, while users behind validating resolvers get SERVFAIL and a domain that appears completely dead. That makes DNSSEC outages hard to diagnose. The mitigations are to let a reputable DNS host manage signing and key rollovers automatically, and to change keys and DS records carefully and in the right order.

You can confirm a domain's DNSSEC status with a DNS lookup. On who.is, use the DNS lookup tool: enter the domain and look for the DNSSEC-related records — a signed zone will publish DNSKEY and RRSIG records, and a domain wired into the chain of trust will have a DS record at its parent.

It's also worth checking the domain's nameservers and WHOIS data so you know which provider is authoritative — that's the provider that signs the zone and supplies the DS you publish at the registrar. If you've just enabled DNSSEC, remember that the DS record, like any DNS change, is subject to caching and propagation delays before every resolver sees it.