DNSSEC Validates DNS Data Through Signed Delegations
DNS normally answers questions about names and resource records without cryptographic proof that the returned data came from the zone operator. DNS Security Extensions (DNSSEC) add signatures and a delegation chain that a validating resolver can check before treating signed DNS data as authentic.
The protection is specific. DNSSEC provides data-origin authentication and integrity for DNS data. It does not encrypt queries or responses, hide queried names, or authenticate the application reached after resolution. A valid signed A record can establish that the record is authentic within the DNSSEC chain; it does not establish that the server at that address is safe.
The core path combines three record types:
trusted key
|
v
DNSKEY signs DS in parent zone
|
v
DS identifies child DNSKEY
|
v
child DNSKEY verifies RRSIG
|
v
RRset is authenticatedThis chain lets validation cross administrative boundaries without placing every zone key directly into each resolver’s trust configuration.
RRSIG authenticates an RRset
DNSSEC signs resource-record sets, not arbitrary presentation text. An RRset groups records with the same owner name, class, and type. The corresponding RRSIG record identifies the covered type, signing algorithm, key tag, signer name, signature validity interval, and the signature itself.
A simplified signed response can be represented as:
www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN RRSIG A 13 3 300 ...A validator does more than check that an RRSIG exists. It selects a matching DNSKEY, checks the signature’s inception and expiration fields, constructs the canonical signed form defined by DNSSEC, and verifies the signature. An attached signature that cannot be linked to an authenticated key is not sufficient.
Signature lifetime also makes time part of validation. Operational failures such as expired signatures can make otherwise unchanged zone data fail validation. Zone signing therefore includes key management and timely signature maintenance, not merely a one-time signing operation.
DNSKEY publishes zone verification keys
A signed zone publishes public keys in its apex DNSKEY RRset. Those keys are used in the authentication process for signatures in that zone.
example.com. 3600 IN DNSKEY 257 3 13 <public-key-material>The numeric fields encode flags, protocol, and algorithm. The public-key material is safe to publish; the corresponding private signing key is not placed in DNS.
A validator still needs a trusted path to the DNSKEY RRset. Accepting any key merely because it appears in the same response would let a forged response supply both fabricated data and a fabricated key. DNSSEC addresses that bootstrap problem with trust anchors and signed delegation.
DS links a parent to a child zone
At a signed delegation, the parent zone publishes a Delegation Signer (DS) RRset for the child. A DS record contains a digest associated with a child DNSKEY, along with the key tag, algorithm, and digest type.
Conceptually:
parent zone
example. DNSKEY
|
| authenticates parent data
v
child.example. DS
|
| digest identifies a child key
v
child.example. DNSKEYAfter authenticating the parent’s DS RRset, the validator can match it to a DNSKEY in the child zone. The child key can then authenticate the child’s apex DNSKEY RRset and signatures over other RRsets in that zone.
The DS record belongs on the parent side of the delegation. This placement matters operationally because enabling DNSSEC for a child zone usually requires coordination between the child zone’s signing configuration and the parent or registrar path that publishes the matching DS data.
A trust anchor starts validation
Cryptographic chains need a starting point that is already trusted. DNSSEC calls that starting material a trust anchor. A validator configured with an authenticated key can use it to authenticate the next link and continue down the DNS hierarchy.
For a chain rooted at the DNS root, the flow is broadly:
root trust anchor
|
v
root DNSKEY
|
v
TLD DS -> TLD DNSKEY
|
v
child DS -> child DNSKEY
|
v
signed application RRsetEach successful link narrows the next key choice through authenticated DNS data. A signature several levels below the trust anchor is useful only when the validator can build an acceptable authentication path to it.
A signed zone without such a path is an island of security unless the validator has another trust anchor for that zone. Signing data and making that data globally verifiable are related but distinct deployment steps.
Authenticated denial covers missing data
DNS also needs to answer questions whose result is absence: a name does not exist, or a name exists but has no record of the requested type. An unsigned negative response could otherwise be forged by simply claiming that the requested data is missing.
The original DNSSEC specifications use NSEC records to provide authenticated denial of existence. Signed NSEC data can prove gaps in the ordered namespace and the record types present at an existing name. A validator checks the relevant proof and its signatures rather than trusting an unauthenticated NXDOMAIN response.
NSEC3, defined separately from the original DNSSEC record set, provides another authenticated-denial mechanism using hashed owner names. Its operational and privacy properties differ from NSEC, but its security role is similar: negative DNS answers need cryptographic evidence when the zone is expected to be secure.
Validation has secure, insecure, and bogus outcomes
A validating resolver does not reduce every answer to signed or unsigned. The validation path determines how data is classified.
Data with a valid authentication chain can be treated as secure. A delegation that is authenticated as unsigned can lead to insecure data: DNSSEC does not claim authenticity for that child data, but the absence of a signed child is itself established through the parent-side proof. Data expected to validate but failing required checks is bogus.
That distinction prevents a simple stripping attack from turning a signed zone into an apparently ordinary unsigned zone. If an authenticated parent indicates a signed child through DS, removing the child’s DNSSEC records does not create a valid insecure delegation. It creates a validation failure.
For recursive service, RFC 4035 specifies failure behavior when required signatures cannot be validated. Applications commonly observe such failures through the recursive resolver rather than performing the full DNSSEC process themselves.
The AD, CD, and DO bits have different roles
DNSSEC also changes DNS message handling. The EDNS DNSSEC OK (DO) bit signals that DNSSEC records are desired in responses. A validating recursive resolver uses it when retrieving material needed for validation.
The DNS header’s Authenticated Data (AD) bit can indicate that a recursive resolver considers response data authentic according to its validation policy. A stub must not treat an AD bit from an untrusted path as independent cryptographic proof. RFC 4035 requires a secure channel or explicit configuration before relying on validation claimed by another resolver.
The Checking Disabled (CD) bit requests different handling: it allows a requester to ask a security-aware recursive server not to reject data solely because that server’s validation fails, so the requester can perform its own processing. AD, CD, and DO therefore are not interchangeable indicators of security.
DNSSEC does not provide confidentiality
DNSSEC signatures are public verification material. Queries, names, record values, keys, and signatures can still be visible on the network unless another transport mechanism provides confidentiality.
Encrypted DNS transports such as DNS over TLS or DNS over HTTPS address a different boundary: the connection between a client and its resolver. DNSSEC addresses authenticity and integrity of DNS data across the resolution chain. A deployment may use both because they solve different problems.
DNSSEC also does not replace TLS. A signed DNS record can authenticate DNS data, while TLS authenticates and protects an application connection according to its own certificate and protocol rules. Treating either mechanism as a substitute for the other leaves a gap at the boundary the omitted mechanism was designed to protect.
Key and delegation changes require coordinated state
DNSSEC operation becomes delicate during key rotation, algorithm migration, registrar changes, and delegation updates because validators can cache records with different lifetimes. A new child key is not useful as a global authentication path until the necessary signed records and parent-side delegation state line up.
Likewise, removing old material too early can break a chain for resolvers that still hold cached state. Safe procedures depend on the specific key-management method, TTLs, signing software, parent workflow, and algorithm policy. The important invariant is that validators must retain a valid path across each transition rather than seeing a temporary combination that cannot authenticate.
DNSSEC is strongest when treated as a chain-management system rather than a signature checkbox. RRSIG authenticates RRsets, DNSKEY supplies verification keys, DS carries trust across delegations, and a trust anchor gives the resolver a credible starting point. The security property comes from the complete path and its validation, not from the presence of any single DNSSEC record.