A company owns company.com. That much is clear. Their registrar shows it. Their DNS is configured by them. Nobody disputes it.
But one of their subdomains, blog.company.com, starts serving content the company didn't put there.
The company didn't lose their domain. The DNS record is still theirs. So what happened?
Two Different Things Called "Ownership"
When an organization creates a subdomain like blog.company.com, they control the DNS record for it. That record typically points somewhere: a cloud hosting platform, a SaaS documentation tool, a CDN distribution, a third-party service.
Here's the part that trips people up: controlling the DNS record and controlling the resource it points to are not the same thing.
The DNS record says: "When you ask for blog.company.com, go here."
But "here" is often infrastructure owned and operated by an external provider. The organization doesn't own that infrastructure. They have a project or account on it.
company.com (organization owns this)
↓
blog.company.com DNS record (organization controls this)
↓
CNAME → company-blog.hosting-platform.example
↓
Hosted resource (external provider owns and manages this)
That separation is normal and useful. The issue appears when one side of that relationship goes away.
What a Dangling DNS Record Is
Organizations create infrastructure constantly: marketing pages, documentation sites, staging environments, developer tools, short-lived campaign sites. Resources get provisioned and later deleted. Teams change. Projects wind down.
When an external resource is deleted, the DNS record that pointed to it often doesn't get cleaned up. Nobody removes it because nobody thinks to. The original team moved on. The infrastructure list wasn't updated.
The DNS record still exists. It still points to where the resource used to be. But the resource itself is gone.
This is a dangling DNS record: a valid hostname pointing to an external destination where the referenced resource no longer exists.
A dangling record by itself isn't necessarily dangerous. The next question is whether that vacancy can be filled by someone else.
When It Becomes a Takeover
Some external providers allow new users to claim a resource at the same identifier that a previous account used. This is often by design. Platforms need to recycle project names, subdomains, or endpoints so they can be reused.
If that's possible, an attacker can do the following:
- Find a subdomain that still points to an external platform.
- Discover that the resource on that platform is no longer active.
- Create a new account on that platform and claim the same identifier.
- The organization's DNS record now points to the attacker's resource.
User visits blog.company.com
↓
DNS resolves via CNAME
↓
Hosting platform
↓
Attacker's claimed resource
↓
Attacker-controlled content served under company's subdomain
The attacker didn't touch company.com. They didn't modify the DNS record. They simply occupied a vacancy that the DNS record kept pointing at.
Why That Subdomain Context Matters
Content served under blog.company.com inherits the visual and reputational context of the organization. A visitor navigating there sees the company's domain in the address bar. It looks legitimate. The TLS certificate may resolve without errors because it's issued for a valid hostname.
Depending on what the subdomain was previously used for and how the organization's other applications are configured, consequences can range from reputational damage and phishing risk to more significant issues in some architectures.
That said, the exact impact isn't fixed. It depends on what the subdomain was used for, how cookies are scoped, whether other services trust that hostname, and what the attacker actually does with it. Subdomain takeover doesn't automatically break session security or compromise parent domain applications. But serving attacker-controlled content under a trusted hostname is still a meaningful security failure.
The Ownership Boundary Is the Core Idea
It's worth being precise here because the setup is counterintuitive.
The organization did not lose its domain. company.com is still registered in their name. Their DNS is still under their control. Nothing was stolen.
What happened is that DNS ownership and resource ownership have separate lifecycles, and only one of them was maintained.
Who controls company.com?
→ The organization.
Who controls the DNS record for blog.company.com?
→ The organization.
Who controls the resource that record points to?
→ The external provider manages the platform.
The organization controlled a resource on it.
That resource no longer exists.
The provider may allow someone else to claim it.
The organization's authority stops at the DNS record. It doesn't extend into the external provider's resource namespace. When the resource was deleted, that external slot opened up.
How This Differs From Similar Problems
DNS rebinding works differently. It involves changing DNS resolution over time, causing a client to connect to a different IP address than it resolved initially. The manipulation happens through DNS TTL and timing. Subdomain takeover is a static configuration problem, not a dynamic resolution problem.
Domain hijacking is about unauthorized control of the domain registration itself or the DNS authority. The attacker gains the ability to change DNS records for the domain. In a subdomain takeover, the organization retains full control of their DNS. The attacker never touches it.
Dangling DNS is the underlying condition. Subdomain takeover is the security consequence when an attacker can claim the external resource that the dangling record points to.
Defenses That Follow From the Mechanism
Because the problem is a configuration drift between DNS records and external resources, the defenses are about keeping those two things synchronized.
Remove DNS records when external resources are deleted. This is the most direct fix. When a project is decommissioned, the DNS record should be decommissioned with it. The challenge is that this requires DNS and infrastructure changes to be coordinated rather than handled by separate teams independently.
Inventory subdomains and track what they point to. Many organizations don't have a clear map of which subdomains exist and which external services they depend on. Without that visibility, stale records are easy to miss.
Include DNS in infrastructure lifecycle processes. Provisioning a new resource and creating a DNS record should be a paired operation. Deleting a resource and removing its DNS record should be equally paired.
Monitor for dangling references. Organizations can periodically verify that DNS records resolve to resources they still control. A record that points to an unclaimed external resource is a signal worth acting on.
Monitoring catches drift, but the more fundamental fix is keeping DNS and external resource lifecycles synchronized from the start.
The Mental Model
A domain name is an address. An address tells you where to go. It doesn't say anything about who currently controls the destination.
When an organization creates a subdomain that points to an external service, they're establishing a relationship between a hostname they own and a resource they control on someone else's infrastructure. Both sides of that relationship need to stay maintained.
If the external resource is deleted and the DNS record isn't, the address still exists. The destination is just vacant. And in some cases, vacant can be claimed.
The company still owns the domain. The DNS record is still valid. The problem is what that record has been pointing to.
A hostname can continue looking legitimate long after the infrastructure behind it changed hands.
Top comments (0)