DNSSEC Checker

What DNSSEC adds to DNS

Ordinary DNS answers carry no proof of origin. DNSSEC adds digital signatures so that a validating resolver can detect an answer that was altered or forged. The zone publishes its public keys as DNSKEY records and signs its record sets, producing RRSIG records. To tie the zone into the global tree, the parent zone publishes a DS (delegation signer) record, which is a digest of one of the child's keys. A resolver trusts the root, follows DS and DNSKEY down the delegation, and so verifies every step.

DNSSEC protects the integrity of the answers. It does not encrypt queries and does not hide anything, and it does not say whether the content a record points at is trustworthy.

What the tool checks

The tool finds the zone apex, asks the zone's authoritative servers for DNSKEY, reads the DS record from the parent, and compares them. It then examines the signatures and finally asks two validating public resolvers, Cloudflare (1.1.1.1) and Google Public DNS (8.8.8.8), for the zone's SOA with DNSSEC requested and watches the response. A separate, older DNSSEC engine also classifies the zone, and the tool reports whether it agrees with its own measurements.

• Signing state: whether DNSKEY and DS are present, absent, or inconsistent.
• DS to DNSKEY match: it recomputes the DS digest from the DNSKEY records and checks whether one of the zone's keys matches the parent's DS, by key tag, algorithm and digest.
• Algorithm and digest type: it names the algorithm and flags deprecated or legacy ones, citing RFC 8624, and a DS published only with SHA-1.
• Signature window: every RRSIG has an inception and an expiry time. The tool reads these on the signature over the DNSKEY set and reports expired signatures, signatures not yet valid, and signatures close to expiry.
• Signed data: the tool checks that the DNSKEY and SOA answers carry signatures.
• Resolver validation: it asks the two validating resolvers and looks for the AD (authenticated data) flag, or for SERVFAIL.

How to read the result

• Signed, DS matches a DNSKEY, signatures current: a complete chain, reported as a pass, and public resolvers normally set AD.
• Not signed (no DNSKEY and no DS): a low-severity improvement. Many valid zones are unsigned; DNSSEC is optional.
• DNSKEY served but no DS at the parent: the zone is signed, but the chain is not connected, so DNSSEC is not active. Resolvers treat the zone as insecure rather than broken.
• DS at the parent but no matching DNSKEY, or no DNSKEY at all: reported as a high risk. Validating resolvers will treat the domain as bogus and return SERVFAIL, so the domain can disappear for people behind validating resolvers.
• All signatures expired: also high risk, with the same consequence.
• Both validating resolvers return SERVFAIL while the zone's own servers answer: the clearest sign of a broken chain. It is reported as a risk.
• DS matches but no AD flag: informational. Resolvers may not validate, or may have served an unvalidated cached answer.
• Lookups failed: if the DNSKEY or DS cannot be read reliably, the state is not concluded.

Common DNSSEC problems

• Changing DNS provider while the old DS stays at the registrar: the new provider signs with different keys and the stale DS makes the zone bogus. This is the classic way to take a domain offline.
• Key rollover without updating the DS: the zone's key changed but the parent still lists the old one.
• Signatures that are not re-signed: a signer that stopped running lets the validity window lapse.
• Wrong algorithm number or digest type copied into the registrar form.
• Registrar does not support DS records for the TLD or the provider's key.
• Secondary providers that do not both sign, giving different answers from different name servers.

How to enable or change DNSSEC safely

The dangerous part is the DS record at the parent. Publish keys and signatures in the zone first; add the DS at the registrar last. When disabling, reverse the order: remove the DS first, wait until the DS TTL at the parent has passed, and only then stop signing and remove the keys.

Moving a signed domain between providers needs a plan agreed by both: either disable DNSSEC beforehand by removing the DS and waiting, or run a multi-signer set-up where both providers' keys are published. Never leave a DS in place that points to keys nobody serves.

1. Confirm that your DNS provider supports signing and that the registrar accepts DS records.
2. Enable signing at the DNS provider and wait for DNSKEY and RRSIG to appear.
3. Copy the DS values from the provider into the registrar, exactly, including algorithm and digest type.
4. Run this check: the chain should show a match and validating resolvers should set AD.
5. To roll back, remove the DS record at the registrar, wait for its TTL, and only then disable signing.

Limits of the test

The tool verifies the key relationship (the DS digest against the DNSKEY) and signature dates, and observes what public validating resolvers return. It does not perform a full independent validation of every signature across the entire tree, so a clean report is strong evidence rather than a mathematical proof. NSEC and NSEC3 denial-of-existence records are not audited. Results come from one scanner at one moment, and a DS change at the registrar can take the parent's TTL to take effect everywhere.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09