Reference guide · dns-ssl · Published 2026-08-16 · 3 min read
DS records and DNSSEC validation explained
DS records in DNSSEC: the parent-child trust chain, what DS contains, and how to add it when enabling DNSSEC.
- ·The glue of the chain
- ·What DS holds
- ·Enabling and checking
The DS record is the glue of the trust chain
DNSSEC signs DNS answers so a resolver can verify they were not altered. But a self-signed zone proves nothing on its own, because anyone could sign their own wrong answer. The trust has to come from somewhere above the zone, and that is exactly what the DS record provides.
The zone signing article covers signing the zone itself. This page is about the DS record, the "chain of trust" link that ties a signed child zone to the signed parent, usually the top-level domain run by your registrar.
How the chain connects
A DS record lives in the parent zone and describes the child zone. It does not hold the child's IPs or content; it holds a reference to the child's signing key, the one that signs the DNSKEY records in the child zone.
The verification path is recursive:
- A resolver asks for a signed child record and receives an answer plus signatures.
- It needs the child's signing key, which the child's DNSKEY records provide.
- To trust those DNSKEY records, the resolver compares the child's key against the DS record published in the parent.
- The parent zone is itself signed, so the DS record is covered by the parent's signature, and so on up to the root.
If the child's key does not match the DS in the parent, validation fails whatever the answer says. That is what makes DS the point at which "the zone is signed" becomes "the zone is verifiably solid to downstream resolvers".
What a DS record actually holds
A DS record is a compact digest of the child's DNSKEY, not the full key itself. Its fields are the key tag, the algorithm, the digest type, and the digest:
| Field | Meaning |
|---|---|
| Key tag | A numeric identifier for the DNSKEY |
| Algorithm | Which crypto algorithm the child's key uses (for example, 8 = RSASHA256, 13 = ECDSAP256SHA256) |
| Digest type | Which hash of the DNSKEY is present (SHA-256 is type 2) |
| Digest | The hash value itself |
Because it is a digest, DS is short to publish and costly to forge, and matching it requires the child's actual DNSKEY, which only a real zone operator has.
Enabling and checking
The practical workflow when you turn DNSSEC on at the registrar, the parent:
- Sign the child zone first, following the zone signing steps, and note the DNSKEY key tag and algorithm the signer produces.
- Get the DS value. Many DNS providers generate it from the zone; if not, derive it from the DNSKEY with
dnssec-dsfromkey. - Paste the DS, or the key tag and algorithm, into the registrar's DNSSEC settings for the domain.
- Verify with a validation-aware tool:
dig +dnssec example.com SOAshould return anad(authenticated) flag at a validating resolver, or use an online validator.
The common failure is a mismatch: a DS key tag or algorithm that does not correspond to the current DNSKEY breaks the chain, and once validating resolvers reach a trust anchor with a mismatched DS the site becomes unresolvable for them. Publish DS only when the child key is stable, keep it updated whenever the DNSKEY rotates, and re-check with the DNS record types and TTL context in mind before relying on the new answers.