Dangling CNAME: How to Detect and Prevent Subdomain Takeover

What Is a Dangling CNAME?

A CNAME record (Canonical Name) is a DNS alias: it redirects requests for a subdomain like shop.company.com to another target, for example company.cdn-provider.net. As long as the target exists and is reachable, everything works as expected. However, if the target service is cancelled, the cloud hosting removed, or the SaaS platform changed without deleting the corresponding CNAME entry, a dangling CNAME is created: the DNS record points to nothing.

The problem is that the CNAME entry remains active and continues forwarding requests to the non-existent target. Depending on the cloud provider, an attacker can register exactly that target and thereby gain control over the subdomain. The DNS system then works as designed, just for the attacker instead of for you.

What makes dangling CNAMEs particularly insidious is that they are not immediately visible from the outside. The subdomain continues to exist in your DNS but points to a server you no longer control. Visitors who access the subdomain directly see either an error message or, in the worst case, a phishing page placed by an attacker. Without systematic DNS monitoring, such orphaned entries can remain undetected for months.

How Does a Subdomain Takeover Happen?

A subdomain takeover typically follows a predictable sequence:

1. Set up service: A company sets up a cloud service and creates a CNAME record pointing the subdomain staging.company.com to company.cloud-service.io.
2. Cancel service: Months or years later, the cloud service is no longer needed. The account is closed or the resource deleted.
3. Forget CNAME: The corresponding CNAME entry is not removed from DNS. The subdomain now points to a target that no longer exists (NXDOMAIN).
4. Attacker registers target: An attacker identifies the orphaned CNAME, registers the hostname company.cloud-service.io with the same cloud provider, and gains control over staging.company.com.
5. Abuse: The subdomain now serves as a phishing page, distributes malware, or steals session cookies from the main domain.

Which Cloud Services Are Particularly Vulnerable?

Not every cloud service enables a subdomain takeover. The decisive factor is whether an attacker can re-register the same hostname after the original account is deleted. Services with high risk are those that allow custom hostnames and do not perform domain ownership verification when a new user claims the same hostname.

Particularly affected are content delivery networks, cloud hosting platforms, landing page builders, and SaaS services with custom domain functionality. But internal services can also be affected: a decommissioned staging server whose CNAME still exists, or an old campaign landing page whose hosting has expired. The problem intensifies in organisations with many departments: marketing creates landing pages, IT sets up staging environments, and sales uses external tools with custom domains. Without centralised DNS management, abandoned subdomains are quickly forgotten.

What Risks Does a Subdomain Takeover Pose?

The consequences of a successful subdomain takeover extend far beyond a single subdomain:

• Phishing with trust advantage: The taken-over subdomain belongs to your legitimate domain. Phishing emails from staging.company.com appear credible and pass many spam filters.
• Session cookie theft: If your main domain sets cookies on *.company.com (without subdomain restriction), an attacker can read these cookies via the taken-over subdomain. This may include session tokens and authentication data.
• SEO manipulation: Attackers can place spam content or backlinks on the taken-over subdomain. Since the subdomain belongs to the main domain, this can negatively impact your search engine rankings.
• SSL certificate abuse: In some cases, attackers can obtain valid SSL certificates for the taken-over subdomain, making the attack even harder to detect. SSL monitoring can identify such unexpected certificate issuances.
• Compliance violations: If personal data is collected via a taken-over subdomain, GDPR fines and notification obligations under Art. 33 GDPR may apply.

Real-World Subdomain Takeover Incidents

Subdomain takeover is not a theoretical scenario. Vulnerable subdomains are regularly reported at well-known companies through bug bounty programs. Security researchers such as Patrik Hudak have documented that even large technology companies and financial institutions had vulnerable subdomains exploitable through orphaned CNAME records (Patrik Hudak, 0xpatrik.com). OWASP lists subdomain takeover in their security recommendations as a known vulnerability (OWASP).

Particularly critical are cases where subdomains were used for internal applications or customer portals. An attacker who takes over such a subdomain can create a convincing login page and intercept credentials. Since the URL belongs to the real domain, users typically do not suspect anything. Email-based attacks also become more credible: a phishing email that appears to come from a subdomain of your company has a significantly higher success rate than one from an unknown domain.

Detecting Dangling CNAMEs: Manual and Automated Methods

Manual Verification

A manual check begins with inventorying all DNS records. For each CNAME entry, you verify whether the target is still resolvable and whether the associated service is still active. With just a few subdomains, this is feasible, but it quickly becomes impractical with dozens or hundreds of subdomains. Moreover, a one-time check does not discover new dangling CNAMEs created by subsequent service cancellations. In practice, manual DNS audits typically only capture the current state and do not provide continuous protection.

Automated DNS Monitoring

Automated DNS monitoring solves both problems: it continuously checks all CNAME records and their targets. When a CNAME target responds with NXDOMAIN or returns a known error pattern from a cloud provider, an alert is triggered immediately. XICTRAQ also detects changes to existing CNAME records that may indicate a manual or unauthorised intervention, and logs all changes in a change history.

Preventing Subdomain Takeover: Protective Measures

DNS Monitoring as a Core Component of Security Strategy

Dangling CNAMEs are just one aspect of a comprehensive DNS security strategy. XICTRAQ connects DNS monitoring with uptime monitoring, security scans, SSL monitoring, and GDPR compliance checks in one integrated platform. When a subdomain suddenly responds from a different server, XICTRAQ recognises the correlation between DNS change, altered SSL certificate, and new hosting location.

Combined with DNS hijacking protection and domain expiry monitoring, XICTRAQ provides a comprehensive shield for your DNS infrastructure. All DNS record types are monitored: A, AAAA, CNAME, MX, NS, TXT, SPF, DMARC, and CAA. Changes are logged, and any deviation from the expected state immediately triggers an alert via your preferred notification channel.

Checklist: Minimising Subdomain Takeover Risk

• Create DNS inventory: Document all subdomains and their CNAME targets, including the associated cloud service and internal responsible person
• Define offboarding process: Removing DNS records must be part of the deactivation process for every service cancellation
• Enable automated DNS monitoring: XICTRAQ checks CNAME targets continuously and alerts on NXDOMAIN or provider error messages
• Review cookie scoping: Ensure cookies are not unnecessarily set on *.domain.com
• Configure CAA records: Only authorised certificate authorities should be able to issue certificates for your domain
• Conduct regular audits: At least quarterly, reconcile all DNS records with actually used services

Start DNS monitoring now and close the gap that orphaned CNAME records leave in your security architecture. Registration takes just minutes, and you can immediately monitor all subdomains of your domain. If you would like to test the features first, request a free demo or review the pricing.