How to Detect Dangling DNS and Prevent Subdomain Takeovers in 2026

Attackers treat dangling DNS records like unlocked doors. A CNAME pointing to a decommissioned Azure resource, an A record referencing a deleted AWS S3 bucket, an MX record tied to a SaaS platform you stopped using six months ago: each one is a subdomain takeover waiting to happen. SentinelOne flagged more than 1,250 subdomain takeover risks tied to dangling DNS for its clients in 2024 alone. Silent Push reported that a single customer discovered over 2,000 exploitable DNS records requiring immediate remediation, according to Network World.

The real problem is scope. Enterprises operate hundreds of domains across subsidiaries, acquired brands, and cloud environments. You can’t remediate stale DNS records on domains you don’t know you own. This article covers how dangling DNS creates takeover risk, why traditional DNS auditing fails at enterprise scale, and how External Exposure Management platforms like IONIX close the gap with continuous EASM DNS monitoring.

How dangling DNS creates subdomain takeover risk

A dangling DNS record exists when a DNS entry (CNAME, A, AAAA, NS, or MX) points to a resource that no longer exists. The most common scenario involves CNAME records. Your team spins up a cloud service, creates app.yourcompany.com with a CNAME pointing to yourcompany.azurewebsites.net, then decommissions the Azure resource without deleting the DNS record.

The record still resolves. Traffic still routes. An attacker registers the matching resource on the cloud provider and takes control of your subdomain.

This creates three distinct risks:

• Phishing under your domain. The attacker hosts a credential-harvesting page on app.yourcompany.com. Because the URL matches your root domain, email filters and users trust it.
• Cookie theft. Browsers send cookies scoped to .yourcompany.com to the attacker-controlled subdomain. Session tokens, authentication cookies, and tracking data flow to a malicious endpoint.
• Supply chain compromise. Infoblox identified a threat actor called Hazy Hawk in February 2025 hijacking dangling DNS records at organizations including the CDC, Deloitte, PwC, and Ernst & Young. The attackers exploited abandoned cloud resources tied to government and Fortune 500 targets.

The vulnerability affects more than CNAME records. SentinelOne’s October 2024 investigation found researchers acquired approximately 150 deleted AWS S3 buckets and received over 8 million HTTP requests to those buckets, including requests for software updates and deployment artifacts. A dangling NS record is worse: the attacker controls DNS resolution for the entire subdomain zone.

Why enterprises miss dangling DNS records

Manual DNS auditing breaks down at enterprise scale for a structural reason: the audit scope is incomplete.

Security teams audit the domains they know about. A global enterprise with three acquisitions in the past two years, regional subsidiaries operating independent IT environments, and dozens of SaaS integrations across business units has a DNS footprint far larger than any central team tracks. IONIX’s discovery data shows that organizations are typically aware of only about 62% of their actual external exposure. The remaining gap includes forgotten domains, subsidiary infrastructure, and deprecated cloud resources with DNS records still pointing at them.

Three patterns create the majority of dangling DNS records in enterprise environments:

Cloud resource churn. Development teams provision and deprovision cloud resources on AWS, Azure, and GCP on a weekly or daily cadence. Each deprovisioned resource that leaves a DNS record behind creates a takeover vector. Azure App Services, AWS Elastic Beanstalk instances, S3-hosted static sites, and Azure CDN endpoints are frequent offenders.

SaaS migrations. support.yourcompany.com points to yourcompany.zendesk.com. You switch help desk providers but the CNAME stays. careers.yourcompany.com points to a job board you canceled. These records accumulate across business units without centralized tracking.

Acquisitions and subsidiary drift. An acquired company brings 40 domains into your portfolio. Nobody audits their DNS records during integration. Three of those domains have CNAMEs pointing to cloud resources the acquired company shut down before the deal closed. Those stale records are now your liability.

Point-in-time DNS audits catch the records that exist when you run the scan. They miss the record that becomes dangling on Tuesday because a developer deleted a staging environment on Monday. The gap between audits is the exposure window, and attackers exploit it.

How to detect dangling DNS across your entire domain portfolio

Effective dangling DNS detection requires solving two problems in sequence: scope and validation.

Step 1: Map every domain you own

