A DS (Delegation Signer) record is the link between a parent zone and a child zone. It lives in the parent (for example.com, in .com) and holds a hash of the child's key-signing key. The parent signs the DS like any other record, so a resolver that trusts the parent can now trust the child's key. Defined in RFC 4034.
example.com. 86400 IN DS 36114 13 2 46aea2cc…a528b529
│ │ │ └ digest of the DNSKEY
│ │ └ digest type (2 = SHA-256)
│ └ algorithm of the key (13 = ECDSA P-256)
└ key tag of the DNSKEY it points to
The four fields
- Key tag
- A 16-bit number computed from the DNSKEY. It helps resolvers pick the right key. It is not unique, so the digest decides.
- Algorithm
- The signing algorithm of the DNSKEY. See algorithms.
- Digest type
- The hash used: 1 = SHA-1, 2 = SHA-256, 4 = SHA-384. RFC 8624 says new DS records must not use SHA-1; use 2.
- Digest
- The hash of the child's owner name and DNSKEY record.
Who publishes it
You do not edit the parent zone. Your registrar does, through the registry. That is why enabling DNSSEC needs two places: the DNS host signs, the registrar publishes the DS. Some registries can pick up the DS from CDS records in your zone (RFC 7344, RFC 8078).
Common mistakes
- DS for a key that is gone. After a key rollover or a move to a new DNS host, the DS still points at the old key. Every validating resolver returns SERVFAIL. Update the DS first, remove the old key after the DS TTL.
- DS with no signed zone. Same result: SERVFAIL. Remove the DS before you turn signing off.
- Typo in the digest. Copy and paste, do not retype. Check with
dig DS example.com +shortand compare.
Our checker counts the DS records it finds for a domain: "DS in parent". A zone with DNSKEY but no DS is signed but not trusted.