A dangling CNAME hands an attacker a hostname the company still owns

Two conditions have to hold at the same time, and only one of them sits inside the organization's systems ^[15]. The pointer is theirs to edit: blog.company.com is a CNAME in a zone they administer ^[3]. The vacancy is on somebody else's platform, and platforms recycle project names, subdomains and endpoints by design so the identifiers can be reused ^[8]. A dangling record on its own is not necessarily dangerous, and the dev.to explainer says so before it describes the attack ^[7].

Ordinary work manufactures the condition. Marketing pages, documentation sites and staging environments get provisioned and later deleted as teams change and projects wind down ^[4]. The record survives because nobody thinks to remove it and the infrastructure list was not updated ^[5]. "DNS ownership and resource ownership have separate lifecycles, and only one of them was maintained," the explainer says ^[14].

So the check that catches this is a comparison, run on a schedule: every external CNAME target in the zone against the resources that still exist in the provider accounts behind them. Reading the zone alone tells you the target is a valid name, not whether anything is hosted there ^[6]. I would also fix the order of teardown, since it costs nothing: remove the DNS record first, delete the external resource second, and there is no interval when a live hostname points at a claimable identifier ^[9].

What a takeover is worth depends on the target's configuration. The explainer lists the variables: what the subdomain was used for, how cookies are scoped, whether other services trust that hostname, and what the attacker does with it ^[12]. It also declines the maximal version. "Subdomain takeover doesn't automatically break session security or compromise parent domain applications. But serving attacker-controlled content under a trusted hostname is still a meaningful security failure," the explainer says ^[13]. For the session-theft reading to apply to your environment, a cookie would have to be scoped to the parent domain, or another service would have to treat that hostname as trusted ^[12]. Both are things you can read off a config.

The attack steps in the explainer are reconnaissance and a signup form: find a subdomain pointing at an external platform, notice the resource is inactive, create an account, claim the same identifier ^[9]. The organization's registrar entry and its DNS record are untouched throughout ^[10]. Whether a given provider still permits that reclaim is a question to answer vendor by vendor; the explainer describes the behaviour generically and does not name the platforms that allow it ^[16].