The Endpoint Nobody Owns

## What “dangling” means A DNS record maps a name you publish to a target. A hostname like `app.example.com` is very often a `CNAME`: an alias whose value is *another name*, usually one inside a cloud or SaaS provider's own namespace — an object-storage endpoint, a platform app slot, a vendor's custom-hostname endpoint. Your zone says, in effect, “for `app.example.com`, go and ask that other name”. The provider's namespace decides what that other name answers with. A record goes **dangling** the moment the target stops belonging to you while the record keeps resolving. The two live in different systems, owned in practice by different people: the alias is a row in your zone, the target is a resource in someone's cloud account. Deleting the resource does not touch the zone. ## The property that makes it exploitable The enabling fact is not that the record is stale — stale records are ordinary. It is that **the target name is re-registrable, first come first served**. Provider namespaces are usually flat and shared: bucket names, app slot names and tenant subdomains are handed to whichever account asks for one that is currently free. When your resource is deleted, its name goes back in the pool. Anyone who then creates a resource with that exact name inherits everything that still points at it — including your hostname. So the takeover is two ordinary operations: notice a name that resolves to a free target, and register the target. There is no exploit, no credential, no defect. The victim's own zone does all the work of directing traffic. ## What the claimant actually gets - Content served at *your* hostname, to your users, your staff and anything that trusts that name. - A publicly trusted certificate for that hostname, because control of the name is what domain validation tests — the padlock proves the holder controls the name today, never that the name is still operated by the organisation whose brand it carries. - Whatever trust anything else in your estate grants by name or by suffix. ## Common shapes - **A released object-storage bucket.** The zone aliases a hostname to a bucket endpoint; the bucket is emptied and deleted; the bucket name is free. - **A decommissioned platform app slot.** A demo or a retired service is torn down; the slot name returns to the pool. - **A cancelled vendor tenant.** A SaaS subscription lapses; the marketing hostname still aliases the vendor's endpoint, and the vendor re-issues the tenant identifier. - **An A record to a released provider IP address.** A weaker variant: the claimant needs that address reallocated to them, which is probabilistic rather than deterministic — cheap at scale, unreliable against one specific name. ## The twin that is not an attack at all The usual origin is a competent administrator following a correct checklist. A decommissioning ticket says “delete the resource”, and it is closed correctly when the resource is gone. Nothing in that checklist owns the zone, which is often administered by a different team entirely. Both halves behaved properly and the gap between them is the whole vulnerability. ## Who takes it, and why that shapes what happens next The typical claimant is not after you. Bulk squatters enumerate names that resolve to free targets across thousands of organisations, claim the cheap ones, and monetise by resale, by parking, or by borrowing the reputation of a recognisable name. That is why a taken subdomain often sits harmlessly for months before anything is served from it, and why “nobody is targeting us” is not a reason to leave one standing. ## What it is not It is not a poisoned resolver answer and not a seized registrar delegation — in both of those, someone subverts or steals the *answer path*. Here the answer path is correct and honest: your zone genuinely publishes that alias, and the resolver faithfully returns what you asked it to publish. The organisation is not being lied about; it is publishing a pointer to something it no longer owns.