A product team deletes an old hosted application, the cloud resource disappears, and the monthly bill stops. The public hostname often survives. Months later, preview.example.com still resolves through a CNAME to a provider-specific name associated with a resource that no longer exists. From the organisation’s perspective the application is gone. From DNS’s perspective, authority is still being delegated.
That mismatch creates the conditions associated with subdomain takeover. The important detail is not simply that a DNS record points at a dead destination. Exploitation also depends on the external service allowing another party to claim the referenced name, tenant, site, bucket, project, or equivalent routing identifier. A dangling record is therefore evidence of stale control; whether it is directly exploitable depends on the provider’s ownership model.
The security impact can be larger than the abandoned application suggests. A hostname under an established domain inherits trust from browsers, users, integrations, allowlists, and sometimes cookie or content policies. Retiring compute without retiring that authority leaves a fragment of the old system alive in a place that operational inventories often overlook.
DNS outlives the resource it describes
Cloud and hosted platforms encourage loose coupling between names and resources. A DNS record may point to a load balancer, object storage website, deployment platform, CDN distribution, support portal, marketing service, or another managed endpoint. This separation is useful: infrastructure can change while a stable public name remains.
It also means the lifecycle of the DNS record is independent from the lifecycle of the destination.
Consider a CNAME from campaign.example.com to a provider hostname. The provider maps incoming requests to a tenant based on the hostname or an associated custom-domain configuration. If the tenant is deleted first, the CNAME can remain globally visible. An attacker who can create a new tenant matching the abandoned provider-side identifier may be able to make the provider serve attacker-controlled content for campaign.example.com.
The exact claim process varies substantially among services. Some providers reserve deleted identifiers, require domain ownership validation, prevent cross-account reuse, or retain custom-domain bindings after resource deletion. Others may permit reuse under defined conditions. As a result, an error page or NXDOMAIN response at the target is not enough to establish takeover. The relevant question is whether control of the destination can be reacquired by an unauthorised party while the organisation’s DNS still directs traffic there.
This distinction matters operationally. Treating every broken CNAME as an active compromise produces noisy findings. Treating broken records as harmless because the application is offline misses the authority that DNS still conveys.
The hostname carries more trust than the retired workload
A forgotten subdomain can matter even when it once hosted low-value content. Security boundaries frequently depend on domain relationships that are broader than application ownership.
Users may recognise the parent domain and trust a page served beneath it. External systems may allow traffic or callbacks based on hostname patterns. Security products may assign reputation at the registrable-domain level. Search results, old documentation, QR codes, emails, and third-party links can continue sending visitors to a hostname long after the original service has been removed.
Browser state can add further consequences, although those consequences depend on configuration. Cookies with a Domain attribute can be sent to matching subdomains subject to normal cookie rules; host-only cookies are narrower and are not shared in that manner. A takeover does not automatically expose cookies, and attributes such as Secure, HttpOnly, SameSite, path scope, prefixes, and application design all affect what is reachable or useful. Still, broad cookie scope turns forgotten subdomains into a more consequential part of the web security boundary.
Content controls can create similar coupling. A Content Security Policy that permits scripts or frames from a broad wildcard beneath an organisation’s domain may grant a compromised subdomain a role the retired application never needed. OAuth redirect allowlists, CORS policies, webhook destinations, and enterprise proxy rules can also preserve assumptions about names after the underlying service changes.
This is the deeper problem with dangling DNS: the record is not merely stale configuration. It can preserve an identity that other systems continue to treat as organisationally controlled.
Provider behavior determines exploitability
Subdomain takeover is often described as a DNS flaw, but DNS is only one half of the mechanism. The other half is resource assignment at the service receiving the traffic.
A provider that accepts arbitrary custom domains without demonstrating control creates a different risk profile from one that requires a fresh DNS challenge before binding a hostname. Likewise, a platform that permanently associates a custom domain with the original account behaves differently from one that releases the binding immediately after deletion.
Strong ownership checks reduce the chance that stale DNS can be converted into active control. They do not make stale records desirable. A provider can change product behavior, an account can be migrated, or a record can later be repointed to a service with weaker binding. Stale names also complicate inventories and incident analysis.
Custom-domain verification is most useful when it proves current control at the moment a binding is created and when the platform prevents another tenant from serving the hostname after that proof becomes stale. A one-time check followed by unrestricted reassignment can leave a gap during deletion and recreation. Provider-side safeguards and customer-side lifecycle controls reinforce each other; neither should be treated as a substitute for the other.
DNS record types also affect the shape of the issue. CNAME records make the dependency visible because they name another hostname, but aliases, provider-specific apex records, and direct address records can become stale as well. A direct A or AAAA record pointing to a released cloud address can create a related reassignment risk if that address can later be allocated to another tenant. The mechanism is different from reclaiming a named SaaS resource, but the operational mistake is similar: public routing authority remains after destination ownership ends.
Decommissioning order is a security control
The safest retirement process treats DNS as part of the service rather than as external housekeeping.
Deleting the provider resource first creates a window in which the public name remains delegated but the destination may become available for reassignment. Removing or neutralising the public DNS mapping before releasing the resource closes that window for normal resolution, while the organisation still controls both sides of the relationship.
DNS caching means the transition is not instantaneous. Recursive resolvers can retain records according to their effective TTL, and clients may have additional caching behavior. Lowering TTL shortly before a planned migration can reduce persistence, but changing the TTL at the same moment as deletion does not evict records already cached under the previous value. High-risk retirements benefit from planning that accounts for this residual period.
A controlled sequence usually includes identifying every public name attached to the resource, removing external dependencies, changing DNS to a destination still controlled by the organisation or removing the record, waiting for an appropriate cache period when the risk warrants it, and only then releasing provider-side identifiers that could be reassigned.
That sequence is not ceremonial process. It preserves continuous ownership while authority is being withdrawn.
The reverse relationship also matters during migrations. A team may move a hostname to a new platform and assume the old provider binding is irrelevant once DNS changes. Keeping obsolete custom-domain bindings around can create confusing ownership state and future conflicts. Decommissioning should remove stale authority on both sides: DNS should no longer reference retired infrastructure, and retired infrastructure should no longer claim names it does not serve.
Inventory has to include relationships, not just records
A DNS zone export can identify records, but it cannot by itself determine whether their targets are still owned. Useful detection requires joining DNS data with infrastructure and provider state.
The central relationship is simple: hostname, DNS target, provider resource, owning account or project, responsible team, and expected lifecycle should agree. Drift among those elements is the signal.
This is difficult in organisations with delegated zones, multiple registrars, acquired domains, SaaS products purchased directly by business teams, and infrastructure spread across cloud accounts. Passive DNS and certificate data can help discover names that central inventories missed, but neither source proves current ownership. Certificate issuance shows that a name has participated in a certificate workflow; it does not establish that the corresponding application still exists or that a particular DNS target is safe.
Automated checks are most effective when they are provider-aware. Generic scanners can flag suspicious response signatures or unresolved targets, but provider error messages change and false positives are common. A stronger check asks whether the referenced resource exists in an account the organisation controls and whether the provider considers the custom-domain binding owned.
That model also avoids an unsafe verification pattern: attempting to claim an apparently abandoned third-party resource merely to prove that it is claimable. Production security programs should not need to take control of external resources to establish that lifecycle state is inconsistent. Provider documentation, account inventory, DNS state, and authorised validation mechanisms offer safer evidence.
Wildcards and delegation expand the search space
Not every risky name appears as an obvious individual CNAME.
Wildcard DNS can route large sets of undeclared hostnames toward shared infrastructure. That can be intentional, especially for multi-tenant applications, but it makes the serving layer responsible for rejecting unknown hosts safely. If a platform turns any hostname under a wildcard into a claimable tenant identifier, the DNS design has effectively delegated a broad namespace to the application.
Delegated subzones create another ownership boundary. A parent zone may contain an NS delegation to nameservers operated by a team, vendor, or cloud service. If the delegated zone is abandoned while the parent delegation remains, the resulting failure mode differs from a single dangling CNAME but carries the same governance concern: authority persists after operational ownership has ended. The practical risk depends on whether the delegated infrastructure or nameserver relationship can be acquired or influenced by another party.
These cases are a reminder that DNS inventory should model delegation, not just endpoint resolution. A hostname can be under organisational authority in the registry and parent zone while its effective control has moved elsewhere.
Ownership evidence should expire with the service
Many organisations have a clean provisioning path and an informal retirement path. New services receive tickets, infrastructure definitions, DNS records, certificates, monitoring, and ownership metadata. Old services are deleted when someone notices the cost.
That asymmetry is expensive in security terms. Public names are durable, globally visible references. They should have an owner and an expected destination for as long as they resolve.
Infrastructure as code helps when DNS and the referenced resource share a lifecycle, but it is not sufficient if manual records, SaaS dashboards, or separate repositories can outlive the stack. Periodic reconciliation remains valuable: enumerate authoritative DNS, resolve external dependencies, map them to known resources, and investigate names whose ownership cannot be demonstrated.
The strongest signal is not that a hostname returns an error. It is that the organisation can no longer produce current evidence that it controls the system receiving traffic for that hostname.
Service retirement is complete only when that authority has been withdrawn. Compute deletion removes a workload. DNS cleanup removes the public claim that the workload still belongs to the organisation.