dns.dangling_records Reviewed July 2026

Quick fix

Identify the business owner and intended service behind every reported record.

What this finding means

SecuTest follows bounded CNAME and address relationships and reports records whose external target is unresolved, retired, or otherwise consistent with an abandoned dependency. A dangling record is a configuration defect; takeover risk requires additional provider-specific evidence.

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 Potential subdomain takeover and trusted-origin abuse

How the attack or failure scenario works

A subdomain takeover occurs when DNS still points to a third-party resource that the legitimate owner has deleted, allowing another party to claim that resource. The attacker can then serve content under the organization's hostname and abuse user trust, links, cookies, OAuth redirects, or certificate issuance paths.

Conditions and limitations

  • A DNS record references an external service or resource that no longer exists.
  • The provider allows a different account to claim the exact referenced identifier.
  • The attacker successfully claims it before the organization removes or restores the DNS mapping.

Why it matters

Security and business impact A DNS record pointing to a retired or unresolved external dependency can break services and may become a subdomain-takeover path if the resource is claimable.

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. Identify the business owner and intended service behind every reported record.
  2. Remove obsolete DNS records immediately when the service is no longer required.
  3. If the service is required, recreate or claim the referenced resource in the authorized provider tenant before restoring traffic.
  4. Review certificates, cookies, OAuth redirects, webhooks, and logs associated with the hostname.

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.

Trace record
dig +trace affected.example.com

Inspect aliases
dig +short CNAME affected.example.com
dig +short A affected.example.com
dig +short AAAA affected.example.com

Verify the fix

  1. Run `dig +trace affected.example.com` and resolve the complete alias chain.
  2. Check the referenced resource in the authorized provider control plane.
  3. Confirm the hostname serves only the intended application from multiple resolvers.
  4. Repeat the scan after 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

  • Assuming NXDOMAIN alone proves the resource is claimable.
  • Deleting a record before confirming production dependencies.
  • Attempting to claim a production resource without explicit authorization.

Authoritative references