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.
Why it matters
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
- Identify the business owner and intended service behind every reported record.
- Remove obsolete DNS records immediately when the service is no longer required.
- If the service is still required, recreate or claim the referenced resource in the correct provider account.
- Review certificate issuance, CDN, SaaS, and cloud logs for unexpected use of the hostname.
Commands and configuration examples
Replace example values with the hostname, selector, IP address, port, or provider values shown in your SecuTest evidence.
dig +trace example.com
dig +short A example.com
dig +short AAAA example.com
dig +short CNAME host.example.com
Verify the fix
- Run: dig +trace affected.example.com
- Resolve the complete CNAME chain from at least two external resolvers.
- Confirm the target exists in the authorized provider account.
- Repeat the SecuTest scan after DNS propagation.
After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.
Common mistakes
- Assuming NXDOMAIN alone proves exploitability.
- Deleting a record before confirming production dependencies.
- Recreating the resource in the wrong region or tenant.