6 Steps to Eliminate Dangling DNS Records and Takeover Risk

A dangling DNS record is a CNAME or delegation entry that keeps pointing at a resource you already deleted, and it is the misconfiguration that makes subdomain takeover possible: once the record is orphaned, anyone can claim the deleted resource’s name and start serving content on your subdomain. The fix is procedural rather than exotic — inventory your DNS zones, verify every target is a resource you own, remove or repoint the orphans, prove domain ownership where the platform supports it, put DNS removal first in your decommissioning runbook, and automate the check so nothing slips through. This guide walks through each step with the platform controls that make it stick.

Why CNAME Records Go Dangling

The failure mode is a lifecycle gap, not a weakness in DNS itself. Microsoft documents the canonical sequence: a team provisions a resource with a hostname, creates a CNAME in the corporate zone pointing a friendly subdomain at it, and later deletes the resource without touching DNS. The subdomain is still advertised as active, but it now routes to a name nobody controls. Microsoft describes this as a common, high-severity threat specifically for organizations that regularly create and delete many resources.

The threat is active, not theoretical. AWS CIRT has observed threat actors actively scanning public DNS for CNAME records that point to resources that no longer exist, looking for takeover opportunities, and MITRE ATT&CK tracks the technique under Compromise Infrastructure. The blast radius goes beyond a defaced page: Microsoft warns that attackers can obtain a valid TLS certificate for the hijacked name, harvest session cookies scoped to wildcard parent domains, run phishing on a trusted hostname, and in some cases intercept mail through dangling MX records.

Six Steps to Eliminate Dangling Records

1. Inventory every record. Export all CNAME, NS and MX records from every zone you control — Route 53 hosted zones, Azure DNS zones and any external registrar. Include delegations: NS records for child zones are as claimable as CNAMEs when the child zone disappears.
2. Cross-reference targets against owned resources. For each record, resolve the target hostname pattern (S3 website endpoints, *.cloudfront.net, *.elasticbeanstalk.com, *.azurewebsites.net, *.azurefd.net) and confirm the backing resource exists in an account or subscription you own. A DNS query alone is not proof of ownership.
3. Delete or repoint orphans. Remove records whose targets no longer exist, or repoint them at live resources you control. Do this before anything else — an orphan left overnight is exposure.
4. Add ownership verification. Where the platform offers verification tokens, deploy them: Azure App Service’s asuid.{subdomain} TXT record blocks another subscription from validating your custom domain, and domain-verification features on shared hosting services prevent third parties from claiming your hostname.
5. Fix the decommissioning procedure. Add ‘remove DNS entry’ as a required check when a service is retired, and put a delete lock on any resource that carries a custom DNS entry so the mapping is visible before deprovisioning. Pair the runbook with your reviews of break-glass access controls so decommissioned credentials and hostnames leave the estate together.
6. Automate detection. Schedule a recurring sweep — an AWS Config custom rule over Route 53, Microsoft’s Get-DanglingDnsRecords tool over Azure, or a scripted export — and route findings to your security queue, the same way you treat stale third-party OAuth grants.

Detecting Dangling Records Continuously

The naive detector — resolve the CNAME and check for an error — has a critical flaw the AWS Security Blog calls out explicitly: if an attacker has already claimed the resource, resolution succeeds against their infrastructure and you get no warning. Detection must compare DNS targets against your resource inventory, not against DNS behavior. An AWS Config custom rule that parses Route 53 CNAME targets and verifies each S3, CloudFront or Elastic Beanstalk resource exists in your account identifies dangling records correctly even after a takeover has occurred; route NON_COMPLIANT findings to Security Hub or SNS. On Azure, the Microsoft Defender for App Service plan raises an alert when an App Service site is decommissioned but its custom domain remains in DNS, regardless of whether the domain is managed in Azure DNS or an external registrar.

Platform Controls That Prevent Takeover

Verification and lifecycle coupling beat after-the-fact cleanup. Azure DNS alias records prevent dangling references by coupling the lifecycle of the DNS record with the underlying resource, and deleting the underlying resource turns the alias record into an empty record set that no longer references it — coverage limited to Azure Front Door, Traffic Manager profiles, CDN endpoints and public IPs. On the delegation side, Route 53 prevents those name servers from being reassigned when a deleted hosted zone still has delegation records in the parent domain, though only for that specific scenario; other dangling-delegation cases still require keeping parent NS records aligned with the hosted zone’s delegation set. For object storage, S3 buckets created with account regional namespaces, launched in March 2026, are scoped to your account and are not subject to this takeover — but the global namespace remains the default, existing buckets cannot be migrated to it, and CloudFront and Elastic Beanstalk have no equivalent scoping.

What to Do After Detection

When a sweep flags a record, work a short playbook drawn from Microsoft’s remediation guidance: remove every CNAME pointing at a deprovisioned FQDN, provision a replacement resource under your control if traffic must keep flowing, review application code for hardcoded references to the subdomain, and investigate whether any compromise occurred before you found it — OAuth credentials or privacy-sensitive data sent to a dangling name may have been exposed to a third party. Finish by answering why the record survived the decommissioning, or the same process gap will produce the next dangling entry.

Sources

• Microsoft Learn — Prevent dangling DNS entries and avoid subdomain takeover
• AWS Security Blog — Threat tactic spotlight: Subdomain takeover
• AWS Route 53 Developer Guide — Protection from dangling delegation records