The most dangerous risks are often the ones that manage to go unnoticed. Dangling DNS — stale DNS entries that continue pointing to defunct resources — are some of the quietest, and most dangerous: easily overlooked, easily exploited.
These misconfigurations are common, which makes them a frequent target for attackers, who actively search for them because they create opportunities for subdomain takeover. Once exploited, attackers can host malicious content under a trusted domain, enabling phishing, malware delivery, and reputational damage.
This blog will cover what dangling DNS is, how it can lead to subdomain takeover, and how organizations can detect and defend against these risks with Censys.
What Is Dangling DNS?
A dangling DNS entry is a DNS record that points to a resource that no longer exists or is no longer controlled by the organization. The DNS record itself remains active, even though the underlying service has been deleted, decommissioned, or abandoned.
This often happens when organizations use third-party services like AWS S3, GitHub Pages, or Heroku. If the service is decommissioned or the account associated with the service is deleted but the DNS entry is not removed, the DNS record still points to the now-defunct, or “dangling” resource.
Dangling DNS can exist on any domain or subdomain in the attack surface. It is particularly common in large organizations where infrastructure changes frequently, ownership changes between teams, or cloud resources are rapidly provisioned and decommissioned.
Why Is Dangling DNS a Problem?
Dangling DNS entries create blind spots in an organization’s attack surface. Because the DNS record remains publicly visible and resolvable, attackers can identify these abandoned references and attempt to claim the associated resource. From an attacker’s perspective, dangling DNS records are a strategic opportunity to gain control over a trusted subdomain without compromising the organization directly.
Why Dangling DNS Is Hard to Catch Manually
In large organizations, DNS records accumulate over years across multiple teams, cloud accounts, and infrastructure providers. When a resource is decommissioned, removing the DNS entry is rarely part of the standard offboarding checklist. Ownership gaps between teams and legacy resources make the problem worse — nobody is sure who is responsible for a record created three years ago by someone who has since left.
Attackers, by contrast, can automate subdomain enumeration and CNAME validation at scale. The asymmetry is significant: finding these records automatically is dramatically faster than doing so manually.
How Dangling DNS Leads to Subdomain Takeover
Subdomain takeover occurs when an attacker successfully claims the resource referenced by a dangling DNS record and gains control over the affected subdomain.
Attackers find dangling DNS instances by scanning and identifying subdomains associated with a website, then checking whether these subdomains point to any resources that no longer exist (a dangling DNS entry). Attackers frequently automate the discovery of these vulnerabilities using tools that scan for:
- Dangling CNAME records
- Unclaimed cloud resources
- Expired third-party service configurations
- Misconfigured NS records
The process typically works like this:
- A DNS Record Points to a Decommissioned Resource.
- Attackers Discover the Dangling Entry.
- The Attacker Claims the Resource.
- The Attacker Gains Control of the Subdomain.
Once the dangling resource is claimed, the attacker can host arbitrary content under the legitimate domain. This may include:
- Phishing pages
- Malware delivery
- Fake login portals
- Malicious redirects
- Defacement content
- Credential harvesting infrastructure
Since the subdomain belongs to a trusted domain, users and security tools may be less likely to immediately identify the activity as malicious.
Which Services Are Most Commonly Exploited?
Subdomain takeover is most common on platforms that allow users to claim named resources. Services frequently involved include AWS S3, GitHub Pages, Heroku, Fastly, Azure, Shopify, and Zendesk. Any platform where a CNAME points to a user-claimable namespace is a potential vector.
What Are the Consequences of Subdomain Takeover?
Subdomain takeover can have serious operational and security consequences.
- Brand and Reputation Damage: Attackers can host malicious or inappropriate content on a company-owned subdomain and be associated with an attack, damaging trust with customers and partners.
- Phishing Attacks: A phishing page hosted on a legitimate company subdomain appears significantly more trustworthy than a completely unrelated domain. This increases the likelihood of credential theft and social engineering success.
- Malware Distribution: Attackers can distribute malware or malicious downloads from the compromised subdomain, leveraging the organization’s reputation to bypass suspicion.
- Session Hijacking and Cookie Abuse: In some cases, compromised subdomains can be leveraged to abuse cookies scoped to the parent domain or interfere with web application trust assumptions.
- Security Monitoring Gaps: Because the activity occurs on a legitimate company subdomain, monitoring tools may not immediately recognize the infrastructure as compromised.
- Data Breaches: If sensitive data is shared through the compromised subdomain, it could lead to data breaches.
Frequently Asked Questions About Dangling DNS
- What is the difference between dangling DNS and a misconfigured DNS record? A misconfigured DNS record has incorrect values (wrong IP, wrong CNAME target). A dangling DNS record was correct when created but now points to a resource that no longer exists or is no longer owned by the organization. Both are risks, but dangling DNS is specifically exploitable via subdomain takeover.
- Can subdomain takeover happen on subdomains I don’t actively use? Yes — inactive or forgotten subdomains are the most common targets. If a DNS record exists, attackers will find it regardless of whether the subdomain appears in your navigation or marketing materials.
- How do attackers find dangling DNS records? Attackers use automated tools to enumerate subdomains (via certificate transparency logs, DNS brute-forcing, and public records), then check each subdomain’s CNAME target to see if the referenced resource is unclaimed on the relevant platform.
- Does HTTPS or a valid TLS certificate protect against subdomain takeover? No. An attacker who claims the resource can also provision a valid TLS certificate for it through the platform’s automated provisioning — meaning the subdomain will show a padlock in the browser even while under attacker control.
- How often should I audit DNS records for dangling entries? Ideally, DNS should be audited continuously, since new dangling entries can appear any time a cloud resource is decommissioned. At minimum, include a DNS review in any cloud resource offboarding checklist and run a full audit quarterly.
How Censys Helps Detect Dangling DNS Risks
Censys helps organizations identify and remediate dangling DNS risks before attackers can exploit them.
Censys continuously analyzes Internet-facing infrastructure using its Map of the Internet: the most complete, accurate, and up-to-date Internet intelligence dataset available. Now, Censys’ Internet intelligence dataset includes DNS records, which are refreshed daily. This enables organizations to detect stale or vulnerable DNS configurations with current, continuously updated visibility.
In Censys ASM, dangling DNS risks can be identified on domain and web entity assets. Censys checks all names within a given workspace to detect dangling DNS risks across CNAMEs, NS Records, and third party services. It surfaces those risks within existing ASM workflows, and includes context that helps analysts quickly decide how to best address the risk. Each detection shows:
- Associated domain name
- Impacted DNS record
- Evidence for the detection
This context helps security teams react to alerts quickly so they can remediate risks before attackers can exploit them.
Learn more about dangling DNS detection in ASM →
Prevent Subdomain Takeover with Censys ASM
Dangling DNS entries are easy for analysts to overlook — and, unfortunately, easy for attackers to find. They can create a direct path to subdomain takeover and expose organizations to phishing, malware distribution, and reputational harm.
Dangling DNS in Censys ASM mitigates this risk by surfacing dangling DNS threats quickly so analysts can respond to them before they’re exploited. Informed by Censys’ comprehensive, accurate, and up-to-date Map of the Internet, Censys dangling DNS alerts are fresh, reliable, and contextualized with the information analysts need to act quickly and confidently.
Dangling DNS risks are now available in your Censys ASM workspace and will be enabled in mid-June. Reach out to your customer success team for more information. If you don’t have Censys ASM, request a demo to learn how it can help protect your organization.
