Diverting to a scrubbing centre by BGP prefix or by DNS name: what does each one leave exposed?

## Two ways to attract traffic into rented capacity Diverting into a scrubbing centre means changing where the internet thinks your service lives. There are two mechanisms, and they fail in completely different ways. ### 1. Routing diversion — the provider announces your prefix The mitigation provider originates a BGP announcement for your address block. The internet's routing table now sends traffic destined for those addresses to the provider's network instead of to your transit link. They scrub and hand the survivors back over a return path. **What it covers:** everything. Every host in the block, every protocol — not just web traffic. This is the only option for services that are not name-addressed at all: raw IP services, game servers, VPN concentrators, anything a client reaches by address. **What it exposes:** - **Granularity.** Network operators routinely filter IPv4 announcements longer than a /24, so a /24 is the practical smallest unit you can divert. You cannot divert one host. Everything sharing that block goes with it. - **Blast radius in shared tenancy.** Consider a managed-service provider fronting forty customers out of one address block. One customer is attacked; the block is diverted; all forty customers' traffic now transits the scrubbing centre and pays the detour. The address plan, decided years earlier for convenience, has just become the unit of your incident blast radius. The design lesson is that **diversion granularity should match the granularity at which you want to make diversion decisions** — which usually means placing tenants who differ in risk, latency sensitivity or who pays into different prefixes. - **Prerequisites.** You need address space you control and authorisation for a third party to announce it, and route filters upstream have to accept the change. This is paperwork done in advance, not during the incident. - **Convergence and stickiness.** The route change propagates quickly but not uniformly, and withdrawing it afterwards is another change with its own approval. ### 2. Name diversion — the hostname points at the provider You change the DNS record for a service so it resolves to an address the provider owns. Clients resolve the name, connect to the provider's edge, and the provider connects onward to your origin. **What it covers:** exactly what resolves through the names you changed, and usually only the protocols the provider's edge proxies — in practice HTTP and TLS. It is per-service, needs no address space of your own, and can be applied to one hostname without touching anything else. That surgical granularity is its genuine advantage over routing diversion. **What it exposes:** - **The origin is still routable.** This is the defining weakness. Repointing a name does not move your servers or make their addresses unreachable. An adversary who learns the origin address attacks it directly and the scrubbing centre never sees a packet. Origin addresses leak from many places: historic DNS records archived by third parties, **Certificate Transparency** logs that publish every certificate issued for your names, mail headers that reveal the sending host, error pages, API endpoints and administrative subdomains that were never repointed, and the SPF and MX records that must keep pointing at real infrastructure. - **The mandatory countermeasure.** Name diversion is only real if the origin refuses everyone else — a filter at the origin's edge, or at its upstream, that accepts connections only from the provider's published source ranges. Without it you have added a proxy, not a defence. Maintaining that allowlist as the provider changes ranges is an ongoing operational burden and a foreseeable self-inflicted outage. - **Diversion completes only as cached answers expire.** Resolvers hold the previous answer for its lifetime, and some hold it longer than they should, so the change reaches your user base over minutes rather than instantly. During that spread, part of your traffic is still being sent to the old address. - **Everything not addressed by that name.** Direct-to-IP clients, hard-coded addresses in partner integrations, non-proxied protocols. ## Side by side | | Routing diversion | Name diversion | |---|---|---| | Unit of diversion | a whole prefix, practically a /24 | one hostname | | Protocol coverage | everything | what the provider's edge proxies | | Origin still reachable directly | no, the route itself moved | yes, unless you filter it | | Needs your own address space | yes | no | | Collateral on neighbours in the block | all of them divert | none | | Completion delay | route propagation | cached answers expiring | ## What an interviewer is listening for The weak answer treats these as interchangeable ways of doing the same thing. The strong answer names the asymmetry: routing diversion is **complete but coarse** — nothing bypasses it, and you cannot aim it; name diversion is **precise but leaky** — you can aim it at one service, and an adversary who does five minutes of reconnaissance walks around it. The strongest answer adds that the choice constrains your address plan. If you front multiple tenants or many unrelated services, deciding after the fact that you want to divert one of them is not possible under routing diversion — the decision was made when the addresses were assigned. That is the sentence that shows you have actually operated this.