Dangling DNS: How Forgotten Subdomains Become Security Incidents

Dangling DNS — sometimes called a dangling CNAME or dangling delegation — describes a DNS record that points to a resource that no longer exists. The DNS entry is live and resolving, but the target on the other end has been deleted, expired, or reassigned. The gap between "DNS record exists" and "resource still exists" is where subdomain takeover lives.

It is a deceptively simple vulnerability. The organisation did everything right when they set up the service — correct DNS records, valid certificate, proper deployment. The mistake happened during teardown, when the cloud resource was deleted but the DNS record was left behind as an afterthought. Nobody noticed because the subdomain was not on anyone's monitoring list. It was just an old subdomain that had served its purpose.

Until an attacker claimed it.

How subdomain takeover works

The mechanics depend on the underlying service, but the general pattern is consistent across dozens of platforms:

1. An organisation creates a cloud resource — an Azure Static Web App, an AWS S3 bucket, a GitHub Pages site, a Heroku app, a Fastly CDN endpoint — and points a subdomain at it via a CNAME record.
2. The resource is deleted when the project ends, the service is migrated, or the hosting contract expires. The cloud provider frees up the resource name.
3. The CNAME record is not removed. It still points to the old resource name — something like myapp.azurestaticapps.net or old-bucket.s3-website.eu-west-1.amazonaws.com.
4. An attacker registers the same resource name on the same platform. On many cloud services, resource names are allocated on a first-come-first-served basis. There is nothing preventing a third party from creating a new resource with the same name your organisation previously used.
5. The attacker now controls what is served under your subdomain. Visitors to staging.yourdomain.com are now seeing content controlled by a third party — but the address bar shows your domain. No certificate warning. No obvious sign that anything is wrong.

From a user's perspective, this is indistinguishable from a legitimate service on your domain. The subdomain resolves. The page loads. If the attacker sets up HTTPS — which they can do freely with Let's Encrypt — there is even a padlock.

Why this is worse than it sounds

Subdomain takeover is not just a reputation problem. Depending on what the attacker does with the taken-over subdomain, the consequences can be significantly more serious:

Cookie theft. Cookies scoped to .yourdomain.com are sent by the browser to all subdomains, including the taken-over one. An attacker serving content under your subdomain can receive session cookies from users who visit the page — potentially including authenticated sessions from your main application if cookie scoping is not properly restricted.

Credential phishing. A taken-over subdomain is ideal for phishing. The address bar shows your domain. Users have no obvious reason to be suspicious. A login form styled to match your main application is highly convincing in this context.

Content injection and brand damage. An attacker can serve anything under your subdomain — defacement, malware, spam, adult content. All of it attributed to your organisation in every access log, browser history, and web archive that records the visit.

Bypassing Content Security Policy. If your main application has a Content Security Policy that allowlists your own subdomains, a taken-over subdomain may be allowed to load scripts or frames into your application — bypassing CSP protections that were working correctly before the takeover.

OAuth and SSO abuse. Some identity providers allow redirect URIs scoped to a domain — meaning any subdomain is a valid redirect target. A taken-over subdomain can be used as a redirect destination in OAuth flows, potentially capturing access tokens.

Which services are most commonly affected

Subdomain takeover is possible on any platform that allocates resource names in a shared namespace where names can be reclaimed after deletion. The most commonly seen in the wild include:

• Microsoft Azure — App Services, Static Web Apps, Traffic Manager, Front Door
• Amazon Web Services — S3 static website hosting, Elastic Beanstalk, CloudFront
• GitHub Pages — custom domain configurations where the repository has been deleted or renamed
• Heroku — custom domain configurations on deleted apps
• Fastly, Netlify, Vercel — CDN and hosting platforms with shared subdomain namespaces
• Shopify, WordPress.com, Tumblr — hosted platforms with custom domain support

The can-i-take-over-xyz project maintains a community-updated list of services and whether they are known to be vulnerable to subdomain takeover after resource deletion. Many major platforms are on the list.

How dangling DNS connects to certificate monitoring

