What is Dangling DNS Records? Ways to Exploit, Examples and Impact

In the complex web of modern cloud infrastructure, it is surprisingly easy for digital assets to fall through the cracks. A "Dangling DNS" record occurs when a DNS entry points to a resource that no longer exists, creating a security vacuum that attackers are eager to fill. This technical guide explores the mechanics of dangling DNS, the methods used to exploit them, and how organizations can protect their external attack surface.

Understanding Dangling DNS Records: A Technical Deep Dive

To understand a dangling DNS record, we must first look at how the Domain Name System (DNS) functions as the "phonebook" of the internet. Organizations use various types of DNS records to map human-readable domain names to technical resources.

A dangling DNS record is a stale entry in your DNS zone file that points to a decommissioned or deleted resource. This typically happens with cloud services, where resources like IP addresses, storage buckets, or web apps are ephemeral. When you delete the resource but forget to delete the DNS record pointing to it, the record is "dangling."

The Anatomy of a Dangling Record

Consider a scenario where a company, example.com, creates a subdomain for a marketing campaign: promo.example.com. They host this on an external cloud provider using a CNAME (Canonical Name) record.

; DNS Zone File for example.com
promo.example.com.  IN  CNAME  marketing-campaign-123.s3-website-us-east-1.amazonaws.com.

Once the campaign ends, the IT team deletes the S3 bucket marketing-campaign-123. However, they forget to remove the promo.example.com CNAME record from their DNS provider. The record still points to that specific AWS address. Because AWS allows any user to claim a bucket name that is not currently in use, an attacker can simply create a new bucket named marketing-campaign-123 in their own AWS account. Instantly, promo.example.com serves the attacker's content.

How Dangling DNS Records Occur

The primary driver of dangling DNS is the mismatch between the lifecycle of a DNS record and the lifecycle of the cloud resource it points to. Common scenarios include:

1. Cloud Migration: Moving services from one provider to another (e.g., AWS to Azure) often leaves behind old records.
2. Ephemeral Environments: Development or staging environments that are spun up and torn down frequently are prime candidates for stale records.
3. SaaS Discontinuation: Stopping a subscription to a service like Zendesk, Ghost, or GitHub Pages without cleaning up the associated custom domain CNAME.
4. Elastic IP Release: In environments like AWS EC2, an "A" record might point to an Elastic IP. If that IP is released back into the pool, another AWS customer will eventually be assigned that same IP.

Ways to Exploit Dangling DNS: Subdomain Takeover

The most common exploitation of a dangling DNS record is a Subdomain Takeover. This allows an attacker to gain full control over a subdomain of a legitimate organization, effectively inheriting the trust associated with that organization's primary domain.

1. Exploiting CNAME Records (SaaS and Cloud Services)

CNAME records are the most frequent targets. Attackers use automated tools to scan an organization's subdomains and check the status of the target resource. If they receive a 404 error or a specific "NoSuchBucket" message, they know the record is dangling.

Example: GitHub Pages Takeover

If docs.example.com points to example-org.github.io via CNAME, and the organization deletes the example-org repository or changes their GitHub username, the CNAME becomes dangling.

An attacker can:

1. Create a new GitHub account or repository.
2. Configure the repository to use docs.example.com as a custom domain.
3. GitHub's system will verify that the CNAME points to GitHub and allow the takeover.

2. Exploiting A and AAAA Records (IP Reuse)

This is more common with cloud providers that utilize shared IP pools. If api.example.com points to the IP 52.20.10.15 (an AWS Elastic IP) and the organization releases that IP, an attacker can programmatically request new IPs from AWS until they are assigned 52.20.10.15.

# Attacker checks the IP of the target
dig api.example.com +short
# Output: 52.20.10.15

# Attacker runs a script to cycle through AWS Elastic IPs until a match is found

3. Exploiting NS (Name Server) Records