Before auditing DNS records, you need a complete inventory of your domains. This includes primary corporate domains, subsidiary domains, acquired brand domains, regional TLD variations, and defensive registrations. Seed-list approaches fail here. If your asset inventory starts with the domains your IT team tracks, you miss the domains you don’t know about.

Organizational entity mapping solves this. IONIX builds a complete entity model from corporate records, M&A history, brand registrations, and subsidiary relationships before scanning a single port. The platform researches what your organization owns (including what you forgot you owned) and uses that entity map as the foundation for asset discovery.

Step 2: Enumerate all DNS records per domain

For every domain in your portfolio, query authoritative DNS servers to extract the full record set: A, AAAA, CNAME, MX, NS, TXT, and SRV records. Pay specific attention to CNAME records pointing to external providers (cloud platforms, SaaS services, CDN endpoints) and A records pointing to IP addresses you no longer control.

Step 3: Validate target resolution

For each DNS record pointing to an external resource, verify the target still exists and belongs to your organization. A CNAME pointing to yourcompany.azurewebsites.net that returns an NXDOMAIN or a default cloud provider page is dangling. An A record pointing to an IP address not in your allocated ranges is dangling.

Automated CNAME validation checks include:

• Does the target domain resolve?
• Does the resolved resource return your content or a default/error page?
• Is the cloud resource still provisioned in your account?
• For SaaS CNAMEs, is your account with the provider still active?

Step 4: Prioritize by exploitability

Not all dangling records carry equal risk. A dangling CNAME pointing to an Azure App Service is takeover-ready: anyone can register the matching hostname. A dangling A record pointing to a private IP in a cloud VPC is lower risk. Prioritize records pointing to cloud services where resource registration is open (Azure, AWS, GitHub Pages, Heroku) and services where the registration namespace is first-come-first-served.

IONIX validates exploitability from an attacker’s perspective: testing whether a dangling record can be taken over, not just whether the target fails to resolve. This distinction separates a DNS record security audit that produces a worry list from one that tells you which records an attacker can exploit today.

Step 5: Remediate and monitor continuously

Delete the dangling DNS record or repoint it to a valid resource. For records with SEO value, configure a 301 redirect to the correct destination. Then monitor continuously. A DNS audit run quarterly misses the three months of exposure between scans.

From point-in-time scans to continuous EASM DNS monitoring

The difference between a DNS audit tool and an External Exposure Management platform is continuity. A one-time scan tells you what was dangling on the day you ran it. Continuous monitoring catches new dangling records as they appear.

IONIX uses multi-factor discovery methods, including DNS analysis, certificate mapping, and metadata inspection, to map every internet-facing asset across your environment. Cloud instances, third-party platforms, shadow IT, and forgotten infrastructure that traditional tools miss all fall within the discovery scope.

Three capabilities separate IONIX’s approach from standalone DNS audit tools:

Organizational entity mapping before discovery. IONIX maps the full corporate structure, subsidiaries, acquisitions, and affiliated brands before scanning. A dangling DNS detection tool that starts from a known domain list will never find the stale CNAME on a subsidiary’s forgotten marketing domain. IONIX starts by building the complete organizational picture.

Exposure validation, not just detection. IONIX confirms whether a dangling DNS record is exploitable from the outside. The platform tests reachability and takeover feasibility the way an attacker would, providing evidence-backed findings rather than a list of records that fail to resolve. IONIX customers report a 97% drop in false-positive alerts because validated findings replace theoretical risk.

Continuous monitoring with Active Protection. IONIX is the only vendor that acquires dangling DNS records on behalf of customers before attackers can claim them. IONIX customers have reduced mean time to resolve external exposures by 90%, cutting exposure windows from weeks to hours.

Why dangling DNS prevention requires more than a DNS tool

DNS hygiene tools address one dimension of the problem: checking whether existing records resolve. They don’t solve the scope problem, the validation problem, or the continuity problem.

An EASM platform built on organizational entity mapping discovers the domains you didn’t know you owned. Exposure validation confirms which dangling records are exploitable. Continuous monitoring catches new dangling records as cloud resources change. The combination closes the full lifecycle: discovery, validation, and remediation.

EASM shows you what’s there. IONIX shows you what’s exploitable and what to fix first. Book a demo to see how IONIX maps your organizational entity structure and identifies exploitable dangling DNS records across your full external exposure.

FAQs