DNSSEC check

Queries SOA, DNSKEY and DS through validating public resolvers and reports secure, insecure, bogus or unknown from the AD flag; bogus is detected by repeating the query with checking disabled. There is no local cryptographic validation.

Updated 2026-10-25

What this tool checks

DNSSEC protects DNS answers with signatures. The chain of trust starts at the root, and each parent zone vouches for its child with a DS record that points to the child's key.

The check asks a validating public resolver for the domain's SOA and DNSKEY records and reads the AD flag on the answers. It also looks up the DS records at the parent. From that it gives one of four states:

secure: the resolver validated the answer.
insecure: there is no DS record at the parent and nothing was validated (DNSSEC_NOT_SIGNED).
bogus: the normal query fails with SERVFAIL, but the same query with checking disabled (the CD flag) answers and a DS record is present (DNSSEC_BOGUS).
unknown: anything else, for example a timeout or answers that do not fit together. The status of the result is then unknown too.

What the evidence shows

For each DS record the check shows the key tag, the algorithm and the digest type. For each DNSKEY it shows the algorithm and whether it is a key-signing key (KSK, flag 257) or a zone-signing key (ZSK, flag 256). It flags:

outdated algorithms: RSAMD5, DSA, RSASHA1 and RSASHA1-NSEC3-SHA1;
DS records that use the SHA-1 digest (DNSSEC_SHA1_DIGEST);
a DS algorithm with no DNSKEY of the same algorithm (DNSSEC_DS_WITHOUT_DNSKEY), which breaks the chain.

How to read the result

An unsigned domain is not an error. Many domains are unsigned, and the result is information. A bogus domain is the serious case, because validating resolvers stop answering for it. The DNSSEC guide explains the chain of trust and how rollovers go wrong.

Limitations

There is no local validation. The status is what the public resolvers report, and a resolver with a stale view can differ for a short time.
The check does not inspect signature expiry dates or NSEC/NSEC3 parameters.
It looks at the name you enter. A signed parent with an unsigned child zone shows as insecure for the child.

Use it from code

API reference for DNSSEC check

curl -i "https://api.probekit.dev/v1/dns/dnssec?domain=example.com"

A request without payment is answered with 402 Payment Required and the exact price. See the API reference.

Limits

Input	Domain
Deadline	10 seconds
Freshness	Up to 5 minutes, never longer than the record TTL
Price	$0.01 per check

Findings this tool can report

DNSSEC (6)

Error DNSSEC_BOGUS DNSSEC validation fails for the domain.
Warning DNSSEC_DEPRECATED_ALGORITHM The zone uses a DNSSEC algorithm that should no longer be used.
Error DNSSEC_DS_WITHOUT_DNSKEY A DS record has no DNSKEY with the same algorithm.
Warning DNSSEC_INDETERMINATE The DNSSEC status of the domain could not be determined.
Info DNSSEC_NOT_SIGNED The domain is not signed with DNSSEC.
Warning DNSSEC_SHA1_DIGEST A DS record uses a SHA-1 digest.

Check (1)

Warning CHECK_QUERY_BUDGET_EXCEEDED The check stopped after reaching its DNS query limit.

DNS (3)

Error DNS_DOMAIN_NOT_FOUND The DNS resolver reported that the domain does not exist.
Warning DNS_RESOLVER_FAILURE The DNS resolver returned a server failure.
Warning DNS_RESOLVER_TIMEOUT The DNS resolver did not answer in time.

Frequently asked questions

What do secure, insecure and bogus mean?

Secure means a validating resolver could build a chain of signatures from the root down to the domain. Insecure means the parent zone holds no DS record for the domain, so there is nothing to validate. Bogus means a chain should exist, because a DS record is published, but the signatures do not verify, and validating resolvers refuse to answer for the domain.

Does ProbeKit validate the signatures itself?

No. The status comes from the public resolvers ProbeKit uses, Cloudflare first and Google as fallback. They validate DNSSEC and set the AD (authenticated data) flag on answers they could verify. The check reads that flag and does not repeat the cryptography.

My domain is bogus. What usually causes that?

Most often a DS record at the registrar that no longer matches the zone's keys, for example after moving to another DNS provider or after a key rollover that removed the old key too early. Expired signatures are the other common cause. Until it is fixed, the domain does not resolve for anyone behind a validating resolver.

Is RSASHA1 still acceptable?

RFC 9905 says RSASHA1 and RSASHA1-NSEC3-SHA1 must not be used to sign, and the IANA algorithm registry (RFC 9904) says the same of RSAMD5 and DSA. The check flags these algorithms with DNSSEC_DEPRECATED_ALGORITHM. ECDSA P-256 (algorithm 13) is the common choice today.