DS Delegation Signer Common

What it's for

A DS (Delegation Signer) record is a hash of a child zone's DNSKEY, published in the parent zone, not in the zone it refers to. It's the mechanism that links DNSSEC's chain of trust across a delegation boundary: the parent zone (say, the .com registry) vouches for the child zone's (example.com's) signing key by publishing a hash of it, without needing the actual key material duplicated at the parent.

This is what completes DNSSEC setup for a domain — enabling DNSSEC at your DNS provider generates the DNSKEY inside your own zone, but a validating resolver has no reason to trust it until the parent zone (via your registrar) publishes the matching DS record confirming the delegation is cryptographically authorized.

Format & syntax

example.com.    3600    IN    DS    12345 8 2 49FD46E6C4B45C55D4AC69CBBC2BB69E9E1E6D34

• Key Tag — a short identifier matching a specific DNSKEY in the child zone (there can be multiple keys, so this pins down which one)
• Algorithm — matches the algorithm number used by the referenced DNSKEY (e.g. 8 for RSA/SHA-256)
• Digest Type — which hash algorithm was used to create the digest (2 is SHA-256, the modern standard)
• Digest — the actual hash value of the DNSKEY record

How it's used in practice

• Completing DNSSEC activation — after enabling DNSSEC at your DNS provider (which generates a DNSKEY), you take the DS record value they give you and manually submit it to your domain registrar, who publishes it in the parent zone. This step is very commonly missed because it happens in a completely different dashboard (registrar, not DNS provider) than where DNSSEC was originally enabled.
• Chain of trust validation — a validating resolver walks down from the DNS root, checking at each delegation boundary whether the child zone's DNSKEY matches the DS record published by the parent, building an unbroken cryptographic chain from root to leaf.
• Key rollover coordination — when a zone rotates its Key Signing Key, the corresponding DS record at the parent/registrar must also be updated, timed carefully to avoid a window where they don't match (which would break validation).
• Disabling DNSSEC safely — removing DNSSEC from a domain requires removing the DS record at the registrar before removing DNSKEY/signing at the DNS provider, in the correct order, to avoid a temporary state where resolvers expect signatures that no longer exist.

Common mistakes & gotchas

• Enabling DNSSEC signing but never publishing the DS record — far and away the most common DNSSEC failure mode. The zone is technically signed, but with no DS record at the parent, there's no established chain of trust — which for non-validating resolvers changes nothing, but for validating resolvers can range from "DNSSEC is just ignored" to actual resolution failures depending on the exact state.
• Mismatched key tag, algorithm, or digest after a key rotation — if you rotate your DNSKEY but don't update the DS record (or update it incorrectly) at the registrar, validating resolvers will fail to verify the new key against the old DS hash, breaking resolution for validating clients.
• Wrong order when disabling DNSSEC — removing DNSKEY/signing before removing the DS record at the registrar leaves a DS record pointing at a key that no longer exists, causing hard validation failures. Always remove the DS record first, wait for its TTL to expire, then disable signing.
• Confusing where to publish it — a DS record belongs at the registrar/parent zone level, not inside your own DNS zone alongside your other records. Some registrars have a dedicated "DNSSEC" tab specifically for this.

Comparison & FAQ

Where do I actually publish a DS record?

At your domain registrar, not your DNS provider. Your DNS provider generates the DNSKEY and gives you the DS record value to copy; the registrar publishes it in the parent zone to complete the chain of trust.

What happens if I enable DNSSEC but never add the DS record?

The chain of trust to your zone is incomplete. Depending on resolver behavior this can range from DNSSEC effectively being ignored for your domain, to validation errors for resolvers that specifically expect a complete chain — it's important not to skip this step.

In what order should I disable DNSSEC?

Remove the DS record at your registrar first, wait for its TTL to fully expire, and only then disable DNSSEC signing at your DNS provider. Doing it in the reverse order leaves a dangling DS record pointing at a key that no longer exists, which breaks validation for resolvers that check it.

Does every domain need a DS record?

Only domains with DNSSEC enabled. It's optional, but if you do enable DNSSEC, the DS record is not optional — without it the setup is incomplete.