This is a more severe form of dangling DNS. If a subdomain is delegated to a set of external name servers (e.g., via a SaaS provider's managed DNS) and that service is cancelled, the NS records in the parent zone still point to those name servers. If the provider allows users to claim "zones" by name, an attacker can recreate the zone on that provider and gain control over all records for that subdomain.

Technical Examples of Subdomain Takeovers

Scenario: AWS S3 Bucket Takeover

Imagine you find a subdomain assets.victim-corp.com that points to an S3 bucket. You use curl to check the status:

curl -I http://assets.victim-corp.com

Response:

HTTP/1.1 404 Not Found
x-amz-error-code: NoSuchBucket
x-amz-error-message: The specified bucket does not exist
Server: AmazonS3

The NoSuchBucket error is a green light for an attacker. They can log into their own AWS console and create a bucket with the exact name referenced in the CNAME record. Once created, any file uploaded to that bucket will be served under assets.victim-corp.com.

Scenario: Azure App Service Takeover

Azure subdomains often follow the pattern [app-name].azurewebsites.net. If an organization deletes their Azure Web App but keeps the CNAME app.example.com pointing to it, the takeover is straightforward.

When visiting the dangling domain, the attacker sees the default Azure "404 Web Site not found" page. By creating a new Azure Web App with the same name, the attacker intercepts all traffic intended for the original application.

The Impact of Dangling DNS Exploitation

The impact of a successful subdomain takeover can range from minor brand embarrassment to catastrophic data breaches.

Phishing and Social Engineering

Because the attacker is hosting content on a legitimate subdomain (e.g., login.company.com), users are highly likely to trust the site. Attackers can host pixel-perfect clones of login pages to harvest credentials. Since the domain is legitimate, the site will have a valid SSL/TLS certificate (often easily obtained via Let's Encrypt), and it will bypass most email security filters that check for domain reputation.

Cookie Stealing and Session Hijacking

Many web applications set cookies at the parent domain level (e.g., .example.com). These cookies are automatically sent to all subdomains. An attacker controlling malicious.example.com can read sensitive session cookies belonging to users who have logged into app.example.com. This allows the attacker to hijack active user sessions without ever knowing the user's password.

Bypassing Content Security Policy (CSP)

CSP is a security layer used to prevent Cross-Site Scripting (XSS). Many organizations whitelist their own subdomains in their CSP (e.g., script-src 'self' *.example.com). If an attacker takes over a subdomain, they can host malicious scripts there, and the victim's browser will execute them because they originate from a "trusted" source.

Bypassing OAuth Whitelists

OAuth implementations often use a whitelist of allowed redirect URIs. If an attacker takes over a subdomain that is on the whitelist (e.g., dev-callback.example.com), they can redirect OAuth tokens to their server, effectively compromising user accounts on the platform.

How to Detect and Identify Dangling DNS Records

Securing your infrastructure requires constant vigilance. Here are methods to identify these risks:

Manual Discovery with CLI Tools

You can use the dig command to inspect records. Look for CNAMEs pointing to cloud providers and then verify if the destination is active.

dig CNAME dev.example.com

If the result points to a service like unclaimed-app.herokuapp.com, try visiting that URL. If you see a "No such app" page, the record is dangling.

Automated Scanning

For organizations with hundreds or thousands of subdomains, manual checking is impossible. Security teams use specialized tools to automate the process. These tools perform three main tasks:

1. Subdomain Enumeration: Finding all possible subdomains via passive and active DNS discovery.
2. Fingerprinting: Identifying which cloud service each subdomain points to.
3. Verification: Checking the HTTP response or DNS status to see if the resource is claimable.

Best Practices for Prevention

Preventing dangling DNS is primarily a matter of process and visibility.

1. Strict Decommissioning Workflows: Ensure that every ticket for deleting a cloud resource (S3 bucket, Azure App, etc.) includes a mandatory step to remove associated DNS records.
2. DNS Inventory Management: Maintain a clear mapping of which DNS records point to which internal or external resources.
3. Use Alias Records: Where possible (such as in AWS Route 53), use "Alias" records instead of CNAMEs. Alias records are often more tightly integrated with the cloud provider's internal state.
4. Continuous Monitoring: Use automated platforms to monitor your external attack surface. Since cloud environments change daily, a monthly audit is not enough.

Conclusion

Dangling DNS records represent a significant but preventable risk in the modern threat landscape. By understanding the lifecycle of DNS entries and the technical nuances of cloud resource allocation, security professionals can close these gaps before they are exploited. Regular auditing and automated discovery are the best defenses against subdomain takeovers.

To proactively monitor your organization's external attack surface and catch dangling DNS exposures before attackers do, try Jsmon.