Read the parent signal
A DS record in the parent identifies a child signing key by key tag, algorithm and digest.
Direct answer: A DNSSEC check compares DS records published by the parent with DNSKEY records published by the child and reports whether matching cryptographic key evidence is visible.
The server asks its resolver for the domain's parent-visible DS records and child DNSKEY records before comparing them. Result responses are private, uncached and excluded from search indexing. Do not enter passwords or secrets. Read the lookup privacy policy.
What this dnssec check tells you
DNSSEC adds signatures to DNS data and links a child zone to its parent through DS records. This check compares the parent-visible DS set with the domain's DNSKEY set and reports whether at least one cryptographic digest matches; it does not replace end-to-end validation by a validating resolver.
- Whether a parent DS record is visible for the domain
- Which DNSKEY records the child zone currently publishes
- Whether at least one parent DS digest matches one published DNSKEY
If a key match is missing during a provider change, follow the nameserver migration checklist and coordinate the parent DS record with the child DNSKEY set before proceeding.
How the evidence is collected
Read the child keys
DNSKEY records publish the zone's current public signing material and key roles.
Compare the digest
The checker calculates the supported DS digest for candidate keys and reports exact matches without claiming to validate every signed response.
Read the fields without overclaiming
| Signal | What it can establish | What it does not prove |
|---|---|---|
| DS key tag | A compact identifier used to select a candidate DNSKEY. | Proof that the key is current or trustworthy by itself. |
| DS digest | A parent-published hash of DNSKEY material and the owner name. | A signature over ordinary DNS answers. |
| DNSKEY flags | A value that helps distinguish zone-signing key use from other key roles. | Evidence that the parent delegates trust to that key. |
| Algorithm | The cryptographic algorithm number shared by DS and DNSKEY records. | A guarantee that every resolver supports or accepts it. |
A parent DS remains after the DNS provider removed the old key
The DS query returns a key tag that matches none of the published DNSKEY records. Treat this as broken chain evidence, not an ordinary propagation delay. Restore the expected key or update the parent DS through the registrar using the provider's documented rollover procedure, then confirm with an independent validating resolver.
Common mistakes
- Calling a DNSKEY-only zone fully protected when the parent publishes no DS
- Removing an old DNSKEY before caches and the parent DS transition are safe
- Treating a digest match as proof that every record signature validates
- Checking only one resolver during an active key rollover
DNSSEC Check FAQ
Does a matching DS and DNSKEY prove DNSSEC is fully valid?
No. It proves that a parent-published digest matches a currently observed key. Full validation must also verify the chain of trust, signatures, denial-of-existence proofs, time validity and the requested record set.
Is DNSSEC enabled when DNSKEY exists but DS does not?
The zone may sign its data, but ordinary validating resolvers cannot build a chain of trust from the parent without a DS record or another configured trust anchor.
Why can DNSSEC fail during a nameserver move?
The new provider can publish different keys while the parent still points to an old DS. Coordinated pre-publication, DS updates and safe key-removal timing prevent that mismatch.