DNSSEC Validation Makes DNS Tampering Detectable at the Resolver

A recursive resolver can receive a syntactically valid DNS answer from the network and still have no cryptographic evidence that the answer came from the zone responsible for the name. Transaction identifiers, source-port randomization, and transport controls make blind forgery harder, but they do not turn ordinary DNS records into authenticated data.

DNS Security Extensions add that missing property for signed portions of the namespace. Resource-record sets carry signatures, zones publish signing keys, and parent zones can bind child keys into a chain rooted in a configured trust anchor. A validating resolver can then classify data according to cryptographic evidence instead of accepting an answer solely because it arrived through the expected DNS exchange.

The boundary is precise. DNSSEC authenticates DNS data; it does not encrypt queries, conceal names, authenticate application servers, or make every operational failure safe.

Signatures attach integrity to RRsets

DNSSEC signs resource-record sets rather than individual DNS packets. An RRset groups records with the same owner name, class, and type. Its associated RRSIG record contains a signature over a canonical representation of that set plus signature metadata.

This distinction separates data authentication from transport. A recursive resolver may obtain records through several authoritative servers, cache them, and later answer a client without repeating the original network path. Validation concerns the signed DNS data and its authenticated key chain, not the identity of the server connection that happened to deliver a packet.

A valid RRSIG establishes that the signed RRset matches the data covered by a key whose authority the validator has established. It also carries inception and expiration times, so validation depends on the resolver’s clock and on signatures remaining within their validity interval. A stale signature can make otherwise correct DNS data fail validation.

The signature does not make the contents semantically correct. If an authorized zone operator signs an incorrect address, DNSSEC can authenticate that incorrect address as data published by the signed zone. Cryptographic origin authentication protects against undetected alteration; it does not replace sound zone administration.

DS records connect delegation to child keys

A DNSKEY record publishes a public key for a zone. Possessing a signed DNSKEY set is not enough by itself, because a validator still needs a trusted basis for accepting that key. DNSSEC builds that basis through delegation.

A signed parent can publish a Delegation Signer record containing a digest associated with a child zone’s DNSKEY. The validator authenticates the parent’s DS RRset, matches it to the child’s DNSKEY material, verifies the child’s DNSKEY RRset, and can then use authenticated child keys to verify other signed RRsets in that zone.

Repeated across delegations, this forms a chain of trust. A typical validator begins from a configured root trust anchor and follows authenticated delegations toward the target name. Local policy can also establish other trust anchors, so the protocol does not require every validation arrangement to begin at the public root.

The absence of a DS record has its own meaning when that absence is authenticated. A signed parent can prove that a delegation is insecure rather than signed. In that case, data below the insecure delegation does not gain DNSSEC authenticity merely because the resolver itself supports validation.

That distinction prevents a validator from treating every unsigned answer as an attack. DNSSEC must distinguish a deliberately unsigned branch from a signed branch whose required authentication material is missing or invalid.

Secure, insecure, and bogus are different outcomes

A validating resolver does more than return a binary signature result. The security status depends on the available chain and the evidence encountered along it.

Secure data has a valid authentication path to a trust anchor under the validator’s policy. Insecure data belongs to a branch for which authenticated delegation evidence establishes that DNSSEC protection is not present. Bogus data is expected to validate through a secure chain but fails the required checks. Indeterminate status can arise when the validator lacks a trust anchor needed to establish a security path.

These states have different operational consequences. Insecure data can still be returned according to resolver policy because the namespace explicitly lacks an authenticated chain at that point. Bogus data indicates a failure in a branch that was expected to be protected. A validating recursive resolver normally protects dependent clients by returning a server-failure response rather than handing them data that failed authentication, unless checking has explicitly been disabled for the query.

This fail-closed behavior turns DNSSEC configuration errors into availability incidents. An expired zone signature, an incorrect DS record, or a botched key transition can make legitimate names unreachable through validating resolvers even while non-validating resolvers continue to return records. DNSSEC therefore moves some DNS failures from silent integrity loss into visible resolution failure.

Authenticated denial closes the negative-answer gap

Signing existing records is only half of the problem. An attacker able to forge a negative response could otherwise replace a valid signed answer with a claim that the name or record type does not exist.

DNSSEC supplies signed denial records for this case. NSEC records link names in canonical order and state which record types exist at a name. A validator can use signed NSEC material to verify that a queried name or type falls into authenticated empty space rather than accepting an unsigned absence claim.

NSEC3 provides another denial mechanism based on hashed owner names and supports operational choices intended to make straightforward zone enumeration less direct. It does not turn DNS into a confidential directory, and its properties depend on parameters and the names present in the zone.

Authenticated denial is significant because absence is security-relevant data. A resolver that authenticates positive answers but accepts forged negative answers would still permit an on-path attacker to suppress destinations, service records, or other DNS information without forging a signed RRset.

The AD bit is a claim with a channel boundary

Applications often rely on a recursive resolver rather than validating DNSSEC locally. DNS defines the Authenticated Data bit so a security-aware recursive server can indicate that the relevant answer and authority data passed its authentication process.

That signal is not safe to trust across an arbitrary network path. The DNSSEC protocol requires a stub resolver to rely on validation performed by a recursive server only when the response comes from a trusted security-aware resolver over a secure channel, or when equivalent trust has been configured. An attacker able to alter an unprotected response could otherwise set the same header bit.

The Checking Disabled bit serves a different role. A client that intends to apply its own authentication policy can request raw data even when the recursive resolver would reject it under local validation policy. This is useful for validators that need to inspect evidence themselves, but it also means these control bits are meaningful only when the parties and channel are treated consistently.

The DNSSEC OK bit in EDNS signals that a resolver can receive DNSSEC records. It is a capability signal, not a validation verdict. Requesting signatures and validating them are separate operations.

Validation does not encrypt DNS traffic

DNSSEC is sometimes grouped with encrypted DNS transports, but the controls protect different properties. DNSSEC provides origin authentication and integrity for signed DNS data. It does not provide confidentiality for query names or responses.

DNS over TLS and DNS over HTTPS can protect a DNS exchange against observation or modification between a client and the selected recursive resolver. That secure channel does not, by itself, authenticate the DNS data received by the recursive resolver from the wider DNS hierarchy. A trusted recursive service may combine encrypted client transport with DNSSEC validation, but neither mechanism substitutes for the other.

The same separation applies to application identity. A DNSSEC-authenticated A or AAAA record can establish that the signed zone published a particular address. It does not prove that a TLS service at that address owns a valid certificate for the requested hostname. DNS data authentication and application endpoint authentication remain distinct trust decisions.

Signed DNS makes tampering fail visibly

The operational value of DNSSEC appears at the point where a resolver must choose between plausible data and authenticated data. Without validation, a forged answer that satisfies ordinary DNS matching rules may enter a cache if other defenses fail. With a valid signed chain, altering the protected RRset without the signing key causes signature verification to fail.

That property is strongest only where the chain remains intact. Unsigned delegations deliberately leave branches without DNSSEC authentication. Misconfigured signatures or delegation records can deny service. Trust-anchor management becomes part of resolver security. Resolver clocks matter because signatures have validity periods. Larger responses and extra cryptographic work also add protocol and operational costs.

These constraints do not reduce DNSSEC to a transport hardening feature. Its core effect is architectural: authoritative zones can publish cryptographic evidence that survives recursive resolution and caching, while validators can reject data that conflicts with that evidence. The result is not a private or failure-proof DNS, but a namespace in which protected data can carry verifiable origin and integrity across an otherwise untrusted delivery path.