Derya

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 thing to check before building any of this: whether your interface is wireless.

Bridging a wireless interface generally does not work, because access points expect one address per client and a bridge presents several. Guides rarely say so and people spend an evening on it.

If the host is on wifi, the realistic options are NAT for the virtual machines, or a routed setup with proxy ARP, or a cable. It is the one case where the answer is that the thing you are trying to do is not available rather than not configured.