Ordinary DNS follows the delegation, asks the servers expected to be authoritative, and accepts a response when it matches the outstanding query and passes basic validation checks. Those checks help resist spoofing, but they don’t verify that the DNS data is authentic.
DNS Security Extensions add cryptographic validation. Signed zones publish keys and signatures alongside their normal records, so a validating resolver can confirm that an RRset was signed by the expected zone and was not altered in transit. The normal delegation and resolution process still applies. DNSSEC adds a way to verify the authenticity and integrity of the answer.
DNSSEC signs the records themselves
DNSSEC doesn’t set up a secure session, encrypt a channel, or authenticate a server connection. It signs data.
Records sharing an owner name, type, and class form a resource record set (RRset). A signed zone publishes at least one RRSIG for each of its authoritative RRsets, and the resolver verifies that signature with the matching DNSKEY public key:
www.example.com. 300 IN A 192.0.2.25
www.example.com. 300 IN RRSIG A ...That RRSIG covers the A RRset itself, not the packet carrying it, the connection, or the resolver that asked. That’s why the data survives the journey. It can pass through recursive resolvers, caches, and forwarders and still validate at the far end, because validation depends on the records rather than on preserving one path from the authoritative server.
Not everything in a zone file gets signed. Delegation NS records and the glue addresses that accompany them are the parent’s non-authoritative copies, so they carry no signatures.
Validation needs a trusted starting point
A signature is only useful if the verifier already knows which key deserves trust. DNSSEC solves that by chaining trust down the hierarchy from a trust anchor, key material the resolver is configured with independently of any answer it validates. In common deployments that means one or more root-zone keys, usually maintained through automated trust-anchor rollover.
From there each level authenticates the next, so the resolver ends up with a cryptographic reason to trust the key that signed the record it actually wanted. No separate certificate authority is involved, and the chain runs through the same zones DNS already uses.
DS records join parent to child
The Delegation Signer (DS) record is the link. It lives in the parent zone, carries a digest computed over the child’s DNSKEY owner name and key data along with identifying fields, and is signed by the parent’s own key. When a resolver arrives at the child, it compares the child’s DNSKEY against that authenticated DS record, and a match extends the chain downward.
This is also why DNSSEC deployment crosses an administrative boundary and why it breaks in the ways it does. Signing your zone isn’t enough on its own. To join the ordinary chain the parent has to publish a matching DS record, so a child can be busily publishing DNSKEY and RRSIG records and remain an island of security that no chain from the root can reach.
RRSIG lets a resolver detect tampering
The RRSIG carries a signature computed over the RRset in canonical form plus the RRSIG’s own metadata. A validating resolver reconstructs that canonical form and checks it against the appropriate DNSKEY. Unauthorized changes to the signed data break the check. The ordinary transformations DNS performs in transit, like TTLs counting down in caches and records arriving in a different order, don’t.
Signatures are also time-bounded. RRSIG records carry inception and expiration times that the resolver honors. That makes clock accuracy operationally relevant, because a badly wrong resolver clock can render perfectly good signatures either expired or not yet valid.
Negative answers can be authenticated too
Sometimes what a resolver needs is proof that something doesn’t exist. Plain DNS returns NXDOMAIN, or a negative answer meaning the name exists without that record type, and carries no proof of origin for either.
DNSSEC provides authenticated denial of existence through NSEC and NSEC3 records, letting a validating resolver confirm the signed zone really is asserting absence. Without it, an off-path attacker could make an existing signed name simply disappear by forging a denial. NSEC points at ranges in the ordered zone namespace directly, while NSEC3 uses hashed owner names, introduced partly to make casual zone enumeration harder. NSEC3 isn’t a confidentiality mechanism, though. A determined attacker can collect the hash chain and test likely names offline, which is why current guidance treats the protection as moderate.
Validation has four outcomes
A validating resolver sorts DNS data into more than pass and fail. The core specifications define four security states:
- Secure: a chain of trust runs from a trust anchor to the data, and the required signatures verify.
- Insecure: the resolver established that no chain of trust exists here, normally by authenticating the absence of a DS record at a delegation.
- Bogus: the resolver believes a chain should be establishable, and validation fails or the required DNSSEC records are missing.
- Indeterminate: the resolver can’t tell whether the data ought to be signed, typically because no applicable trust anchor covers it.
The distinction that matters operationally is insecure versus bogus. An unsigned zone isn’t a DNSSEC failure, and a properly delegated unsigned branch resolves perfectly normally. Bogus means the resolver expected this data to validate and it didn’t, which it’s expected to treat as a failure.
example.com, pointing at the child's key-signing key. If the child retires that key before a replacement DS has propagated at the parent, the chain breaks and answers go bogus even though the authoritative servers are reachable and happily serving ordinary DNS records. Rolling only the zone-signing key is less risky by comparison, because the parent's DS doesn't reference it, though cached signatures still need time to age out.
Validation usually happens at the resolver
Few applications validate a full chain themselves. A security-aware recursive resolver does the work and reports the result, setting the Authenticated Data (AD) bit when it considers the answer data and any relevant negative authority data authentic.
That signal only means something inside the trust relationship between a client and its resolver. A stub that accepts an AD bit arriving over an untrusted path has relocated the trust problem rather than solved it, an issue the specifications call out directly as the last-hop problem.
A validating resolver normally returns SERVFAIL for data it considers bogus, while a non-validating resolver hands over the same records without complaint, so comparing the two paths points at DNSSEC quickly. But SERVFAIL alone proves nothing, since timeouts, unreachable servers, and assorted other failures return it too. Setting the CD bit to request the data anyway, or reading Extended DNS Errors, is what narrows the cause to DNSSEC.
DNSSEC doesn’t encrypt anything
Signatures authenticate, but they don’t conceal. Query names, record contents, and the DNSSEC records themselves stay visible on ordinary transports. DNS over TLS and DNS over HTTPS can provide confidentiality, integrity, and resolver authentication for one transport hop, which is a different problem from authenticating data end to end.
The relationship runs both directions. An encrypted connection to a resolver proves nothing about whether an unsigned authoritative answer is authentic. The two protect different parts of the system, which is why they complement each other rather than compete.
What a valid signature actually proves
A signature that validates under the chain of trust proves that the zone published this record and that what validated matches what was signed.
A signed A record can point at a phishing page. A signed MX record can front infrastructure built for abuse. A signed domain can serve malware all day while its records validate perfectly the entire time. DNSSEC authenticates provenance, not intent.
This is the same boundary described in why attackers use DNS. DNS is a naming system, and DNSSEC makes the naming data trustworthy without making any judgment about the thing being named. Deciding whether a destination deserves to be reached is filtering’s job, and the two work at different layers for different reasons.
Summary
DNSSEC adds origin authentication and integrity by signing DNS data and building a chain of trust through the DNS hierarchy. A validating resolver classifies each answer as secure, insecure, bogus, or indeterminate, and the insecure-versus-bogus distinction is the one that decides whether anything is actually broken.
For cache poisoning, this means a forged response must also pass DNSSEC validation before it can be accepted. Keep in mind, DNSSEC doesn’t encrypt DNS traffic or tell you whether a signed destination is safe.