Subdomain takeover needs a resolving name and a claimable target — which do you remove, and in what order?
answer
- two prerequisites, break either
- which step opens the window
- the freed name goes back in a pool
- ownership token that must stay published
- claim the target back yourself
basics
~10 sRemove either and the attack dies, so remove both: retire the record before releasing the resource, and prefer targets bound to proven domain ownership. Patching removes neither dependency.
solid answer
~50 sThe technique has exactly two prerequisites: your zone must keep resolving the name, and the target it names must be registrable by someone else. Break either one. The cheap operational control is **ordering**: delete or repoint the record first, then release the resource, so the claimable window never opens - the reverse order opens one that lasts until somebody notices. Structurally, prefer providers whose custom-hostname binding requires an ownership token that must stay published in your zone, or whose target names are never re-issued; a flat first-come namespace is what makes the second prerequisite exist at all. For a name already dangling, the fastest containment is to claim the freed target yourself while the record is cleaned up. In parallel, shrink the blast radius: host-only cookies and no suffix-shaped allowlists. None of this is patching - "we are fully patched" leaves both prerequisites intact.
go deeper
Recall the ordering rule: the DNS record goes first, then the resource is released. Getting that one sequence right prevents most of these.
State the two prerequisites explicitly and map each control to the one it removes. Be able to say why a periodic check is a mitigation of duration rather than a control.
Show the architecture-time move as well as the teardown move — choosing bindings that require proven domain ownership — and have the immediate containment ready for a name that is already dangling.
Turn it into a purchasing and platform question: what you require of a provider's custom-hostname binding before it is approved, and what residual you accept because some record will always outlive its target.
## Name the two dependencies first The technique cannot substitute for either of these: 1. **The name still resolves** to a target that identifies a resource, and 2. **that target is registrable** by a party other than you. Every control worth having attacks one of the two. Framing the answer this way is also what separates a candidate who has thought about it from one who has memorised “delete stale records”. ## Attacking dependency 1 — the resolving name **Ordering is the whole control.** A teardown that releases the resource and then removes the record opens a claimable window between the two steps, and in practice that window is not seconds — it is however long it takes the second ticket to be written, approved and executed, if it is written at all. Reverse it: repoint or delete the record first, confirm it no longer resolves to the provider target, then release the resource. The intermediate state (a name that resolves to nothing) is harmless; the other intermediate state is the vulnerability. **Make the record part of the resource's lifecycle.** Where the record is created by the same automation that creates the resource, destruction can be made to take both. Where the zone is edited by hand in a different team's system, the two lifecycles are structurally unable to stay in step, and no amount of care in the teardown checklist fixes that. **Avoid wildcards.** A `*.example.com` record makes every unclaimed label under the zone resolve to something, which converts a bounded list of names into an unbounded one. ## Attacking dependency 2 — the claimable target This one is chosen at architecture time, when a team picks where a hostname will point: - **Prefer bindings that require proven ownership.** Some providers require a verification token published in your zone before they will serve your custom hostname, and stop serving it if the token disappears. That design makes a freed slot useless to a stranger, because they cannot produce the token for your domain. - **Prefer per-tenant target names that are never re-issued.** If the freed name is retired rather than returned to a public pool, the second prerequisite never exists. - **Prefer pointing at infrastructure you control.** A record aimed at your own load balancer or your own name cannot be claimed by registering something in a shared namespace; the failure mode degrades to an unreachable host. When you evaluate a new provider, “what happens to my custom hostname binding when I cancel” is a purchasing question, and it is rarely on the checklist. ## Containment when one is already live If a name is dangling right now, the record change is the real fix but it may take a change window you do not have. The immediate move is often to **claim the freed target yourself** in your own account, which takes it out of the pool, and then clean up the record at normal pace. If the target is already held by someone else, the record change becomes urgent: repointing it is entirely within your control and needs no cooperation from the holder. ## Blast-radius controls, in parallel These do not stop a takeover; they decide what a takeover is worth, and they are worth having because some name, somewhere, will always dangle: - Host-only cookies rather than cookies scoped to the parent domain. - Allowlists written as explicit hosts rather than as a domain suffix — cross-origin rules, redirect and callback targets, internal service policies. - A CAA record on the zone, which restricts *which* authority may issue for names in it. It narrows the issuance path rather than preventing issuance to whoever controls the name, so treat it as a constraint, not a fix. ## The trap in “we are fully patched” Patching updates code you run. Neither prerequisite is code you run: one is a row in your zone, the other is a policy in someone else's namespace. A perfectly current estate is exposed identically. Equally, a scanner-shaped answer (“we check for it periodically”) attacks neither prerequisite — it shortens how long one persists, which is worth having but is not the control the question is asking for. ## The compact answer Order the teardown so the record dies first; choose targets that cannot be re-registered by a stranger; keep host-only cookies and explicit allowlists so the residual is survivable.
- Why does a teardown that releases the resource first create a window even if the record is deleted the same day?Because the target name returns to the provider's free pool the instant the resource is released, and enumeration of names that resolve to free targets runs continuously and in bulk across the whole internet. The window is not “until someone notices us”, it is “until the next pass”. Reversing the order removes the window entirely rather than shortening it.
- A provider requires a token in our zone before serving our custom hostname. What does that buy?It binds the hostname to demonstrated control of the domain rather than to a first-come label, so a freed slot cannot be inherited by a stranger — they cannot publish the token in your zone. It converts the second prerequisite out of existence for that provider, which is why it belongs in provider selection rather than in the teardown checklist.
- Does a CAA record stop a takeover?No. It restricts which certificate authorities may issue for names in the zone; it does not stop issuance by a permitted authority to whoever controls the name, and it does nothing about the hostname serving attacker content over plain HTTP. Treat it as narrowing one consequence, not as a control on either prerequisite.
- What is the fastest containment for a dangling name you cannot get a change window for?Register the freed target yourself in your own account. That removes it from the pool immediately and costs almost nothing, and it leaves the record change to be done at normal pace. It is a holding action, not a fix — the record still points somewhere it should not, and that debt has to be closed.
saying these in an interview costs you the question
- Answers only “delete stale records” with no ordering
- Believes patching or version currency helps here
- Thinks periodic checking is a control rather than a shortener
- Claims a CAA record prevents the takeover
- Releases the resource first and cleans DNS afterwards