How DNSSEC is put together
DNSSEC adds signatures to DNS answers so that a resolver can verify they were not altered on the way. The zone publishes its public keys as DNSKEY records and signs its records with them. The parent zone (.com for example.com) publishes a DS record: a digest of the zone's key-signing key. That DS record is the link in the chain of trust from the root down to the domain, and it is set through the registrar.
Both halves are needed. Keys in the zone without a DS record at the parent are not validated by anyone. A DS record that points at a key the zone does not publish is worse: validating resolvers then refuse every answer and the domain disappears for their users.
What this tool checks and where the data comes from
OrbitProbe asks two public validating resolvers, Cloudflare and Google, over DNS-over-HTTPS for the DS and DNSKEY records of the registrable domain, with the DNSSEC OK bit set. It lists the DS records with key tag, algorithm and digest type, the DNSKEY records with their role (KSK or ZSK) and algorithm, and whether each resolver set the AD (Authenticated Data) flag on its answer. Where the registry publishes it, the RDAP "delegation signed" flag is shown as a second source.
The verdict is one of: signed (DS and DNSKEY present), not signed (the resolvers answered and there is no DS record), keys published without a DS record, DS present but keys unreadable, or could not be checked. If one resolver fails, the other one's answer is still used, and the failure is shown.
Reading the AD flag honestly
An AD flag means: these validating resolvers marked the answer authenticated at the time of the check. It is their statement about their own validation, not a certificate for the domain and not a promise about other resolvers. The tool does not re-verify signatures itself, and it does not walk every record of the zone, so an expired signature on a single record can go unnoticed here.