Guide
Checking a DNSSEC chain of trust: DS records, DNSKEYs and key tags
DNSSEC adds digital signatures to DNS so that a resolver can prove an answer was not forged on the way. It is built as a chain: the root zone vouches for the top-level domain, which vouches for your domain by publishing a hash of your key. When the chain is intact, tampering is detectable. When it breaks, validating resolvers refuse to answer, and the domain seems to vanish. The page inspects each link.
The three parts of the chain
The DNSKEY records sit in your zone and carry the public keys. Usually there are two: a key-signing key (KSK, flags 257) and a zone-signing key (ZSK, flags 256). The ZSK signs the zone’s records; the KSK signs the DNSKEY set itself. The DS record lives in the parent zone and holds a hash of the KSK: its key tag, algorithm, digest type and digest. The parent signs it, so a resolver that trusts the parent can trust your key. The RRSIG records are the signatures with an inception and expiry time.
What the page checks
It asks for the DS records at the parent and the DNSKEY records in the zone, then recomputes the DS digest from each key by hashing the owner name and the key’s data as RFC 4034 defines, for digest types 1 (SHA-1), 2 (SHA-256) and 4 (SHA-384). Each DS row says whether it matches a DNSKEY. The key tag, a 16-bit checksum that lets software find the right key quickly, is calculated for each key. The page lists the algorithm by name, such as ECDSA P-256 with SHA-256 for number 13, and warns about algorithms and digests that are deprecated. It reports how long the signature over the DNSKEY set remains valid and whether the resolver returned the authenticated-data flag.
Reading the verdict
The sample verdict is the best case: “The resolver validated the answers (AD flag set), and a DS record matches a DNSKEY: the chain of trust is intact.” Other outcomes: no DS record means the zone is not signed at the parent (it may still have DNSKEYs, which makes the signing useless); a DS that matches no key means the registrar’s record is stale; a signature that expires soon means the signer has stopped refreshing it. If the resolver returns an error for a signed domain, the page retries without validation to show that the data exist but fail the check.
A worked example
Press Sample to analyse cloudflare.com. The page shows one DS record with key tag 2371, algorithm 13 (ECDSA P-256/SHA-256) and digest type 2 (SHA-256), marked “matches a DNSKEY”. The zone has two DNSKEYs: key tag 34505, a zone-signing key with flags 256, and key tag 2371, the key-signing key (secure entry point) with flags 257. The DS tag equals the KSK’s tag, which is how the link is made. The signature over the DNSKEY set was valid for another 40 days when this guide was reviewed. Keys are rolled over time, so the numbers will change.
Limits
The page reads the chain and recomputes hashes; it does not verify every RRSIG in the zone, and it does not examine NSEC or NSEC3 records that prove a name does not exist. Resolver validation is the final judge and depends on the resolver you choose. A domain that is not signed is not broken: most domains are unsigned. For key rollover, always add the new DS at the registrar before removing the old one. Check the nameserver side with the NS Lookup.
Related tools
- NS Lookup shows which servers hold the signed zone.
- CAA Record Lookup reads another security-related DNS record.
- DNS Lookup can display DS and DNSKEY records directly.
- SOA Lookup shows the zone serial and timers.
Checked against the current version of the DNSSEC Analyzer on .