Certificate issuance fails with a DNSSEC error, but my domain resolves perfectly everywhere I check

The difference is that the certificate authority validates DNSSEC and most of the resolvers you tested with do not, or do not enforce it strictly.

DNSSEC is a chain of signatures. Your zone signs its records, the parent zone publishes a fingerprint of your signing key, and a validating resolver walks that chain from the root down. If any link is broken, a validating resolver returns nothing at all — not a wrong answer, not the unsigned answer, a hard failure. That is the whole point of it.

A non-validating resolver ignores the signatures and hands you the records. So the site works for you, works for your phone, works for most online lookup tools, and is invisible to anyone whose resolver checks.

That is why the error looks contradictory. You and the authority are asking the same question and only one of you is checking the answer's signature.

To find out which side is broken, test with a validating resolver rather than whatever you have been using.

• Query a resolver known to validate and look for the AD flag in the response. Present means validated; absent on a signed zone means it did not validate.
• Use one of the DNSSEC debugging services that draws the chain from the root to your zone and marks the broken link. That single page usually identifies the fault in seconds.

The faults, in order of how often I see them:

A key rotation that did not reach the parent. You changed signing keys at your DNS host and the fingerprint record at your registrar still points at the old one. Extremely common, because the two are often different companies.

Signatures expired. DNSSEC signatures have a validity window and something stopped re-signing.

Signing enabled at the host, fingerprint never published — or the reverse, fingerprint published for a zone that is not signed. Both break it completely.

One case worth knowing about because it is not your fault and no amount of checking your own zone will find it: the break can be above you.

If the operator of your top-level domain has a problem with their signing, every domain under it fails validation at once while each individual zone is perfectly correct. It looks exactly like your problem.

The tell is that the debugging chain shows the break at the parent rather than at your zone, and that other domains under the same suffix fail identically. If you find that, there is nothing to fix on your side — the answer is to wait, and meanwhile to get a certificate by a route that does not depend on the broken lookup.

Which is the practical workaround for any of this: if HTTP validation is available to you, it does not need the authority to resolve anything beyond your address, so it can succeed while a DNS-based challenge cannot.

A caution on the fastest fix people reach for: disabling DNSSEC at your DNS host does resolve it immediately, and it is a real decision rather than a shrug.

Unsigning a zone that was signed is fine as long as the fingerprint record at the registrar is removed first. Remove the signing while the parent still advertises a key and you have broken it harder than before, and it will stay broken until the parent record is gone and caches expire.

So: parent record first, then unsign. In that order, and with a wait between them.