Certificate Transparency logs provide a surprisingly effective signal for detecting dangling DNS. Here is why:

When a service is active, it typically has a TLS certificate. When the service is deleted, the certificate may still be in the CT logs — showing a subdomain that had a certificate at some point. If you query CT logs for your domain and then resolve each discovered subdomain, you can cross-reference two things:

• Does the subdomain still resolve in DNS? If not — clean up the DNS record.
• If it resolves, does it resolve to your infrastructure, or to a third-party service? A CNAME pointing to an external platform is a candidate for takeover investigation.
• If it resolves to a CNAME target, does that target exist? A CNAME that resolves but points to a non-existent resource on the target platform is a confirmed dangling entry.

This is exactly the kind of analysis that external attack surface scanning automates. The combination of CT log enumeration (finding all subdomains that have ever had certificates) and active DNS resolution (checking current state) gives you the complete picture.

Detecting and remediating dangling DNS

Finding your dangling DNS exposure requires working through the following sequence for your domains:

Step 1 — Build a complete subdomain list. Use CT logs to enumerate every subdomain that has ever had a certificate under your domain. Supplement with DNS brute-force enumeration to catch subdomains that may not have had certificates. The CT log list is the more reliable starting point.

Step 2 — Resolve all subdomains. For each subdomain, check current DNS resolution. Look specifically for CNAME records — these are the dangerous ones, because they delegate resolution to a third-party namespace where resource names can be reclaimed.

Step 3 — Check CNAME targets. For each CNAME, check whether the target resource still exists. A CNAME pointing to something.azurewebsites.net can be checked by attempting to access that resource directly. A 404, a "no such site" error from the platform, or a redirect to a platform's own error page indicates the resource has been deleted while the CNAME remains.

Step 4 — Remediate immediately. Any confirmed dangling CNAME should be removed from DNS immediately. There is no reason to leave it in place — if the resource it pointed to has been deleted, the DNS record serves no purpose and creates unacceptable risk.

Step 5 — Establish a process for future decommissioning. The root cause of dangling DNS is a decommissioning process that does not include DNS cleanup. The fix is procedural: every time a cloud resource with a custom DNS record is deleted, the DNS record must be removed as part of the same ticket, change, or deployment. DNS cleanup should be a required step, not an afterthought.

Prevention is simpler than detection

The most effective defence against dangling DNS is never creating it in the first place — which requires that DNS record cleanup is treated as mandatory during decommissioning, not optional cleanup to be done "sometime later."

A few practices that help:

• Infrastructure-as-Code. When DNS records are managed alongside the resources they point to in the same IaC configuration (Terraform, Pulumi, CloudFormation), deleting the resource automatically deletes the DNS record. This eliminates the manual step where records get forgotten.
• DNS record TTL discipline. Short TTLs on records pointing to cloud resources make cleanup faster and reduce the window during which a dangling entry is resolvable after the resource is deleted.
• Audit DNS regularly against live resources. A periodic review of all CNAME records, checking that each target still exists, catches entries that slipped through the decommissioning process.
• Use NS delegation carefully. Delegating an entire subdomain zone (via NS records) to an external party creates a large potential dangling surface. If the delegation is abandoned, the entire subdomain namespace becomes vulnerable.

How CertControl surfaces dangling DNS

CertControl's external attack surface scanner combines CT log enumeration with active DNS resolution and CNAME chain analysis to surface potential dangling entries as part of its regular discovery process. When the scanner finds a subdomain resolving via CNAME to an external platform, it checks whether the target resource appears to exist — and flags entries where the CNAME chain leads to a platform response that suggests the resource has been deleted.

These findings appear in the discovery dashboard alongside other external surface findings, prioritised by risk. A confirmed dangling CNAME to a platform known to be vulnerable to takeover is a high-severity finding that warrants immediate DNS cleanup.

Because the scanner runs continuously and CT monitoring surfaces new subdomains in real time, dangling entries created by recent decommissioning activity surface quickly — while the window for remediation is still open and before any attacker has had time to claim the orphaned resource.