DNSSEC signs DNS data so a resolver can prove an answer really came from your zone and was not altered on the way. It is also what DANE for mail depends on. SSLBoard groups discovered hostnames by their assessed zones and reports validation status, signing details, and the related findings.
One thing DNSSEC does not do is keep DNS data private. It is authentication and integrity only, as RFC 4033 sets out.
Zone status
| Status | Meaning |
|---|---|
| Secure | Validation succeeded for the assessed zone. Check the hardening findings too |
| Insecure | No validated DNSSEC protection for the zone or delegation. A deployment choice, not a break |
| Bogus | Signed data or trust chain failed validation. Validating resolvers can reject your zone outright. Treat as urgent |
| Error | The state could not be established. Read the lookup or validation failure |
Some error responses explicitly say the delegation or signing records are missing. SSLBoard treats those as effectively unsigned rather than lumping them in with confirmed broken signatures. A general lookup failure stays an assessment failure.
Two different kinds of finding
Broken validation findings point at specific parts of the signing and delegation chain: expired signatures, signatures not yet valid, a parent DS record that does not match, missing DNSKEY or RRSIG records, and invalid signatures. Each points somewhere different, so keep the exact finding when you raise it with your DNS provider. “DNSSEC is broken” will cost you a day.
Hardening findings cover deprecated signing algorithms, weak keys, and reliance on SHA-1-only DS digests. Signature-expiry risk warns that signing which currently works needs operational attention before it does not.
Zone enumeration is its own thing. An NSEC zone-walking finding means your denial-of-existence records expose the names in your zone to enumeration. The signatures are valid. Assess it as information exposure, keeping in mind that public DNS names are not secrets and never were. Is NSEC3 the fix? covers the decision, including why the iteration count most people choose is the wrong one.
Fix and verify
For a broken zone, coordinate the authoritative DNS provider and the registrar together, so the signing keys and the parent delegation records agree. Changing one side blindly during a rollover is how most bogus zones happen in the first place.
For an unsigned zone, plan it as one change covering both signing and delegation, not two changes days apart.
Then wait for the DNS changes to be visible, retest, and confirm both the zone status and the specific findings. Check resolution through an actually validating resolver.
A Secure result authenticates the DNS data in scope. It does not validate your web certificate and says nothing about your application.