A blackhole stopped the flood in forty seconds but took eleven unrelated services with it, so what went wrong?

## Read the postmortem correctly The tempting conclusion is that the on-call made a bad call. They did not. Forty seconds to end a volumetric flood is the control working exactly as designed. What failed was that nobody had ever answered the question **"what dies when we blackhole this address?"** before the night it mattered. A blackhole is a routing action. Routing sees a destination prefix. It cannot see hostnames, TLS SNI, ports, or which of your teams owns what. The unit of destruction is therefore the address, and if your architecture does not make address boundaries equal service boundaries, then your mitigation granularity is whatever your address plan happened to become over ten years. ## The three ways one host route kills eleven things **Shared front-end address.** The overwhelmingly common cause. Many services sit behind one reverse proxy or one load-balancer VIP, distinguished by hostname or SNI at layer 7. From the internet they are one address. The attacker floods one hostname, you blackhole the address that hostname resolves to, and every co-tenant of that address disappears. Note the asymmetry that makes this so easy to walk into: the attacker only needed to know one name, and you paid for all eleven. **Prefix length inflation.** The on-call intended a `/32` and announced something coarser. This happens when the upstream's inbound policy will not accept a prefix that long, when the automation was written against the allocation rather than the host, or when someone reasons that a wider announcement is safer. A `/24` takes two hundred and fifty six addresses off that path, and the postmortem then contains eleven services that were never even adjacent to the attack. **The address had a second job.** An internet-facing address is often also the source address for outbound connections, a NAT pool member, or the endpoint of a partner VPN or an API integration. Discarding traffic to it silently breaks return traffic for flows that had nothing to do with the flooded service, and those failures show up as unrelated timeouts in someone else's dashboard. ## What should have existed beforehand **An address-to-service inventory.** For each internet-facing address, what names resolve here, which teams own them, and what depends on it that is not a web request. This is a table, it is small, and it is the difference between an on-call making a priced decision and making a blind one. Reading it should take ten seconds, because the whole appeal of this lever is that it works in forty. **Address boundaries drawn as blast-radius boundaries.** Anything you might ever have to sacrifice should sit alone on its own address, and anything you cannot sacrifice should not share an address with a likely target. That costs addresses and it costs some proxy configuration, and it is the price of having a mitigation with a survivable blast radius. **A designated alternative for the shared addresses.** For the addresses that genuinely cannot be sacrificed, the coarse lever must be off the table, which means the runbook has to name what the on-call does instead. That is where a granular upstream rule earns its keep: matched on protocol, ports and packet characteristics rather than destination alone, it can shed the flood while leaving the address alive. It also has to exist in the transit contract *before* the incident, and that is a purchasing decision made in daylight, not at 03:00. ## Recovery is not symmetric Withdrawing the announcement restores routing in seconds, so the eleven services come back quickly once someone realises. But two clocks are longer than BGP. If anyone reacted by renumbering a service onto a new address, the recovery time is the cached DNS TTL of the old name, not convergence. And the attacker may still be there: withdrawing is a live re-test of the flood, so the sequence has to be planned as "withdraw, watch the link, be ready to re-announce", with a named person deciding, rather than a hopeful click. ## The answer an interviewer is listening for Say that the incident is evidence about your address architecture rather than about the responder. Then give a concrete remediation order: build the address-to-service map this week, split the shared front end so the sacrificeable services stand alone, cap what the on-call may announce at the longest prefix every upstream accepts, and negotiate a granular option for the addresses that must never go dark. That is a defensible plan with costs attached, which is what the question is really testing.