# Hunting Subdomain Takeover And Dangling Dns > Hunt DNS records that point at infrastructure the organization no longer controls, so an attacker can claim the target and serve content under a trusted name. Covers a CNAME or ALIAS to a decommissioned platform host that the provider lets anyone re-register, a dangling NS delegation whose nameserver or zone no longer exists in the account, a record that outlives its resource because infrastructure-as-code or a teardown pipeline deletes the resource but not the record, and a wildcard or unclaimed virtual host routed to a default backend. Use when reviewing DNS zone files, the DNS records declared in infrastructure-as-code, and the pipelines that provision and tear down them. The resolvable record whose target is unclaimed is the source, an attacker serving content on the trusted origin is the sink, and a claimable dangling target is the bug. - Skill: `unboundcompute/hunting-subdomain-takeover-and-dangling-dns` (Agent Skill) - Install (CLI): `npx skillmds@latest add unboundcompute/hunting-subdomain-takeover-and-dangling-dns` - Raw SKILL.md: https://api.skillmd.com/api/skills/unboundcompute/hunting-subdomain-takeover-and-dangling-dns/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: MIT - Author: UnboundCompute (https://skillmd.com/u/unboundcompute) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/unboundcompute/hunting-subdomain-takeover-and-dangling-dns --- # Hunting subdomain takeover and dangling DNS: who can claim the name you still point at A subdomain takeover is not a source-code bug, which is exactly why source-focused reviews miss it. It is a bug in DNS state: a record still resolves, but the thing it points at is gone, and the shared provider will hand that target to whoever asks next. When an attacker claims it, they serve content on your trusted origin, with a real certificate, inheriting parent-domain cookies, allowlist and content-policy trust, and OAuth redirect standing. You hunt it by inventorying the records, resolving each target, and asking one question per record: is the target still owned, and if not, can an attacker claim it. The discipline is separating a record that merely returns a 404 from one whose target is genuinely re-registrable, because only the second is a takeover. ## When to use - You have DNS zone files, or the DNS records declared in infrastructure-as-code, for a domain in scope. - A subdomain points at a platform host, storage bucket, content-delivery endpoint, or third-party service. - You want to know which records are dangling and, of those, which an attacker can actually claim. ## Scope check Enumerate and fingerprint only domains you own or are authorized to assess, and never register or claim a target you do not own outside an authorized engagement, claiming it is the point of no return and can hijack live traffic. Demonstrate claimability by fingerprint, not by seizing the name. If you can't name the authorization, stop. ## The loop 1. **Inventory the records and resolve every target.** Collect the CNAME, ALIAS, NS, and wildcard records from the zone and from any infrastructure-as-code that declares them, and resolve each to the host or service it points at. The record set is the surface; a record whose target no longer answers, or answers as unrecognized, is the lead. 2. **Fingerprint the target's claim state.** For each dangling-looking target, read the response the provider returns. A takeover needs two things together: a provider fingerprint that says the host is unclaimed (an unrecognized-domain page, a no-such-bucket error, a default landing that invites registration) and a provider that permits open re-registration of that name. One without the other is not a takeover. 3. **Check for dangling delegation.** An NS record that delegates a subdomain to a nameserver or hosted zone that no longer exists in the account hands the entire subtree to whoever can create that zone. Delegation takeovers are more severe than a single CNAME because they capture every name beneath the delegated label. 4. **Trace the provisioning and teardown pipelines.** Look for the record that outlives its resource: a name declared in one infrastructure-as-code state while the resource it targets was removed from another, and a teardown pipeline that deletes the cloud resource but leaves the DNS record to a separate, manual, or later step. Ordering that frees the resource before the record creates a dangling name on every teardown, by design. 5. **Check wildcards and unclaimed virtual hosts.** A wildcard record that resolves every label to a shared ingress routing by host header lets an attacker present an unclaimed host that a default or attacker-reachable backend serves. Enumerate which labels are actually bound and which fall through. 6. **Confirm and record.** Confirm by matching the provider's unclaimed fingerprint and verifying the provider allows re-registration of that exact name, without seizing it. Kill the lead if the target is still owned by a live resource in another account or region despite the 404, if the provider verifies ownership or scopes the name to the original account so it cannot be re-registered, if the record is NXDOMAIN with no delegation and no wildcard behind it (a dead record, not a dangling one), if the name resolves only inside a private or split-horizon zone unreachable from the attacker's position, or if the resource is intentionally managed out of band and still owned. Record the record, the target, the provider fingerprint, and the claim path. ## Where dangling DNS leaks - **A dangling record is an infrastructure-state bug, not a code bug.** Source review never sees it; you have to read the zone and resolve the targets to find it. - **A 404 is not a takeover.** The record has to point at a target the provider will hand to someone else; a target still owned by the organization returns 404 and is inert. - **Delegation takeovers own the whole subtree.** A dangling NS record is worse than a dangling CNAME, because claiming the delegated zone captures every name under it. - **Teardown ordering manufactures dangling names.** When the pipeline deletes the resource before the record, or a different owner holds the record, every teardown leaves an orphan; the fix is ordering, not a one-time cleanup. - **The claimed origin inherits the parent's trust.** A taken-over subdomain gets a valid certificate, parent-domain cookies, allowlist and content-policy standing, and redirect trust; that inheritance is what makes it critical. ## Worked example (a confirm and a kill) > **Confirm.** A subdomain CNAMEs to a platform-as-a-service host whose application slug was > decommissioned; the host now returns the provider's unrecognized-application page, and the provider > lets any account register that slug. Registering it (in an authorized test) would serve attacker > content on the trusted subdomain with a valid certificate. **Confirmed** subdomain takeover via a > dangling CNAME to a re-registrable platform host, `high` rising to `critical` where the parent domain > shares cookies or an allowlist, remediation = remove the dangling record, and reorder teardown so the > record is deleted before or with the resource. > > **Kill.** A subdomain CNAMEs to a storage host that returns a no-such-bucket 404, but the bucket name > is still reserved by the organization in another region and the provider scopes bucket names globally > so no other account can register it. The record resolves, the target 404s, but the name cannot be > claimed. **Killed**, `kill_reason` = "target returns 404 but the name is account-reserved and the > provider forbids re-registration by any other account, so there is no claim path." ## Rationalizations to reject - *"The subdomain returns a 404, so it is dead and harmless."* -> A 404 from an unclaimed, re-registrable target is the takeover. Fingerprint the provider and check whether the name can be claimed. - *"We deleted the resource, so the record is fine."* -> The record still resolves to the freed target. Deleting the resource without the record is what creates the danger. - *"It is only a staging subdomain."* -> Staging usually shares the parent domain's cookies and trust; a takeover there reaches production users through that shared origin. - *"The wildcard covers it."* -> A wildcard to a host-routing ingress lets an attacker present an unclaimed label the default backend serves; the wildcard is the exposure, not the cover. - *"Nobody knows that record exists."* -> Passive DNS and certificate logs publish it. Obscurity is not ownership; claimability is. ## Executing this in practice You need the zone records and the DNS declared in infrastructure-as-code, the resolved target of each record, the provider fingerprint for any target that no longer answers as owned, the provider's rules on re-registering that name, and the provisioning and teardown pipelines that create and remove the records. For each dangling target, decide whether an attacker can claim it. Resolving the record tells you it is dangling; the provider fingerprint and its registration rules tell you whether it is takeoverable. ## Related - `mapping-attack-surface` - the recon that inventories the DNS surface this hunt adjudicates; surface discovery finds the records, this skill decides which are claimable. - `auditing-session-lifecycle-and-fixation` - its broad-cookie-domain shape hands off here: a session cookie scoped to a parent domain is capturable once a sibling subdomain is taken over. - `auditing-cors-and-cross-origin-trust` - a taken-over subdomain becomes a trusted origin, so the two weaknesses compound where an allowlist trusts sibling subdomains. - [FINDING-SCHEMA.md](../../FINDING-SCHEMA.md) - source = the resolvable record with an unclaimed target, sink = an attacker serving content on the trusted origin, evidence = the provider fingerprint and the claim path, without seizing the name.