Dangling DNS and Subdomain Takeover: A Cleanup Checklist

Retiring a service can leave a domain pointing at something your organisation no longer controls. The application is gone, the cloud resource was deleted, but the DNS record remains. Under certain provider conditions, that mismatch can create a subdomain takeover risk.

Not every broken CNAME is exploitable, and an error page alone isn't proof of a takeover. The defensive task is to identify unresolved ownership, verify the provider's behaviour, and remove or reclaim references safely. This guide is a cleanup workflow for domains you own or are authorised to administer.

Understand the ownership gap

A subdomain such as help.example.com may point to a hosted service. DNS tells browsers where to go; the hosting provider decides which customer controls the destination. If the original resource is removed but the DNS reference survives, the two systems no longer share the same ownership state.

Microsoft's subdomain takeover guidance discusses dangling DNS and provider-side protections. Whether a specific record can be abused depends on the service, verification controls, and reclaiming rules. Don't assume that a generic scanner result establishes a confirmed vulnerability.

Focus first on exposure you can fix without proving exploitation. An abandoned public hostname is a maintenance problem even if the provider currently prevents reassignment. It can confuse users, break links, and become harder to assess as hosting arrangements change.

Build an inventory that joins DNS with resources

Export records from your authoritative DNS provider. Combine them with your cloud inventory, service contracts, application ownership list, and retirement tickets. A list of hostnames without owners will quickly become another stale spreadsheet.

Track hostname, record type, target, environment, business owner, resource identifier, and last verification date. Include campaign sites, preview environments, documentation portals, and vendors managed by departments outside engineering. Short-lived projects are easy to forget when the main production service gets all the attention.

For a public hostname you control, DNS Lookup can inspect supported record types. It doesn't establish provider ownership or prove takeover risk. Don't submit private internal names if your organisation's policy prohibits sending them to an external query service.

Triage suspicious records carefully

Flag references to deleted resources, targets with no owner, and destinations displaying a provider's unconfigured-service message. Then check the provider console and the original provisioning record. A temporary service failure can look like an abandoned target, so confirm before changing DNS.

Also look for multiple layers of delegation. A record may point to another hostname that points to a hosted resource. Follow the chain within your authorised inventory and identify who controls each step. A third-party vendor may be responsible for the final resource while your team owns the public DNS name.

Don't attempt to register or claim someone else's cloud resource to test a finding. For your own environment, use provider documentation and approved security procedures. The goal is safe ownership verification, not demonstrating an attack against an unrelated service.

Retire services in the right order

Before deleting a hosted resource, identify all DNS records and links that depend on it. Remove or repoint the public name as part of the retirement plan, account for caching, and verify that traffic no longer reaches the old destination before releasing ownership where applicable.

Keep the business owner involved. A supposedly unused hostname may support email links, an old mobile app, or a customer bookmark. If the service needs a replacement, route users to a controlled destination rather than leaving a confusing error page.

Document the completed checks in the retirement ticket. “Deleted from cloud console” is not enough. The ticket should explain what happened to DNS, certificates, application bindings, and any vendor-side domain verification.

Review cookie and trust implications

A forgotten subdomain can have consequences beyond its own content. Broadly scoped cookies, permissive trusted-origin lists, and authentication callbacks may increase the impact of losing control over a host. Review those relationships while cleaning up the DNS record.

Don't assume every subdomain shares the same sensitivity. A public campaign page and an authentication callback have different consequences. Rank remediation by exposed trust relationships, public use, and the confidence of the ownership gap.

For session design, see session cookie theft prevention. That guide explains why reducing cookie scope matters even when your main application is correctly secured.

Automate checks without creating false certainty

Run periodic comparisons between DNS targets and your resource inventory. Alert on new unowned records, not merely on all records that briefly fail to resolve. Attach evidence and an owner so an alert can lead to a decision.

Use CSV Viewer for a sanitised inventory export if a table makes review easier. It cannot check resource ownership, and private infrastructure exports should stay in an approved internal system. Treat automation as a way to surface questions, not as a replacement for provider-specific verification.

Recheck findings after remediation. Confirm the authoritative record, the expected public response, and the provider-side binding. Update the inventory so the next scan doesn't repeatedly rediscover a resolved issue.

Conclusion

Subdomain takeover prevention is largely ownership housekeeping. Join DNS records with actual resources, verify ambiguous findings, and coordinate DNS changes with service deletion. A retirement process that closes both sides of the relationship is more reliable than waiting for a scanner to notice the gap.