Does this domain’s DNSSEC actually validate?

example-company.com is signed, and the signature chain does not check out. A validating resolver returns SERVFAIL for it; the same query with validation disabled returns an address normally, which is what identifies DNSSEC as the cause rather than a nameserver problem. The practical effect is an outage: every resolver that validates — which is most large providers, and the default on many networks — refuses to return an address at all, so the domain is unreachable for a large share of the internet while appearing fine from anywhere that does not validate. The resolver's own diagnosis: EDE(9): DNSKEY Missing no SEP matching the DS found for example-company.com.

The parent zone publishes 1 DS record for example-company.com, naming key tag 42069. A DS is a digest of the zone's signing key held by the level above, and it is what anchors this zone to the chain — it is placed there by the registrar, which is why it can drift out of step with what the zone itself publishes.

The zone publishes 2 keys: tag 32784 (zone-signing, algorithm 13), tag 50719 (key-signing, algorithm 13). The key-signing key is the one the parent's DS is meant to point at. These were read with validation deliberately disabled, because a validating resolver refuses to hand over the keys of a zone whose chain is broken — asking it any other way would have come back empty and reported a zone with keys as having none.

This tool recomputed the digest from the records and the parent's DS for key tag 42069 does not correspond to anything the zone publishes — the zone publishes no key with tag 42069 and algorithm 13. That is the break, named precisely: the registrar's DS points at a key that is not there, which is what happens when a zone's keys are rolled or the zone is moved to a new provider without the DS at the registrar being updated to match. Fixing it means replacing the DS at the registrar with one for a key the zone actually publishes.