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 and DNSKEY relationships, signatures, and validation outcome. A validation failure is more serious than an intentionally 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, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type DNS spoofing, cache poisoning, and DNS availability failure

How the attack or failure scenario works

DNSSEC lets resolvers verify that DNS data was signed by the authoritative zone and has not been altered. Without validation, an attacker who can poison or intercept DNS may redirect users. With a broken signed chain, validating resolvers return failure, causing an outage.

Conditions and limitations

  • For spoofing, the attacker must influence a resolver, cache, delegation, or network path.
  • For outage, the parent DS and child DNSKEY or signatures must be inconsistent or expired.
  • Clients or recursive resolvers must perform DNSSEC validation for the result to matter.

Why it matters

Security and business impact Broken DNSSEC can make a signed domain unreachable to validating resolvers, while an unsigned zone lacks cryptographic authenticity for DNS answers.

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 at the registrar or restore the matching DNSKEY at the authoritative provider.
  3. Roll keys using documented overlap and TTL procedures.
  4. Monitor validation from independent resolvers before removing old keys or signatures.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Validate answer
dig +dnssec example.com A

Full validation
delv example.com A

Inspect delegation
dig +short DS example.com
dig +short DNSKEY example.com

Verify the fix

  1. Run `dig +dnssec example.com A` and inspect signatures.
  2. Run `delv example.com A` or an equivalent validating resolver test.
  3. Confirm DS and DNSKEY digests match at the parent and child.
  4. Repeat the scan after registrar and DNS propagation.
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 cached DS or signatures expire.
  • Assuming the AD bit from a non-validating resolver proves validation.

Authoritative references