Audit all DNS records pointing to external services. Delete records for decommissioned applications. Ensure active third-party services remain subscribed and configured. Monitor for dangling CNAME records that resolve to null hosts, which indicate immediate takeover risk.
The Anatomy of a Dangling Record
A subdomain takeover occurs when an attacker registers a domain name that your organisation has already configured in its DNS, but no longer hosts content for. This happens because DNS records are persistent. When you remove a service from a cloud provider, the provider’s server stops responding. However, your public DNS record still points to that provider’s address.
The DNS record now points to an empty slot. The cloud provider sees the incoming traffic and recognises that the specific subdomain is unclaimed. It allows anyone to register that subdomain on their platform. The attacker registers it, serves malicious content, and your DNS continues to direct users to them.
This mechanism bypasses many security controls because the domain is legitimately yours. The certificate authority issued a valid TLS certificate for that subdomain. Email filters may allow messages from that address. The attacker inherits your reputation.
Why Manual Audits Fail
You cannot rely on quarterly manual checks to find these gaps. The attack surface changes daily. New services are spun up for testing. Old environments are decommissioned. Documentation rarely keeps pace with infrastructure changes.
Imagine a development team spins up a staging environment on a cloud platform. They create a DNS record for staging.example.com. After the project ends, they delete the cloud instance. They forget to update the DNS. Six months later, a security researcher finds the dangling record.
By the time you find it, the attacker has already used it. They may have hosted a phishing page that mimics your login portal. They may have served malware. The damage is done before you even know the record was dangling.
This is why exposure management is critical. You need continuous visibility into what your domain resolves to, not just what you think it resolves to.
Priority One: Remove Orphaned Records
The most effective prevention is elimination. If a subdomain does not serve a business purpose, delete its DNS record. This removes the vector entirely. There is no record to hang, so there is nothing to take over.
Start with your internal asset inventory. Cross-reference every DNS record against your active service list. Look for records pointing to third-party platforms. Check if the service is still active. If the platform returns a "not found" error for that specific subdomain, the record is dangling.
Delete these records immediately. Do not leave them in a "pending deletion" state. Ensure your DNS management policy requires explicit approval to keep records for decommissioned services. This reduces your attack surface to only what is actively managed.
Priority Two: Monitor for Dangling CNAMEs
You cannot delete records that you do not know exist. Continuous monitoring is the second line of defence. Use automated tools to scan your domain’s DNS records regularly. Look for CNAME records that point to external hosts.
Check if the target host responds. If the target returns a generic error page indicating the subdomain is not configured, you have a risk. Some platforms return a 404, others return a 500 error. The key is that the server is live but the specific tenant is missing.
Integrate this monitoring into your security operations. Alert your team when a new dangling record is detected. Prioritise remediation based on the value of the subdomain. A record for dev.example.com is less risky than login.example.com, but both must be fixed.
| Measure | Effort | What it stops |
|---|---|---|
| Delete orphaned DNS records | Low | Eliminates the vector entirely for known assets. |
| Automated DNS monitoring | Medium | Detects new dangling records before attackers claim them. |
| Redirect unused subdomains | Low | Prevents attackers from serving content on known unused names. |
Priority Three: Redirect Unused Subdomains
For subdomains that must remain in DNS for legacy reasons, redirect them. Use a CNAME or A record to point them to a central sinkhole or a parked page. This page should clearly state that the subdomain is not in use.
This prevents attackers from serving their own content. If the attacker tries to register the subdomain on the cloud platform, the platform will see that the DNS record points elsewhere. Some platforms will refuse to allow the registration if the DNS does not match their expected configuration.
Even if the platform allows it, the redirect ensures users see your warning page. This breaks the illusion of legitimacy. It also makes it harder for attackers to host phishing content, as the content does not match the domain’s expected behaviour.
See also: Exposure Management: Concrete Benefits and Hidden Limitations · Exposure Management Practices to Reduce Attack Surface
What Does Not Work
Many teams assume that strict access controls prevent takeover. This is incorrect. The vulnerability exists in the DNS configuration, not in the application code. You do not need to exploit broken access control to take over a subdomain. You only need to find the dangling record and register it on the provider’s side.
Similarly, strong passwords and weak password policies are irrelevant here. The attacker is not logging into your system. They are registering a new account on a third-party platform. The platform verifies that the DNS record points to them. It does not check your password strength.
Do not waste resources on application-layer fixes for a DNS-layer problem. Focus on the DNS records. Focus on the lifecycle of those records.
Integrating with Broader Security
Subdomain takeover is a form of exposure. It reveals gaps in your asset management. It shows where your documentation fails. It highlights the disconnect between infrastructure and security.
Addressing this issue supports your broader security goals. It reduces the risk of command injection attacks, as attackers often use taken-over subdomains to host malicious scripts. It mitigates the impact of exploit kits, which may use trusted domains to bypass filters.
It also prevents the abuse of end-of-life software. Attackers may use taken-over subdomains to host old, vulnerable versions of software that you no longer support. By controlling your DNS, you control where that software can be hosted.
Closing Checklist
- Audit all DNS records pointing to third-party services. Delete any that point to inactive or deleted services.
- Implement automated monitoring for dangling CNAME records. Alert your team when a record points to an unconfigured host.
- Redirect unused subdomains to a central sinkhole or parking page. Ensure the page clearly states the subdomain is not in use.
Key takeaways
- Dangling DNS records occur when a service is deleted but the domain record remains, creating a takeover vector.
- DNS monitoring tools detect these orphaned records faster than manual audits can.
- Redirecting unused subdomains to a central sinkhole prevents attackers from claiming them.
Subdomain takeover exploits the gap between DNS records and active services. Remove orphaned records and monitor continuously to close this gap.
Frequently asked questions
How do I know if a subdomain is vulnerable to takeover?
Check if the DNS record points to a third-party service. Then, try to access the subdomain. If the service returns a "not found" or "unconfigured" error, it is vulnerable.
Can DNSSEC prevent subdomain takeover?
No. DNSSEC protects against DNS spoofing. It does not prevent an attacker from registering a valid subdomain on a platform if the DNS record is dangling.
How often should I audit my DNS records?
You should monitor them continuously. Manual audits are too slow. Automated tools can detect new dangling records in real-time.
What is the first sign of a subdomain takeover?
A security researcher or automated scanner reporting a dangling record. You may also see unusual traffic to a subdomain you do not recognise.
How this guide was produced: written by the Breach Observer editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.