Subdomain Takeover: How Abandoned DNS Records Become an Attack Surface
A company can remove an old website and still leave behind a security problem. If its DNS configuration continues pointing to a hosting resource that has been released, another party may be able to claim that resource and publish content through the abandoned subdomain. This is the basic scenario behind a subdomain takeover.
The issue is not simply that a website has stopped working. The security concern is that the old domain configuration may still direct visitors to infrastructure where someone else can register the missing resource. Whether this is possible depends on the hosting provider and the state of the DNS configuration.
For website owners, developers, and security teams, understanding this distinction makes it easier to identify genuine exposure and avoid treating every broken subdomain as a vulnerability.
In this article
1. Understanding subdomain takeover
A subdomain is an address created beneath a primary domain. For example, help.example.com could host customer support, while events.example.com could be used for a temporary campaign.
Organizations frequently host these services on external platforms. Rather than running every application on their own servers, they configure DNS records to direct requests to cloud hosting providers, content delivery networks, website builders, or other services.
A subdomain takeover can occur when the organization stops using one of these services but leaves a DNS record pointing to it. If the provider allows an unauthorized person to claim the abandoned resource or hostname, that person may gain control over the content served through the subdomain.
For example, a record might continue pointing to a hosting platform after the original project has been deleted. The DNS entry can remain valid even though the intended website no longer exists. If the provider makes the corresponding resource available for registration, the abandoned configuration may become exploitable.
Three conditions to distinguish
- A stale DNS record: the record no longer serves its intended purpose.
- An unclaimed resource: the hosting platform no longer associates the destination with the original customer.
- A takeover opportunity: the platform permits an unauthorized party to claim the resource in a way that affects the organization's subdomain.
A stale record is a reason to investigate, but it does not automatically prove that a takeover is possible.
2. How DNS records create the risk
DNS translates domain names into information that systems use to locate services. A CNAME record, for example, aliases one hostname to another hostname. This is a common arrangement when a company connects its own domain to a third-party website platform.
Consider a hypothetical configuration in which promo.example.com points to a hostname supplied by an external hosting provider. The company publishes its campaign page, and visitors reach the expected content.
Later, the marketing team deletes the project because the campaign has ended. The DNS record is maintained by a separate service, so deleting the project does not necessarily remove that record. Requests may still reach the hosting provider, but the original project is no longer associated with the hostname.
The risk depends on how that provider handles abandoned resources. Some providers return a generic error and do not permit another customer to take over the relevant hostname. Others may allow a resource to be recreated or a custom domain to be registered again under conditions that make the leftover DNS record dangerous.
Consequently, security teams should investigate the provider's actual behavior rather than assume that every error page signals a claimable resource.
3. An example from website operations
Imagine that an organization launches a temporary product campaign at launch.example.com. Its marketing department uses an external landing-page service because the campaign needs to run for only a few months.
- The campaign launches. The company creates the landing page and configures the required DNS record.
- The campaign ends. The marketing team deletes the project or closes its hosting account.
- The DNS record remains. Nobody checks whether the record is still needed or removes it during the shutdown process.
- The configuration is discovered. A later review finds that the subdomain still directs requests to the external provider.
- The risk is assessed. The security team determines whether the destination is genuinely unclaimed and whether the provider allows another customer to control it.
If the provider permits the relevant resource to be claimed, an unauthorized person may be able to publish a page through the company's old subdomain. If the provider prevents such claims, the record may still be unnecessary or confusing, but the same takeover conclusion would not be justified.
Important: an error response alone is not proof of a vulnerability. DNS resolution, provider behavior, domain verification requirements, and the ability to control the exact hostname must be evaluated together.
4. Possible security consequences
The impact of a confirmed subdomain takeover depends on the subdomain's purpose, its relationship with other applications, and the browser security controls in place. A forgotten campaign address may have limited consequences, while a subdomain referenced by important parts of a website may create a more serious exposure.
| Potential consequence | Why it matters |
|---|---|
| Brand impersonation | A visitor may see a familiar company domain in the address bar and mistakenly trust content published there. |
| Phishing | A controlled subdomain can be used to host deceptive pages that imitate a legitimate service. |
| Unsafe script dependencies | If a vulnerable subdomain is trusted by a site's script-loading policy or referenced by application code, control of that subdomain may create a route to script injection or other client-side attacks. |
| Cookie-related exposure | Cookies scoped to a parent domain can create additional risk, depending on their attributes and the application's design. Cookies marked HttpOnly cannot be read directly by page JavaScript, and host-only cookies are not shared with sibling subdomains. |
| Reputation and trust damage | Visitors, customers, and security services may associate harmful content with the organization whose domain appears in the URL. |
These outcomes are possibilities, not automatic results of every takeover. For instance, controlling a subdomain does not by itself grant access to the primary website's server, its database, or every cookie associated with the organization.
Modern browser protections also affect the consequences. The same-origin policy separates different hostnames, cookie attributes restrict access in particular circumstances, and Content Security Policy rules can limit which sources a page may load. The exact configuration determines whether an additional vulnerability exists.
Why bug bounty teams investigate this issue
Security researchers may report a subdomain takeover when they can demonstrate that an organization has left a hostname pointing to a resource that an unauthorized party can control. The finding is especially relevant when the subdomain supports an important business function or is trusted by other parts of the organization's web infrastructure.
Bug bounty programs do not necessarily assign the same severity to every case. A nonfunctional, unused subdomain with no demonstrated security impact may be treated differently from a confirmed takeover that exposes users to phishing or affects a trusted application dependency.
A useful report therefore documents the affected hostname, the DNS relationship, the provider's response, the evidence of control, and the realistic impact. It should avoid making claims about account compromise, cookie theft, or cross-site scripting unless those consequences have actually been demonstrated within the program's rules.
5. How to assess a suspected takeover
Organizations can investigate their own domains by combining DNS inventory data with information about the services those records support. The aim is to distinguish an abandoned reference from a resource that another party could genuinely claim.
Start with an authorized inventory
Collect the subdomains and DNS records that the organization is responsible for managing. For each record, identify its destination, the service that owns that destination, the internal team responsible for it, and whether the service is still required.
Where the organization has access to its DNS provider's management console or authoritative zone data, those sources can help establish what records are configured. Public DNS lookups can supplement the inventory, but they may not reveal every record or explain why it exists.
Check the destination and provider response
Review records that point to external hosting services, especially those associated with projects that have been retired. Determine whether the destination still corresponds to a legitimate resource and whether the provider reports a missing configuration, an inactive project, or another condition requiring attention.
Provider-specific error messages can be useful indicators, but they are not definitive evidence on their own. The same response may occur for several reasons, including an incorrect configuration, a suspended service, a hostname that has not been verified, or a resource that cannot be claimed by another customer.
Verify the risk without taking control of third-party resources
When a record appears suspicious, use the provider's documentation and the organization's account records to establish whether the resource remains under authorized control. If further testing is necessary, follow the applicable bug bounty scope, written authorization, and provider rules.
Do not attempt to register or claim a resource belonging to another organization merely to see whether it is available. A defensive review should use the least intrusive method that can establish the problem and support remediation.
Assessment principle: a DNS lookup identifies a relationship between names; it does not establish ownership of a hosting resource. A reliable finding needs evidence that the configuration is abandoned and that the provider's behavior creates a real, actionable risk.
6. Practical prevention measures
The most effective defense is to manage DNS records and hosted resources as connected assets. Organizations should not treat domain configuration as a one-time setup that can be forgotten after a website launches.
Coordinate service shutdown with DNS cleanup
Include DNS review in the standard procedure for retiring a website, application, campaign, or SaaS subscription. Before deleting a hosted resource, identify the records that depend on it and decide whether those records should be removed, redirected, or retained for a documented reason.
The final shutdown check should confirm that the old service is no longer needed and that no DNS entry points to an abandoned, potentially claimable resource.
Maintain ownership information
Every important subdomain should have a known purpose and a responsible team. An inventory can record the hostname, record type, destination, business owner, service provider, last review date, and planned retirement date.
This information makes it easier to investigate an unfamiliar record and prevents DNS entries from becoming orphaned when staff members change roles or projects are discontinued.
Monitor for stale records
Run periodic checks against the organization's approved domain inventory. Flag records whose destinations no longer respond as expected, whose services have been retired, or whose provider configuration appears to be missing.
Automated checks should create investigation tasks rather than automatically label every provider error as a confirmed takeover. Provider behavior changes, and legitimate configuration problems can resemble abandoned resources.
Use provider-supported ownership verification
Some hosting services require proof of domain ownership before allowing a custom domain to be attached. When available, use these controls and keep verification records current. Such measures can reduce risk, but their effectiveness depends on the provider's implementation and whether the abandoned hostname can still be claimed through another path.
Remove unused DNS entries promptly
If a subdomain no longer serves a business purpose, remove its obsolete DNS records after checking for dependencies. If the hostname must remain available, point it to a properly controlled destination and ensure that the associated service cannot be claimed by an unauthorized account.
Be careful with changes to records used by active applications, email services, verification systems, or other business functions. Confirm the intended effect before deleting or modifying them.
7. Common misconceptions
Every broken subdomain can be taken over
False. A broken page may result from a service outage, an invalid destination, or a configuration error. A takeover requires a path for an unauthorized party to control the resource associated with the hostname.
A takeover automatically compromises the main website
Not necessarily. A subdomain takeover may affect that hostname without granting access to the primary site's server or database. Additional impact depends on shared application behavior, cookie scope, trusted scripts, authentication design, and other security controls.
HTTPS means the subdomain is safe
False. HTTPS protects the connection to the endpoint presenting a valid certificate for the requested hostname. It does not prove that the content is operated by the organization the visitor expects. Certificate issuance and hostname control are separate from the question of whether the current content is trustworthy.
Removing the DNS record is always the only required fix
Removing an unnecessary record is often the appropriate solution, but active services may require a replacement destination or a coordinated migration. The correct remediation should address both the DNS configuration and the ownership state of the hosted resource.
8. A maintenance checklist
Use the following checklist when reviewing an organization's DNS configuration or retiring an external website.
- Confirm that each subdomain has a documented business purpose.
- Identify the team responsible for each external hosting resource.
- Check whether the resource is still active and controlled by the organization.
- Investigate DNS records that point to missing or retired services.
- Confirm the provider's rules for custom-domain verification and resource reassignment.
- Remove or update records that are no longer required.
- Check whether other applications depend on the hostname before making changes.
- Schedule recurring reviews and retain records of completed remediation.
This process helps prevent abandoned DNS references from remaining unnoticed long after the associated service has been removed.
Conclusion
Subdomain takeover illustrates how a routine maintenance task can become a security issue. The original website may have been deleted correctly, yet its DNS configuration can continue directing visitors toward an external service. If that service permits an unauthorized party to claim the abandoned resource, the organization may lose control of content served through its own subdomain.
The solution is not simply to scan for error pages. Security teams need to establish which records are still required, verify that external resources remain under authorized control, and investigate whether a genuine takeover is possible. The resulting remediation may involve removing a stale record, restoring control of a resource, or changing the service's configuration.
Maintaining a documented DNS inventory, assigning ownership, monitoring for abandoned destinations, and making DNS review part of every service retirement provide a practical foundation for reducing this risk.
Key Takeaways
- Subdomain takeover can occur when an abandoned DNS record points to a resource that another party is able to claim.
- A stale DNS record or provider error does not, by itself, prove that a takeover is possible.
- Potential consequences include phishing, brand impersonation, and attacks involving trusted web dependencies.
- The impact depends on the affected hostname, provider behavior, and the organization's browser and application security controls.
- Defensive checks should distinguish suspicious records from confirmed, exploitable conditions.
- DNS cleanup should be part of the process for retiring websites, campaigns, and external services.
- Regular inventory reviews and clear ownership help prevent abandoned records from being overlooked.
Further reading
For additional background and guidance, consult these security resources:
- HackerOne: Subdomain takeover — an introduction to the vulnerability and its security implications.
- OWASP — security guidance for web applications and vulnerability management.
- ICANN — information about the domain name system and domain management.