dnssec.validation Reviewed July 2026

Quick fix

Determine whether the zone is intentionally unsigned or expected to be signed.

What this finding means

SecuTest checks the delegation chain, DS/DNSKEY relationships, signatures, and validation outcome. A validation failure is more serious than an unsigned zone because validating clients may reject all affected answers.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, or business intent when those cannot be proven remotely.

Why it matters

Security impact Broken or absent DNSSEC validation can leave DNS answers without cryptographic authenticity or make a signed zone unreachable to validating resolvers.

Step-by-step fix

Where to make the change

  • The authoritative DNS provider and, for DNSSEC delegation, the domain registrar.
  • The cloud, CDN, SaaS, or hosting tenant referenced by the affected DNS record.

Remediation procedure

  1. Determine whether the zone is intentionally unsigned or expected to be signed.
  2. For a broken chain, publish the correct DS value at the registrar or restore the matching DNSKEY at the authoritative provider.
  3. Roll keys using the provider's documented overlap procedure.
  4. Monitor validation before removing old keys or signatures.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, or provider values shown in your SecuTest evidence.

Trace authoritative DNS
dig +trace example.com

Inspect common records
dig +short A example.com
dig +short AAAA example.com
dig +short CNAME host.example.com

Verify the fix

  1. Run: dig +dnssec example.com A
  2. Run: delv example.com A
  3. Confirm the chain validates from independent public validating resolvers.
  4. Repeat the SecuTest scan.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Publishing a DS record before the matching DNSKEY is active.
  • Removing an old key before caches expire.
  • Assuming the AD bit from a non-validating resolver proves validation.

Authoritative references