Somewhere in your Azure DNS zones there is probably a CNAME that points at a web app, storage
account, Front Door, or Traffic Manager profile that no longer exists. The team deleted the
resource months ago; nobody touched the DNS record. That record is now a subdomain takeover
waiting to happen: anyone who re-claims that Azure name (the azurewebsites.net or
blob.core.windows.net hostname your CNAME still points at) inherits your subdomain,
on your domain, with your reputation behind it. Phishing pages and cookie theft on
something.yourcompany.com follow from there.
Why Azure cannot do this out of the box
- Deleting a resource does not clean up DNS records that point at it. Azure DNS has no linkage between a CNAME and the resource behind its target. The resource goes away, the record stays, and nothing warns you.
- Microsoft documents the risk, then hands you a one-off script. The official
guidance ships a PowerShell script,
Get-DanglingDnsRecords, that you run manually. There is nothing that watches continuously, and dangling records appear whenever a resource is deleted, not on the day you happen to run a script. - A naive "does it resolve?" check misses a whole class of targets. Front Door, CDN, and Traffic Manager endpoints resolve via wildcard DNS even when the backing resource is gone, so the NXDOMAIN signal alone gives you false confidence exactly where the takeover risk lives.
The DIY approach: enumerate, resolve, classify, repeat
The shape of a real fix is a scheduled job inside your own subscription:
- Enumerate every CNAME record across all Azure DNS zones in the subscription. Reader at subscription scope is enough; this is a read-only exercise.
- Filter to Azure service suffixes such as
azurewebsites.net,blob.core.windows.net,azurefd.net, andtrafficmanager.net. These are the targets someone else can re-claim. - Resolve each target and classify it. A target that no longer resolves is dangling (takeover-able). A Front Door / CDN / Traffic Manager endpoint that resolves via wildcard DNS, but whose backing resource you cannot confirm as owned, deserves a review bucket rather than a green checkmark. A lookup that times out or returns SERVFAIL is unchecked, not healthy. Everything else is ok.
- Run it daily and alert somewhere people look, like a Teams channel, and suppress repeat alerts for records already verified healthy so the report stays readable.
The catch is the same as with every security chore: the script exists, the discipline does not. A scan you ran in March says nothing about the resource a teammate deleted in April, and the wildcard-DNS edge cases mean the obvious ten-line version quietly under-reports.
A ready-made option: Dangling DNS Sentinel
Dangling DNS Sentinel is that pattern packaged. Every day at 06:00 UTC it enumerates every CNAME across all Azure DNS zones in the subscription, resolves each Azure-service target from inside your tenant using the built-in resolver (no external lookup service), and classifies it as dangling, review, unchecked, or ok, then reports to Teams as an Adaptive Card via a Workflows webhook. Records verified healthy are not re-flagged daily, so the alert channel stays quiet until something actually changes. It is read-only (it never changes DNS) and needs only the Reader role at subscription scope.
Key facts
- The risk: a CNAME pointing at a deleted Azure resource can be re-claimed by anyone, who then inherits your subdomain.
- Native tooling: Microsoft documents the risk and ships the one-off
Get-DanglingDnsRecordsPowerShell script, with nothing that watches continuously. - The blind spot: Front Door / CDN / Traffic Manager endpoints resolve via wildcard DNS, so an NXDOMAIN-only check misses them.
- Least privilege: enumerating zones and resolving targets needs Reader at subscription scope, and the job should never write to DNS.
Related reading: find orphaned Azure resources still costing you money.
Written by the team at Katabarwa Labs. We build small, single-purpose Azure tools that run entirely inside your own tenant. Questions: abaho@llmgraph.ai.