DNSSEC DS Records Link Parent and Child Trust

DNSSEC signs DNS data, but a signature is useful to a validator only when the signing key can be connected to a trusted starting point. That connection has to cross zone boundaries. A resolver validating data below a delegation cannot treat a child zone’s DNSKEY as authentic merely because the child publishes it.

The DS resource record supplies the link. It is authoritative data in the parent zone and identifies DNSKEY material in the delegated child. Once the parent side is authenticated, a matching DS can authenticate the corresponding child key, allowing validation to continue into the child zone.

This mechanism keeps delegation and key ownership separate: the parent publishes a compact commitment to the child’s key, while the child publishes and uses its own DNSSEC keys.

The DS record lives on the parent side

A DS record contains four fields:

key tag | algorithm | digest type | digest

The key tag and algorithm help identify the referenced DNSKEY. The digest is calculated from the canonical owner name and DNSKEY RDATA according to the selected digest algorithm.

For a delegation such as example.com, the DS RRset belongs to the parent side of the zone cut. The child publishes the corresponding DNSKEY RRset at its own apex.

.com zone
   |
   +-- example.com DS  ----+
                           |
                           v
example.com zone       matching DNSKEY
                           |
                           v
                     signed RRsets

The separation is central to the trust model. If the child could create an authenticated parent-side DS by itself, an untrusted child key could simply authorize itself. Instead, the parent’s signed data commits to the key that is permitted to extend the chain.

Validation alternates between signatures and key references

A typical chain starts from a configured trust anchor. A resolver can use an authenticated DNSKEY to verify an RRSIG over a child delegation’s DS RRset. It then compares the authenticated DS with candidate DNSKEY records from the child.

A matching child key can be used in the validation path for the child’s DNSKEY RRset. Keys authenticated through that path can then verify signatures over ordinary child data.

Conceptually:

trusted DNSKEY
     |
verify parent RRSIG
     |
authenticated DS
     |
match digest
     |
child DNSKEY
     |
verify child RRSIG
     |
authenticated RRset

This is not a certificate chain. DNSSEC defines its own resource records, canonical forms, signature processing, and delegation semantics. The useful comparison is narrower: each authenticated link supplies the basis for checking the next link until the target RRset is reached.

A DS record identifies a key; it does not contain one

The DS digest is a commitment to a DNSKEY, not a replacement for the public key. The validator still obtains the child DNSKEY RRset and checks whether a candidate key produces the digest identified by the authenticated DS.

The key tag is an efficiency aid rather than a unique security identifier. Distinct keys can share a key tag. Validation therefore cannot stop after a key-tag comparison; the algorithm and digest relationship are part of the check.

The DNSKEY referenced by DS must also be a DNSSEC zone key. DNSSEC validation applies the record semantics in addition to the cryptographic digest comparison.

An absent DS can mark a delegation as insecure

A signed parent does not imply that every child below it is signed. DNSSEC has to distinguish a deliberately unsigned delegation from a signed child whose authentication data is missing or invalid.

When a validating resolver can authenticate proof that no DS exists at a delegation, the branch can be classified as insecure under DNSSEC processing. Data below that insecure delegation does not gain DNSSEC authenticity from the parent chain.

That state differs from bogus. If a secure delegation says that a child is signed, but required signatures or keys fail validation, accepting the response as merely unsigned would erase the protection DNSSEC is meant to provide.

Operationally, publishing a DS is therefore a security transition. It tells validators that the child participates in the authenticated chain.

Changing DNSSEC keys is not only a child-zone operation when the affected key is represented by a parent DS. The parent and child are separate administrative and caching domains, so rollover sequencing matters.

A safe transition keeps at least one valid authentication path available while old and new material propagate. Depending on the rollover design, that can require overlapping DNSKEY and DS material for a period rather than replacing both sides as one instantaneous action.

The failure modes are asymmetric. Publishing a DS before the corresponding child key is available can create a secure delegation that validators cannot complete. Removing old child key material before parent-side references and cached data have aged out can break an otherwise valid chain.

DNS TTLs, signature validity intervals, publication timing, and registrar or registry update latency all affect the transition. The protocol supplies the records and validation rules; deployment procedures have to preserve continuity across those independent timelines.

DNSSEC authenticates DNS data, not the transport channel

DNSSEC signatures apply to DNS RRsets. They provide origin authentication and integrity for validated DNS data. They do not encrypt DNS names or answers, and they do not turn an authoritative DNS server connection into a confidential channel.

This distinction also separates DNSSEC from mechanisms that authenticate individual DNS transactions. A resolver can validate signed data even when it arrived through an untrusted network path, provided the complete authentication chain and signatures verify under its policy.

The trust anchor remains the starting assumption. A validator needs at least one configured trusted key or digest from which it can build the chain. DNSSEC does not bootstrap that initial trust from an arbitrary answer received over DNS.

The delegation boundary is the control point

The DS record makes the parent-child boundary explicit. The parent does not need the child’s private key, and the child does not need to surrender signing control. The parent only publishes authenticated data that identifies acceptable child key material.

That small record carries a large operational consequence. Adding, replacing, or removing it changes whether validators can extend authenticated DNS state into the child zone. DNSSEC deployments therefore need to treat DS management as part of key lifecycle management, not as registrar metadata that can drift independently from the child zone.

A valid chain depends on both sides agreeing at the same time: the parent must authenticate the intended DS, and the child must publish matching DNSKEY material capable of supporting the signatures validators need to check.

References

Cybersecurity DNSSEC DNS PKI