Security Guides
Subdomain takeover (dangling DNS) — your domain is served by an attacker, and your servers were never touched
Delete a cloud resource but leave the CNAME behind and anyone can claim that subdomain — your servers untouched. Why session cookies leak, why a certificate does not save you, and the deletion order that prevents it.
One day a subdomain of yours starts serving an attacker's content — and nobody touched your servers. Patching, authentication, monitoring: none of them sits on this path. The cause is not an intrusion. It is something you forgot to delete.
What actually happens (three stages)
1. Creation
You provision a cloud resource with a fully qualified domain name (app-xxxx.<provider domain>) and add a CNAME record in your zone so thatsub.example.comroutes to it.2. Deprovisioning (half of it)
The resource is deleted when no longer needed. At this point the CNAME forsub.example.comshould be removed too — and isn't. It is still advertised as an active domain while routing to nothing: a dangling DNS record.3. Takeover
A threat actor discovers the dangling subdomain and provisions a resource with the same FQDN you used to control. From then on, traffic tosub.example.comarrives at their resource, where they decide the content.
Your DNS zone (untouched)
sub.example.com CNAME→ app-xxxx.provider.example
↓ only the target was removed
Cloud resource: deleted
the name returns to claimable by anyone
↓ attacker provisions the same name
Attacker's resource (their account)
they decide what sub.example.com serves. Your servers were never touched
CNAMEs are the weak spot because they point at a name
Unlike an A record, which points at an address, a CNAME points at a name — and on many cloud services that name is available to whoever claims it first. The moment you let go of it, somebody else can take it. The documentation says CNAME records are "especially vulnerable to this threat". The same logic applies to MX records, where the consequence is that mail addressed to that subdomain can be received by someone else.
The damage is not just a fake-looking page
- Loss of control over the subdomain
- Content you do not manage is served from your own domain — brand damage and loss of trust
- Cookie harvesting
- Web apps commonly expose session cookies to subdomains via a wildcard (
*.example.com), where any subdomain can access them. A convincing page on the hijacked subdomain can collect them from visitors — including cookies marked Secure - A base for phishing
- Because the domain checks out as genuine, phishing from it is far more persuasive
The biggest misconception: "it's HTTPS, we have a certificate"
The documentation names this as a common misconception and rejects it: a threat actor holding the hijacked subdomain can apply for and receive a valid certificate for it. A domain-validated certificate checks that the requester controls the name at that moment, so it does not detect that control changed hands.
The result is that a valid certificate works for the attacker — the padlock appears, cookies marked Secure are still sent, and the fake site looks more legitimate, not less. Read a certificate as "who holds this name", never as "who I am talking to".
The fix is making the deletion order a mechanism
The cause is not technical difficulty; it is the order of the decommissioning steps. Delete the resource first, do the DNS later — that gap is the attack surface.
The order that produces incidents
Delete the resource → DNS later → forget
Meanwhile DNS keeps advertising a live, legitimate subdomain. Monitoring will not tell you a server went down — because nothing went down.
The safe order
Remove the DNS record first → then delete the resource
The documentation recommends applying delete locks to resources that have a custom DNS entry, because the lock itself signals that the mapping must be removed before the resource is deprovisioned — while noting that measures like this only work combined with internal education.
Put "remove the DNS entry" on the decommissioning checklist
This is the first prevention step the documentation gives: put it on the list of required checks when decommissioning a service, and educate developers to reroute addresses whenever they delete resources. The point is not to leave the ordering to anyone's memory.
Couple the record's lifecycle to the resource's
Some providers offer record types bound to the resource itself (alias records and similar). Delete the resource and the record becomes an empty set, so it cannot dangle by construction. Coverage is limited to certain services, but use it wherever it applies — this is closing the gap in design rather than in process.
Require proof of ownership
Some services let you publish an ownership-verification TXT record for a custom domain. Where one exists, no other subscription can validate that custom domain or take it over. It does not stop someone creating a resource with the same name, but without the ability to prove ownership they cannot receive your traffic — the boundary moves from "first to claim the name" to "able to prove ownership".
Review DNS zones regularly — does it exist, and do you own it?
The documentation gives two checks: does the target exist, and do you own it. The second matters most, because "it responds, so it's fine" is not a check — a response coming from somebody else's resource is precisely this attack. Keep a service catalogue mapping FQDN endpoints to owners and export it on a schedule as part of your asset inventory.
When you find one, do not stop at deleting the record
The remediation steps go further: update stale subdomain references in your application code, investigate whether a compromise occurred, and work out why the record was not removed at decommissioning so it does not repeat. In particular, if your application logic sent secrets such as OAuth credentials, or privacy-sensitive information, to that dangling subdomain, that data may have been exposed to a third party.
This site's view: attack surface grows out of what you stopped using, not what you built
Security conversations gravitate to what is being built, while the holes tend to come from what was retired and left behind. A subdomain nobody uses, a departed colleague's account, a staging environment spun up for one experiment, member records kept after a subscription was cancelled — all of them share the property that "we don't use it any more" quietly removes something from monitoring and review. Something you stopped using is still an asset until it is deleted. So we argue for scoping the inventory to everything you ever created, not to what is currently running. The people who found themselves in scope of a provider breach after cancelling their service were in the same shape (what to do when your hosting provider is breached).
Sources (primary)
- Microsoft, "Prevent dangling DNS entries and avoid subdomain takeover" (Microsoft Learn / Azure security fundamentals) — learn.microsoft.com (the three stages, why CNAMEs are especially vulnerable, cookie harvesting and MX records, the rejection of the certificate misconception, and the preventive and remediation steps — delete locks, alias records, ownership verification, regular review — all come from this document)
Read next
- Inventory: the asset inventory checklist (extend it to everything you ever created)
- Placement: public buckets (the same "it leaks by configuration" shape)
- Glossary: what phishing is / what XSS is / what CSRF is
FAQ
QDoes a subdomain takeover mean my servers were breached?
No, and that is what makes it awkward. What gets taken over is where DNS points, not your server. If you delete a cloud resource but leave the CNAME record in your DNS zone, a third party only has to provision a resource with the same fully qualified domain name under their own subscription, and traffic aimed at your subdomain arrives at theirs. Patching, authentication and monitoring all sit somewhere else — none of them is on this path.
QDoesn't HTTPS prevent this? Surely a certificate makes it safe?
It does not, and Microsoft's documentation names this as a common misconception outright: whoever holds the hijacked subdomain can apply for and receive a valid certificate for it. A domain-validated certificate proves only that the party holding it controls that name right now — it says nothing about who that party is, and it does not detect that control changed hands. A valid certificate actually works in the attacker's favour, raising the apparent legitimacy of the fake site.
QIf it only affects appearances, isn't the damage limited?
Sessions leak. Web apps commonly expose session cookies to subdomains via a wildcard (*.example.com), and where that is true any subdomain can read them. If users can be steered to the hijacked subdomain, even cookies marked Secure can end up with the attacker. And a dangling MX record means mail addressed to that subdomain can be received by someone else.
QHow do I actually prevent it?
Make the order of deletion a procedure and a mechanism rather than something people remember. The documentation recommends putting "remove the DNS entry" on the required checklist for decommissioning a service, applying delete locks to resources that have a custom DNS entry so the lock itself signals that DNS must go first, using record types whose lifecycle is coupled to the resource where available, and reviewing DNS zones regularly to confirm both that each target exists and that you own it.