Subdomain Takeover: Find Dangling DNS First

Cloud resources are temporary; DNS records tend to live forever. When a CNAME, A, NS or MX record still points to a released service, an attacker may be able to claim the target and serve content under a trusted hostname. That is a subdomain takeover.

This is not primarily a scanning problem. It is a lifecycle and ownership problem. The durable fix connects DNS changes to resource provisioning and decommissioning.

How a Takeover Becomes Possible

A team creates a subdomain for a storage bucket, PaaS app, CDN distribution or support portal. Months later, the resource is deleted but the DNS record remains. If the provider lets another customer claim the orphaned name, the attacker gains control of the organization’s subdomain.

The OWASP Subdomain Takeover Prevention Cheat Sheet emphasizes that a dangling record is dangerous when the downstream resource is claimable.

Impact may include:

• convincing phishing on a trusted domain;
• cookies exposed by overly broad domain scope;
• CSP or OAuth allowlist bypass;
• certificate issuance for the subdomain;
• malicious email or password-reset reception;
• damage to brand and search reputation.

Inventory DNS With Ownership

For every external record, store business purpose, owner, environment, target resource, provider, creation date and planned retirement. Manage DNS and cloud resources in the same infrastructure-as-code workflow where possible.

The inventory should answer one question quickly: who can confirm that this target still exists? Records without an active owner are high-priority debt.

Use the subdomain finder to compare observed names with the inventory and DNS history to understand when a target changed.

Detect Dangling Records Safely

Resolve each record recursively and classify failures. A CNAME returning NXDOMAIN deserves review, but failure alone does not prove exploitability. Check provider-specific ownership controls and response fingerprints without attempting to claim resources you do not own.

Monitor:

• CNAME targets that no longer resolve;
• cloud error pages indicating an absent resource;
• released IP addresses outside approved ranges;
• stale NS delegation;
• MX records pointing to retired services;
• unexpected certificates in CT logs.

Run checks continuously and immediately after infrastructure changes. Weekly scanning is better than an annual audit, but event-driven validation is stronger.

Fix the Decommissioning Order

The safe sequence is:

1. serve a redirect or maintenance response if continuity matters;
2. remove or update the DNS record;
3. wait for TTL and propagation;
4. verify external resolvers no longer reach the resource;
5. release the cloud or SaaS resource.

Deleting the resource first creates the takeover window. Encode the order in runbooks, pull-request checks and automation.

Incident Response

If takeover is suspected, remove or repoint the DNS record immediately. Preserve the current response, certificates, DNS answers and provider logs. Reclaim the resource only through an authorized account and according to provider guidance.

Review cookies, CSP, OAuth redirect URIs, email routing and any trust relationship covering the hostname. Block malicious URLs with the URL scanner and reputation workflow, notify users when exposure is credible and monitor CT for replacement certificates.

Avoid Common Scanner Mistakes

Do not report every NXDOMAIN as exploitable. Do not create a provider resource as a “proof” without written authorization. Do not rely indefinitely on provider fingerprints copied from public tools; services change error pages and ownership controls.

Prioritize verified claimability, sensitive trust relationships and active traffic. A dormant lab hostname and a wildcard-trusted authentication callback do not carry the same risk.

Metrics

Track records without owners, dangling targets, time to remediation, decommissioning changes completed in the safe order and repeated findings by team. The long-term success metric is fewer orphaned records created, not more scanner alerts.

Conclusion

Subdomain takeover is preventable when DNS and resources share one lifecycle. Inventory ownership, validate continuously and remove the record before the service. Pair subdomain enumeration with disciplined decommissioning so trusted names cannot outlive the systems behind them.