What makes a DNS record dangerous?
A subdomain takeover can occur when a name under your domain still points to an external service that your organization has stopped using, and someone else can claim the abandoned destination. The DNS record is “dangling”: it remains published even though the resource it was meant to reach is gone. DNS by itself does not give another person control of your domain, but it may direct visitors to content that person controls.
Consider an illustrative record such as shop.example.com pointing by CNAME to a hosted-service name. If the corresponding hosting project is deleted while the CNAME remains, the outcome depends on the provider’s rules. Some services prevent anyone else from attaching that hostname; others may allow a new account to claim it. A dangling record is therefore a reason to investigate, not proof that takeover is possible.
CNAME records are a common place to look, but they are not the only concern. Records pointing to reassigned IP addresses and delegated subdomains whose authoritative DNS is no longer controlled can also warrant review. The shared issue is a mismatch between the DNS configuration and who controls the destination.
Why an unused subdomain still matters
An old campaign page or retired application may seem harmless because few people visit it. Yet the name still sits beneath a domain that users may recognize. Links in saved documents, search results, emails, or other websites can continue to lead people there. If an unrelated party can serve content at that address, visitors may mistake it for an official page.
The effects depend on how the subdomain was used. A takeover might enable misleading pages or scripts loaded by another site that still references the old host. It does not automatically grant access to the main domain, existing accounts, or all cookies. Even so, an organization should not leave a trusted-looking address pointing to a destination it no longer manages.
Find and assess dangling records safely
Start with the DNS records you administer, including records in delegated subzones and any wildcard records. Compare each externally hosted destination with an inventory of active services and their owners. Ask a practical question for every entry: who maintains the destination, and what happens to this DNS name if that service is removed? Records without a clear owner deserve attention.
Look for clues rather than treating a single error page as conclusive. A CNAME that resolves to a provider but displays a “site not configured” message may indicate a missing service, a temporary misconfiguration, or a provider that safely reserves custom hostnames. Confirm the status with your own service inventory and authorized provider account. Do not try to claim an unfamiliar project or attach someone else’s hostname merely to test a theory.
Prioritize names that are linked from active pages or used for sign-in, downloads, or other sensitive workflows. Also check whether the record is still needed: a destination can be working yet belong to a vendor relationship that has ended. Document what you find so the service owner and DNS administrator can agree on the next step.
Remove the exposure without breaking a live service
If a subdomain is no longer needed, remove its DNS record through your normal change process. First check for legitimate traffic or dependencies, such as links, application settings, or verification steps. DNS changes may take time to be reflected by caches, so removal is not necessarily immediate for every visitor. Follow up to confirm that the published record has changed as intended.
If the subdomain must stay online, restore a destination your organization controls and verify the provider’s hostname-ownership settings. Where available, use provider features that reserve a custom domain for your account. Review any unexpected delegation separately: a subdomain handed to another set of name servers needs a known owner and a functioning zone, not merely a record that appears valid.
Avoid assuming that changing a DNS record alone removes content, credentials, or configurations left with a former provider. Retire those resources according to their own procedures. Conversely, do not delete a live provider project before accounting for the DNS names still pointing to it.
Make cleanup part of every service change
The simplest long-term defense is to connect DNS maintenance with the life cycle of each hosted service. When a team creates a subdomain, record its purpose, owner, DNS target, and associated service. When the team replaces or retires that service, include DNS review in the same checklist. This reduces the chance that a project disappears while its public name remains.
Periodically review external targets and delegated zones, especially after migrations or vendor changes. Assign someone to resolve records with no clear owner rather than leaving them indefinitely. A modest, repeatable review is more useful than relying on a one-time scan: it helps keep DNS aligned with the services your organization actually controls.
