What is DS?

A DS (Delegation Signer) record sits in a parent DNS zone and holds a hash of a child zone's key, linking the child into the DNSSEC chain of trust.

DNSSEC works only if a resolver can trust each zone's keys, and it gets that trust from the zone above. The parent publishes a DS record at the delegation point, next to the NS records, and signs it with its own key. A DS record has four fields, as in example.net. IN DS 18425 13 2 9b98…:

• Key tag (18425): a short number identifying which of the child's DNSKEY records it refers to.
• Algorithm (13): the key's algorithm, here ECDSA P-256 with SHA-256.
• Digest type (2): the hash used, where 2 is SHA-256 and 4 is SHA-384. Type 1 (SHA-1) is deprecated.
• Digest: the hash of the child's owner name and DNSKEY.

A validating resolver fetches the child's DNSKEY set, hashes the matching key and compares it with the DS. If they match, the child's keys are trusted, and that trust carries on down to the records they sign.

For a real domain, the DS goes to the parent through your registrar, which passes it to the registry for the TLD. This is where most DNSSEC outages happen. If the DS doesn't match any key the child publishes, because of a typo or a key change without updating the parent, validating resolvers treat the whole zone as bogus and return SERVFAIL. Removing the DS is the safe way to go back to an unsigned zone; turning off signing while the DS is still there breaks it. The PowerDNS on Debian lesson exports the DS with pdnsutil export-zone-ds, then breaks it on purpose to show the failure.