What a DS record does
DNSSEC lets a validating DNS resolver check that certain DNS answers came from the expected zone and were not altered along the way. It does this with digital signatures, but signatures are useful only if the resolver can establish which keys to trust. That is the purpose of the DNSSEC chain of trust.
A Delegation Signer (DS) record links a parent zone to a signed child zone. For example, the DS record for example.com would be published in the .com zone, not in example.com’s own zone. It contains information derived from one of the child zone’s DNSKEY records, including a digest of that key. The parent signs its own records, including the DS record. That gives a resolver a way to move from a trusted parent to the child’s keys.
Following the chain from parent to child
A validating resolver starts with a trusted key, commonly called a trust anchor, and checks signatures as it follows DNS delegations. At each signed step, it can use the parent’s validated DS record to identify a matching DNSKEY in the child zone. It then checks the child’s DNSKEY signatures before using the validated keys to check signed answers from that zone.
A DS record does not contain the child’s private key, and it does not itself sign the child’s answers. Its job is to identify a public DNSKEY through a digest. DS records also include a key tag, algorithm and digest type. Those fields help the resolver find and evaluate a candidate key, but the digest match and signature checks are what establish the link.
A signed child zone with no DS record at its parent is not connected to that chain of trust. A resolver may treat the delegation as insecure rather than as a DNSSEC validation failure. That distinction matters: publishing signatures in the child zone alone does not give ordinary validating resolvers a parent-backed reason to trust them.
Publishing a DS record for your domain
The usual sequence is to enable DNSSEC at the service hosting your authoritative DNS, obtain the DS details generated for the zone, and submit those details through your registrar or domain-management interface. The registrar arranges for the DS record to be published in the parent zone. The available controls and terminology vary by provider, so identify which service manages the zone’s DNSKEY records and which one accepts changes to the parent’s DS record.
Before adding the DS record, confirm that the authoritative nameservers serve the signed zone and its expected DNSKEY. After publication, check that the DS visible at the parent matches a DNSKEY served by the child. DNS and registry changes can take time to appear across resolvers; allow for that when planning a change. Public DNSKEY and DS values are suitable for comparison, but private signing keys and account credentials should never be pasted into a troubleshooting request.
A DS record is not a general-purpose security setting. It does not encrypt DNS traffic, secure a website connection or replace TLS certificates. It supports a specific check: whether DNSSEC-signed data can be validated through the delegation.
Why mismatches can break resolution
If the parent publishes a DS record but the child no longer serves a matching DNSKEY, validating resolvers cannot complete the chain. They may return a DNSSEC validation failure, often surfaced to users as a DNS error, even while non-validating resolvers appear to receive answers. A similar problem can occur if the matching key exists but required signatures are missing, expired or invalid.
This risk is especially important when moving authoritative DNS to a new provider or changing signing keys. Do not assume the new provider uses the old DNSKEY or produces the same DS details. Coordinate the parent’s DS record with the keys and signatures that the active authoritative nameservers actually serve. During a planned rollover, an overlap between old and new key material may be needed so resolvers with cached data can continue validating. Follow your DNS provider’s rollover procedure rather than replacing records in an arbitrary order.
A practical way to check the link
When investigating a signed domain, check three places: the DS record published by the parent, the DNSKEY records returned by the child’s authoritative nameservers, and the result from a validating resolver. Compare the DS details with the child’s keys, then determine whether validation succeeds. If it does not, check which nameservers are authoritative and whether they all serve the intended signed zone.
Treat removing a DS record as a deliberate change, not a routine fix. Removal may restore resolution after a broken delegation, but it also removes the parent-backed DNSSEC link until a correct DS is published again. Keeping a record of which provider controls each side of the delegation makes future DNS moves and key changes easier to manage.
