dnssec.algorithm Reviewed July 2026

Quick fix

Confirm the authoritative DNS provider and registrar support a recommended algorithm.

What this finding means

SecuTest inspects published DNSKEY and DS algorithm identifiers and flags algorithms that current operational guidance considers obsolete or unsuitable. It does not attempt cryptanalysis; the finding is a policy-level cryptographic weakness.

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 Cryptographic downgrade and signature-forgery risk

How the attack or failure scenario works

DNSSEC signatures rely on public-key algorithms. Weak or deprecated algorithms may become easier to break, may be disabled by validating software, or may fail compliance baselines. Exploitation requires the ability to forge a valid signature or force reliance on the weak algorithm.

Conditions and limitations

  • The zone or delegation still publishes a deprecated algorithm.
  • Resolvers accept that algorithm rather than treating it as unsupported.
  • Direct forgery additionally requires sufficient cryptanalytic capability or key compromise.

Why it matters

Security and business impact Deprecated DNSSEC algorithms reduce cryptographic assurance and may fail modern resolver or policy requirements.

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. Confirm the authoritative DNS provider and registrar support a recommended algorithm.
  2. Introduce new DNSKEY and DS material with an overlap period.
  3. Wait for TTL and parent-delegation propagation before retiring the old algorithm.
  4. Document rollover ownership, emergency recovery, and monitoring.

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.

Inspect algorithms
dig +dnssec DNSKEY example.com
dig +short DS example.com

Validate chain
delv example.com A

Verify the fix

  1. Inspect DNSKEY and DS algorithm numbers.
  2. Validate the complete chain before and after the rollover.
  3. Confirm no obsolete DS remains at the registrar.
  4. Repeat the scan from independent validating resolvers.
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

  • Changing DNSKEY without updating the parent DS.
  • Performing an algorithm rollover without overlap.
  • Leaving an obsolete DS active after the new key is deployed.

Authoritative references