What Is a Dangling DNS Record, and How Does It Lead to Subdomain Takeover?
You spin up a marketing microsite on a cloud platform, point promo.example.com at it with a CNAME, run the campaign, and delete the app when it is over. The DNS record stays, because nobody remembers it. Months later, someone else creates an app on the same platform with the same name, and suddenly your subdomain is serving their content, with your brand in the address bar. That forgotten record is a dangling DNS record, and the attack it enables is called subdomain takeover. This article explains how dangling records happen, why they are so dangerous, how to find them in your zones, and the processes that stop them from appearing. If you need a refresher on the record types involved, see A records vs CNAME records.
What Is a Dangling DNS Record?
A dangling DNS record is a record in your zone that points to a resource you no longer own or control. The record itself is valid DNS. The problem is what is on the other end: a deleted cloud app, a released IP address, an unclaimed storage bucket, or a name server zone that no longer exists.
On its own, a dangling record is just broken. It becomes a security issue when the resource it points to can be claimed by someone else. Many cloud and SaaS platforms let any customer create a resource with a chosen name, such as an app called example-promo that lives at example-promo.azurewebsites.net. If your CNAME still points there and you have released that name, anyone can register it and receive your subdomain's traffic.
How Subdomain Takeover Works
The sequence is almost always the same:
- You provision a resource on a third-party platform, for example a static site, an app service, a storage bucket, or a CDN endpoint.
- You point a subdomain at it, usually with a CNAME to the platform's hostname.
- You deprovision the resource but leave the DNS record in place.
- An attacker finds the dangling record. Attackers scan certificate transparency logs, passive DNS datasets, and brute-forced subdomain lists for CNAMEs pointing at known platforms whose targets no longer exist.
- The attacker claims the resource name on the same platform in their own account.
- Your subdomain now serves their content. Because the platform routes traffic by hostname, and your DNS sends your hostname to their resource, the platform happily serves it.
Here is what a dangling CNAME looks like with dig:
dig promo.example.com CNAME +short
# example-promo.azurewebsites.net.
dig example-promo.azurewebsites.net A
# ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, ...
The first lookup shows your record still pointing to the platform. The second shows the target no longer exists, which is the classic signature. An NXDOMAIN on the target of a CNAME that points into a cloud platform is a strong sign the name could be claimed. See what NXDOMAIN, SERVFAIL, and REFUSED mean for more on reading these responses.
Not every vulnerable record returns NXDOMAIN. For some services, the platform hostname keeps resolving, and the takeover signal is instead an HTTP error page such as "NoSuchBucket" from an object storage service or a "There isn't a site here" style message from a hosting platform.
Types of Dangling Records
Dangling CNAME Records
The most common case. A CNAME points to a platform hostname that has been released:
; Zone file excerpt for example.com
promo 3600 IN CNAME example-promo.azurewebsites.net.
docs 3600 IN CNAME example-org.github.io.
assets 3600 IN CNAME assets.example.com.s3-website-us-east-1.amazonaws.com.
shop 3600 IN CNAME example-shop.myshopify.com.
Each of these is safe while the resource exists and is owned by you. Each becomes a takeover risk the moment it is deleted while the record remains. Platforms that have historically been affected include app hosting, static site hosting, object storage website endpoints, CDNs, help desk and status page services, and many smaller SaaS tools.
Dangling A and AAAA Records
An A record pointing at a cloud IP address you have released is also dangerous:
api 300 IN A 203.0.113.45
If 203.0.113.45 was an elastic or static public IP that you released back to the provider, it will eventually be assigned to another customer. That customer then receives traffic for api.example.com. This is harder for an attacker to exploit deliberately, since they cannot choose which IP they get, but attackers do cycle through allocations looking for addresses that still have DNS pointing at them.
Dangling NS Delegations
The most severe variant. If you delegate a subdomain to a set of name servers with NS records, and the zone on those servers is later deleted, some DNS providers allow another customer to create a zone with the same name on the same servers:
dev 3600 IN NS ns-1234.dns-provider.example.
dev 3600 IN NS ns-5678.dns-provider.example.
Whoever claims that zone controls every record under dev.example.com, not just one hostname. That includes the ability to obtain certificates and receive email for it. Many large providers now randomize name server assignment to make this harder, but it remains a risk with some providers and with self-hosted name servers you have decommissioned.
Dangling MX Records
An MX record pointing at a mail service you no longer use can allow someone else who sets up that service to receive mail for your domain or subdomain. Mail servers deliver to whatever host your MX record names, so a stale entry is a direct path to intercepted mail.
Why Subdomain Takeover Is Dangerous
A taken-over subdomain is more than a defacement:
- Phishing on your real domain. Users and filters trust
login.example.comfar more than a lookalike domain. - Valid HTTPS certificates. The attacker controls content on the hostname, so they can pass HTTP-based certificate validation and get a trusted certificate for it.
- Cookie theft. If your main site sets cookies scoped to
.example.com, a script on any subdomain can read or overwrite them, which can lead to session hijacking. - Bypassing security policies. Content Security Policy rules, CORS allowlists, and OAuth redirect URIs that trust
*.example.comwill trust the attacker too. - Reputation and SEO damage. Search engines may index spam or malware under your domain.
Wildcard records make this worse: a stale wildcard DNS record pointing at a platform can expose every possible subdomain at once.
How to Find Dangling DNS Records
Step 1: Export Every Record
You cannot audit what you cannot see. Export every zone from your DNS hosts. In AWS Route 53, this lists every CNAME and its target in a hosted zone:
aws route53 list-resource-record-sets \
--hosted-zone-id Z0123456789EXAMPLE \
--query "ResourceRecordSets[?Type=='CNAME'].[Name,ResourceRecords[0].Value]" \
--output text
The --query expression filters the record sets to CNAMEs and prints each name with its first target, one per line. Run it for every hosted zone, and use the equivalent export in other providers. For more on working with Route 53 from the CLI, see how to manage DNS records in AWS Route 53.
Step 2: Check Each Target Automatically
This Python script uses dnspython to check a list of hostnames. It follows each CNAME, then tries to resolve the final target, and flags anything whose target does not exist:
import dns.exception
import dns.resolver
HOSTNAMES = [
"promo.example.com",
"docs.example.com",
"assets.example.com",
"shop.example.com",
]
resolver = dns.resolver.Resolver()
resolver.lifetime = 5
def cname_target(name):
try:
answer = resolver.resolve(name, "CNAME")
return answer[0].target.to_text()
except (dns.resolver.NoAnswer, dns.resolver.NXDOMAIN):
return None
for host in HOSTNAMES:
target = cname_target(host)
if target is None:
print(f"{host}: no CNAME (check A/AAAA ownership separately)")
continue
try:
resolver.resolve(target, "A")
print(f"{host} -> {target}: resolves")
except dns.resolver.NXDOMAIN:
print(f"{host} -> {target}: DANGLING (target is NXDOMAIN)")
except dns.resolver.NoAnswer:
print(f"{host} -> {target}: no A record, check AAAA and the service")
except dns.exception.Timeout:
print(f"{host} -> {target}: timeout, recheck")
Install it with pip install dnspython and populate HOSTNAMES from the export in step 1. Anything marked DANGLING should be investigated and removed immediately. Targets that resolve can still be vulnerable on platforms where the hostname always resolves, so for CNAMEs into known third-party services, also load the subdomain in a browser or with curl -sI https://promo.example.com and look for platform "not found" pages.
Step 3: Reconcile A Records Against Your IP Inventory
For A and AAAA records, compare every address against the list of IPs your cloud accounts currently own. Most providers can list allocated public IPs from the CLI or console. Any address in DNS that is not in your inventory is a candidate dangling record.
Step 4: Check Delegations
For every NS record that delegates a subdomain, query the delegated servers directly and confirm they answer authoritatively for the zone:
dig SOA dev.example.com @ns-1234.dns-provider.example +norecurse
A REFUSED or SERVFAIL response, or no aa flag in the header, means the zone no longer exists there and the delegation is dangling.
How to Prevent Dangling Records
- Delete DNS first, resource second. When decommissioning, remove the DNS record before deleting the cloud resource. That order leaves no window where the name points at something claimable.
- Manage DNS as code. Define records alongside the resources they point to in Terraform, Pulumi, CloudFormation, or similar, so destroying the resource destroys its record in the same change.
- Use alias records where possible. Provider-native alias or ALIAS records that reference a resource by ID, rather than by hostname, often stop resolving automatically when the resource is deleted. See ALIAS and ANAME records.
- Use platform domain verification. Many platforms now require a TXT record to prove you own a custom domain before attaching it, for example Azure App Service's
asuidTXT record and GitHub Pages verified domains. Keep those verification records in place so nobody else can attach your hostnames. - Avoid broad wildcards into third-party services. A wildcard CNAME into a platform turns every unused subdomain into a potential takeover target.
- Scope cookies tightly. Set session cookies on the exact host that needs them rather than on the parent domain.
- Audit regularly. Run the checks above on a schedule and after every infrastructure change. Track who owns each subdomain.
For a broader look at how small DNS mistakes become large incidents, see the risks of misconfiguring DNS settings.
Dangling DNS Records FAQ
A broken record simply fails to work. A dangling record points to a resource that someone else could claim, which turns a broken link into a security vulnerability. Every dangling record is broken for you, but not every broken record is exploitable.
Any service that lets customers choose a resource name and route custom hostnames to it can be affected, including app hosting, static site hosting, object storage websites, CDNs, and many SaaS tools. Many providers have added ownership verification to reduce the risk, but older configurations may predate it.
Directly, it only affects the subdomain. Indirectly, it can expose cookies scoped to the parent domain, bypass policies that trust all subdomains, and damage the reputation of the whole domain.
Yes. They control the content served on the hostname, which is enough to pass HTTP-based domain validation. CAA records limit which certificate authorities can issue, but they do not stop issuance from an allowed authority.
It is usually harder to exploit because attackers cannot choose which IP address they are allocated. But it is still a real risk, and attackers do cycle through cloud IP allocations looking for addresses with DNS still pointing at them.
Run an automated check at least weekly and after any decommissioning work. Teams with frequent deployments often run it daily or in their CI pipeline.
No. DNSSEC guarantees that your records are authentic, and in this case your authentic record is exactly what sends traffic to the attacker. The fix is to remove the record.
Delete or correct the record immediately, then check whether the target was already claimed by someone else. If it was, review logs for any traffic, revoke any certificates issued for the hostname, and rotate session cookies that might have been exposed.
Conclusion
Dangling DNS records are a process problem dressed up as a technical one. The DNS is working exactly as configured; it just still points at something you gave up. Subdomain takeover turns that leftover record into a phishing site, a cookie stealer, or a foothold inside your security policies, all under your own domain name.
The fix is discipline: remove DNS before deleting resources, manage records alongside infrastructure in code, keep platform ownership verification in place, and audit your zones regularly with automated checks. Each subdomain should have a known owner and a known reason to exist. When you are setting up new ones, the guide on how to set up subdomains in DNS settings is a good place to start, and building the decommissioning step into that process from day one is what keeps them from dangling later.
Here are some useful references for going deeper on dangling records and subdomain takeover:
- Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover — Azure's guidance, including domain verification with asuid records.
- GitHub Docs: Verifying your custom domain for GitHub Pages — how to prevent others from claiming your domains on GitHub Pages.
- AWS Documentation: Amazon Route 53 Developer Guide — covers record management, alias records, and hosted zones.
- RFC 1034: Domain Names - Concepts and Facilities — defines CNAME and NS delegation behavior that dangling records rely on.
- dnspython Documentation: dnspython — the library used in the detection script.
