What a DS record contains
RFC 4034 defines the Delegation Signer record as four fields: the key tag of the child's KSK, the algorithm number of that key, a digest type, and the digest. The digest is a hash over the child zone's name plus the DNSKEY record data, so it pins one exact key. A record such as 2371 13 2 followed by 64 hex characters says: trust the ECDSA P-256 key with tag 2371 whose SHA-256 hash is this value.
The record sits in the parent zone because that is where the chain of trust hands over. A validator trusts the root key, uses it to verify the TLD's DNSKEY set, finds the DS for your domain in the TLD zone, and uses that DS to decide which of your DNSKEYs to trust. Without the DS, your signatures are an island nobody is anchored to.
Reading the table and the status box
Each row shows Key Tag, Algorithm as number and name, Digest Type with its name, TTL and the digest in uppercase hex. Digest type 1 gets a deprecated marker. The TTL is set by the parent zone rather than by you, and parent zones tend to use long values, so a DS change at the registrar can take a day to drop out of caches even when your own records use short TTLs.
The box above the table reports whether the resolver validated the answer. DS records are signed by the parent, so DNSSEC validated here means the parent's part of the chain is intact. No DS record at the parent zone means DNSSEC is not active for this delegation: either the zone was never signed, the DS was never submitted, or you looked up a name that is not a delegation point. A subdomain inside your zone has no DS of its own unless you delegated it separately.
Matching the DS to a DNSKEY
A DS is only useful if a key in the child zone matches it on key tag and algorithm and hashes to the same digest. Open DNSKEY Lookup for the same domain and look for a KSK row (flags 257) with the tag shown here. Two DS rows for the same key with digest types 2 and 4 is a common and harmless pattern. Two rows with different key tags usually means a KSK rollover is in progress and both keys are live.
This tool shows the tags but does not recompute the digest. For an automated comparison of DS key tags against the published KSKs, run the DNS Health Checker or the Domain DNS Validation checklist, which report the DNSSEC chain as pass or fail.
Mistakes that break resolution
The DS is the one DNS record where a mistake takes the whole domain offline for most of the internet, because the big public resolvers all validate. The failure is silent from inside your network if your own resolver does not validate, which is why people notice it from customer complaints rather than monitoring.
The order of operations matters in both directions. Turning DNSSEC on means sign first, then publish the DS. Turning it off means remove the DS, wait at least the DS TTL, then stop signing. Moving providers means have the new provider sign, replace the DS, wait, and only then switch the NS records.
- DS present, zone not signed: the registrar form was filled in before the DNS host enabled signing. Remove the DS or finish signing.
- DS points at the old provider's key: update the DS with the new provider's values. The old values stop validating the moment the NS records change.
- DS with digest type 1 only: add a type 2 record for the same key, confirm it, then delete the SHA-1 one.
- Typo in the digest: the key tag matches but validation fails. Re-copy the digest from the DNS host and resubmit.
Where the values come from
Your DNS host's DNSSEC page shows the DS values, sometimes alongside the full DNSKEY. Some registrars accept the DNSKEY and compute the DS themselves, which avoids copy errors. A growing number of registries also honour CDS and CDNSKEY records (RFC 7344 and RFC 8078), letting the child zone publish its own desired DS and the parent update automatically. To find out which registrar holds the domain, run a WHOIS lookup.