How does ProbeKit decide that a domain is secure?

ProbeKit does not validate signatures itself. It asks validating public resolvers, Cloudflare first and Google if Cloudflare does not answer, and reads the AD (Authenticated Data) flag in their answers. A domain is reported as secure when the resolver sets AD on the SOA or DNSKEY answer.

What does bogus mean?

The domain has a DS record at its parent, so resolvers expect valid signatures, but validation fails. Validating resolvers then answer SERVFAIL, and users behind them cannot reach the domain at all. The answers only appear when validation is switched off with the CD flag.

Is an unsigned domain an error?

No. Most domains are not signed, and DNS works normally for them. DNSSEC protects against forged answers on the way from the nameservers to the resolver. The DNSSEC check reports an unsigned domain as information, not as a problem.

Which algorithm should I use?

The current recommendations are kept in the IANA DNS Security Algorithm Numbers registry (RFC 9904). It lists RSASHA256 (8) and ECDSAP256SHA256 (13) as algorithms that must be implemented, and recommends Ed25519 (15). Algorithms 1, 3, 5, 6 and 7, which use MD5, DSA or SHA-1, must not be used for signing; RFC 9905 deprecates the SHA-1 based RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7).

DNSSEC explained: DS, DNSKEY and validation

DNS answers are not authenticated by default. A resolver that receives a forged answer, for example through cache poisoning, has no way to tell. DNSSEC adds signatures to DNS data so that a validating resolver can check that an answer really comes from the zone and has not been changed. The core specification is RFC 4033, RFC 4034 and RFC 4035, with clarifications in RFC 6840 and algorithm guidance in RFC 9904 and RFC 9905.

The records

DNSSEC adds a few record types:

DNSKEY holds a public key of the zone. It is published at the zone apex.
RRSIG holds a signature over a set of records of one name and type.
NSEC or NSEC3 prove that a name or type does not exist, so that "no such record" can be authenticated too.
DS (delegation signer) is published in the parent zone. It contains a hash of one of the child's DNSKEYs.

A DNSKEY has a flags field. The value 257 has the Secure Entry Point bit set and is used for a key-signing key (KSK), the key the DS points to. The value 256 is a zone-signing key (ZSK), which signs the rest of the zone. Using two keys is a convention, not a requirement; a zone can also sign everything with a single key.

A DS record has four fields: the key tag of the DNSKEY it refers to, the algorithm of that key, the digest type, and the digest. For example:

example.com.  DS  2371 13 2 1F987CC6583E92DF0890718C42...

The chain of trust

A validating resolver starts at the root zone, whose key it knows in advance. The root signs the DS records for each top-level domain, the top-level domain signs the DS records of the domains below it, and so on. At each step the resolver checks that the child's DNSKEY matches a DS in the parent and that the child's records are signed by that DNSKEY.

The DS record at the parent is what turns DNSSEC on for a domain. Signing a zone without publishing a DS at the registrar has no effect on validation. Publishing a DS that does not match any key in the zone breaks the domain.

Secure, insecure, bogus and indeterminate

RFC 4033 section 5 and RFC 4035 section 4.3 describe four outcomes of validation for an answer:

Secure: the resolver built a chain of signatures from its trust anchor to the answer.
Insecure: the resolver can prove that there is no chain, typically because the parent has no DS for the domain. The answer is used, but without protection.
Bogus: a chain should exist but does not validate: signatures are missing, expired or wrong, or the DS points to a key the zone does not have. A validating resolver returns SERVFAIL.
Indeterminate: the resolver cannot tell whether the data should be signed, for example because it cannot reach the parent's nameservers. ProbeKit's own unknown result (DNSSEC_INDETERMINATE) is related but not the same thing: it is what the check reports when one of its lookups fails or the resolvers' answers fit none of the cases described below.

A validating resolver signals a secure answer by setting the AD (Authenticated Data) bit in the response (RFC 4035 section 3.2.3). A client can ask for it by setting the AD bit in its query, as RFC 6840 section 5.7 allows, or by setting the DO bit. A client can also set the CD (Checking Disabled) bit to get the answer without validation. That is how a bogus domain can be told apart from a nameserver that is simply down.

How the ProbeKit check works

ProbeKit does not validate DNSSEC signatures itself. The status comes from the validating public resolvers it uses, Cloudflare first and Google if Cloudflare does not answer. The check queries the SOA, DNSKEY and DS records of the domain with the DO bit set and reads the AD flag:

AD is set on the SOA or DNSKEY answer: secure.
AD is not set and the parent has no DS record: insecure, reported as DNSSEC_NOT_SIGNED.
A normal query gives SERVFAIL, but the same query with CD set answers and a DS record exists: bogus, reported as DNSSEC_BOGUS.
Anything else, such as a timeout or answers that do not fit one of these cases: unknown, reported as DNSSEC_INDETERMINATE, and the result status is unknown.

Because the result depends on the resolvers, a problem that only some resolvers see, or a change that has not reached their caches yet, can give a different answer from a check run elsewhere.

Algorithms

Each DNSKEY and DS names an algorithm by number. RFC 9904 moved the recommendations to the IANA DNS Security Algorithm Numbers registry, which replaces the table in the older RFC 8624. RFC 9905 deprecates the SHA-1 based RSA algorithms for signing. The registry sets which ones should be used today:

Number	Name	Status for signing
1	RSAMD5	Must not be used
3	DSA	Must not be used
5	RSASHA1	Must not be used (RFC 9905)
6	DSA-NSEC3-SHA1	Must not be used
7	RSASHA1-NSEC3-SHA1	Must not be used (RFC 9905)
8	RSASHA256	Must be implemented
13	ECDSAP256SHA256	Must be implemented
15	ED25519	Recommended

The check reports keys and DS records with algorithm 1, 3, 5, 6 or 7 as DNSSEC_DEPRECATED_ALGORITHM. Under RFC 9905, validators still implement the SHA-1 based algorithms but treat zones signed only with them as insecure, so such a domain loses its DNSSEC protection.

The DS digest type has its own list. Type 1 is SHA-1, type 2 is SHA-256 and type 4 is SHA-384. The IANA digest registry (RFC 9904) says SHA-1 must not be used to create new DS records. The check reports DS records with digest type 1 as DNSSEC_SHA1_DIGEST; publish a SHA-256 DS instead.

DS and DNSKEY must match

Every DS record at the parent should point to a DNSKEY that is actually in the zone. A DS whose algorithm does not appear among the zone's DNSKEYs is a common result of a key or algorithm rollover that was finished in the zone but not at the registrar, or the other way round. The check reports it as DNSSEC_DS_WITHOUT_DNSKEY. Depending on what else is published, resolvers may treat the domain as bogus.

Common mistakes

Moving a domain to a new DNS provider that does not sign it, while the old DS stays at the registrar. The domain becomes bogus.
Letting signatures expire because automatic re-signing stopped.
Rolling a key without the waiting periods for TTLs, so caches still hold the old DS or DNSKEY.
Keeping an old algorithm because it still works with most resolvers.

Use the DNSSEC check to see the state, the DS records and the DNSKEY algorithms of a domain, or the domain health check for DNSSEC together with the mail checks. To look at the raw records, use the DNS lookup.