How to Clean Up Dangling CNAME Records After Decommissioning Cloud Services
Dangling CNAME records occur when a DNS Canonical Name record points to an external cloud service, CDN, or SaaS provider that has been deleted or unclaimed. Because the underlying cloud resource no longer exists under your account, an attacker can provision that exact resource name on the provider's platform and successfully hijack your subdomain, leading to severe security risks like phishing and data theft. Cleaning up these orphaned pointers is an essential part of domain hygiene and cloud infrastructure decommissioning.
To proactively discover whether any of your domain pointers are orphaned, you can use the DNS Lookup tool to inspect your current zone configurations, query authoritative nameservers, and verify active resource mappings.
Understanding the Subdomain Takeover Vulnerability
When you initially map a domain like app.example.com to an external service provider using a CNAME record, you are instructing recursive resolvers to trust the target domain provided by that service, such as example.azurewebsites.net or example.cloudfront.net.
app.example.com. 300 IN CNAME example.cloudfront.net.
If you later delete the underlying distribution or storage bucket on the cloud platform without first deleting the CNAME record in your DNS zone, the target domain becomes unassigned. If an external actor notices that example.cloudfront.net (or the equivalent provider endpoint) is available for creation, they can claim it. Once claimed, any traffic destined for app.example.com will resolve directly to the attacker's newly provisioned service, while valid SSL certificates (if managed externally) or cookie scopes may allow them to intercept sensitive user sessions.
Step 1: Inventory Your Active DNS Records
Before you can clean up dangling CNAME records, you need a complete export of your current DNS zone files. Log in to your DNS hosting provider or registrar, keeping in mind that menu paths such as Network Settings, DNS Manager, or Zone Editor may differ slightly depending on your specific vendor.
Export your zone file or query your nameservers directly using command-line utilities. To pull all records for your domain, run a query using dig or nslookup:
dig example.com ANY +noall +answer
Filter the output specifically for CNAME records to review every external dependency your domain currently relies upon:
dig example.com CNAME +short
Review the list and cross-reference every target against your active cloud infrastructure inventory. If a target points to a service, bucket, or application you no longer manage or recognize, flag it for immediate investigation.
Step 2: Validate Target Availability
Once you have a list of external CNAME targets, you must determine whether the target resource is still active, owned by you, or completely abandoned and vulnerable. You can perform basic HTTP and DNS checks against the target endpoints.
Use curl to inspect the HTTP response headers of the CNAME target:
curl -I https://example.cloudfront.net/
If the target returns a standard cloud provider error page indicating that the resource does not exist (such as an AWS NoSuchBucket error or an Azure App Service 404 Not Found), the record is likely dangling.
| Target Cloud Service | Common Dangling Error Indicator | Vulnerability Status |
|---|---|---|
| AWS CloudFront | Bad Request: ERROR: The request could not be satisfied |
High |
| Azure App Service | 404 Web Site not found |
Critical |
| GitHub Pages | There isn't a GitHub Pages site here. |
High |
| Heroku | No such app |
Critical |
Step 3: Remove or Update the Orphaned Records
After identifying a dangling CNAME record, you have two choices: remove the record entirely if the service is permanently decommissioned, or update it to point to your current active infrastructure.
Removing the Record via DNS Management Console
- Log into your DNS provider dashboard and navigate to the DNS management or zone editor section.
- Locate the specific CNAME record pointing to the decommissioned service, such as
legacy-app.example.com. - Select the delete or remove option for that record.
- Save and publish your zone changes.
Verifying Removal with PowerShell
To confirm that the dangling CNAME has been successfully purged from public resolvers, use PowerShell to query the record:
Resolve-DnsName -Name legacy-app.example.com -Type CNAME -Server 8.8.8.8
If the record has been successfully removed, the command will return a status indicating that the record could not be found or does not exist.
Common Mistakes and How to Fix Them
- Deleting the Cloud Resource First: Many administrators delete the cloud service instance, storage bucket, or CDN distribution first and forget about DNS. Always remove the DNS CNAME record before tearing down the underlying infrastructure.
- Ignoring Apex Records (ANAME/ALIAS): While CNAME records cannot legally sit at the root domain (
example.com), many modern DNS providers offer proprietary ANAME, ALIAS, or flattening features that behave like CNAMEs. Ensure you audit these root-level pointer records just as strictly. - Failing to Clear Local CNAME Caches: After deleting a record, recursive resolvers may continue to serve cached responses until the Time To Live (TTL) expires. Always check your TTL values before decommissioning and test using explicit public DNS resolvers.
Infrastructure Decommissioning Checklist
- Inventory all external cloud integrations and CDN targets.
- Audit the DNS zone for stale or unreferenced CNAME records.
- Test target endpoints for cloud-specific error signatures.
- Delete the CNAME records from the DNS provider zone file.
- Verify global propagation and ensure resolvers return NXDOMAIN.
- Document the decommissioned endpoints for internal compliance.