The parent zone’s fingerprint of a signed child’s key (DNSSEC).
A DS record sits in the parent zone (for example .com) and holds a hash of the child zone’s key-signing DNSKEY. It is the link in the DNSSEC chain of trust: a validating resolver trusts the child’s keys because the parent, which it already trusts, vouches for them.
- Type
- DS
- Code
- 43
- Defined in
- RFC 4034
- IANA description
- Delegation Signer
- Field: Key tag
- Which DNSKEY it refers to
- Field: Algorithm
- e.g. 13 = ECDSA P-256
- Field: Digest type
- e.g. 2 = SHA-256
- Field: Digest
- Hash of the DNSKEY
How it works
You publish it at your registrar, using the values your DNS host gives you. A DS record that no longer matches the zone’s keys makes validating resolvers return SERVFAIL for the whole domain, which is the most common way DNSSEC breaks sites.
Example
example.com. 86400 IN DS 2371 13 2 1F987CC6583E92DF0890718C42…
Example uses reserved documentation names and addresses (RFC 2606, RFC 5737, RFC 3849).
Common mistakes
- Moving DNS hosts without removing or updating the DS first.
- Leaving an old DS after a key rollover.
How to check yours
To check DNSSEC end to end, look up the DS record at the parent and the DNSKEY records in the zone: the DS key tag and algorithm should match one of the zone’s key-signing keys. A validating resolver such as Cloudflare or Google returning SERVFAIL for an otherwise working domain usually points to a mismatch here.
Related record types
Sources
Sources
- IANA: Resource Record (RR) TYPEs registry · checked 5 Oct 2026
- RFC 4034 · checked 5 Oct 2026