Mitigation technique
Anycast for DDoS Mitigation
Last updated: August 2026 · Dispersal, not filtering · Reading time ~11 min
Anycast announces the same address from many locations so the network delivers each client to a topologically near one. Against volumetric attacks it disperses the load across every site rather than concentrating it on one — which is a capacity multiplier and not a filter. It does nothing about an application-layer attack, which simply follows the client to whichever site it reaches.
Anycast is a routing arrangement rather than a security control. The same address is announced from many locations, and the network’s own path selection delivers each client to whichever announcement is nearest by its metrics RFC 4786.
Nothing about it inspects traffic. Its value against DDoS comes entirely from arithmetic: an attack aimed at an address announced from thirty sites arrives at thirty sites.
What dispersal buys
| Appliance | What happens to attack volume | What happens to a stateful session | Suits |
|---|---|---|---|
| Unicast, single site | Concentrates on one location | Stable | Small estates with upstream protection |
| Anycast, few sites | Divides roughly by site count | Mostly stable; re-routing events break some sessions | DNS and other stateless services |
| Anycast, many sites | Divides widely; each site sees a fraction | Re-routing is more frequent | Large stateless services and CDNs |
The middle column is the constraint people meet second. Anycast is native to stateless protocols and requires deliberate design for stateful ones.
The multiplier is real and large. A volume that would comfortably saturate a single 10 Gbps site becomes a manageable share at each of many sites, and a network with enough locations can absorb attacks that no single facility could.
Dispersal also localises damage. If one site is overwhelmed, clients whose paths lead elsewhere are unaffected — which is a very different failure profile from a single site going down.
What it does not do
It does not filter. Every packet still arrives somewhere and is still paid for in bandwidth and processing. Anycast raises the ceiling; it does not lower the volume.
It does not help against application-layer attacks. Expensive requests follow their senders to whichever site serves them, and each site pays the full cost of answering. A request flood against a search endpoint costs the same across thirty sites as across one.
It does not fix a shared backend. If all sites query the same database, dispersing the front end concentrates the load at the back. This is the most common way an anycast design fails to deliver what was expected of it.
Operational constraints
Statefulness is the design question. Anycast is native to stateless protocols and requires deliberate handling for stateful ones. A route change mid-session lands a client on a site with no state for the connection, which resets it. On DNS this is invisible; on a long-lived TLS session it is a user-visible failure.
Withdrawal has to be routine. The response to one site being overwhelmed is for that site to stop announcing and let others take its share. That is an operation you want practised, with a clear rule for who decides and how quickly the rest of the network absorbs the load.
Traffic engineering is imprecise. Path selection is other people’s routing policy, not yours. Load distribution across sites will not be even, and the site that receives the most traffic is not necessarily the one you provisioned for it.
Debugging is harder. “Which site served this client” is a question that has to be answerable from telemetry, or incident analysis becomes guesswork.
False-positive risk
None inherent — anycast makes no accept-or-drop decision. The risk is different in kind: a site under pressure that degrades rather than withdrawing serves a fraction of clients badly while the rest of the network looks healthy, and aggregate monitoring will not show it. Per-site metrics are not optional on an anycast service.
Where it fits with other techniques
Anycast pairs naturally with scrubbing: dispersal reduces the volume any single scrubbing location must handle, which is why large mitigation providers are anycast networks first and filtering platforms second.
It does not replace upstream instruments. A site being saturated still needs a way to shed load, and withdrawal from the anycast set is the anycast version of exactly that decision.
For DNS specifically, anycast and transport behaviour interact: operational guidance requires TCP support alongside UDP RFC 9210, and a TCP-fallback path across an anycast set inherits the session-affinity question above.
How to verify
- Confirm from telemetry which site serves which client population, and keep that queryable.
- Withdraw one site deliberately in a maintenance window and measure how long redistribution takes and whether anything breaks.
- Load-test a single site to the point of degradation and confirm your monitoring shows it before aggregate metrics do.
- If any service on the anycast address is stateful, measure the session-reset rate during a deliberate route change.
- Check whether the backend behind all sites is itself a single point of concentration.
Sources
Frequently asked questions
- Does anycast stop DDoS attacks?
- It disperses them. An attack that would saturate one site is divided across every site announcing the prefix, so each sees a fraction and each may cope. Nothing is filtered — the same total volume arrives — which is why anycast is best described as a capacity strategy that happens to be extremely effective against volume.
- Why is anycast so common for DNS specifically?
- Because DNS over UDP is stateless: any site can answer any query, and a client landing on a different site next time costs nothing. That property is exactly what makes anycast easy there and awkward for long-lived stateful sessions.
- What happens to TCP or TLS sessions when routing changes?
- They break. If a route change moves a client to a different site mid-session, the new site has no state for that connection and resets it. On a well-run network these events are rare, but they are not zero, and a service where a reset is expensive needs either session affinity mechanisms or a design that tolerates it.
- Does anycast help against application-layer floods?
- Barely. An attacker sending expensive requests is routed like any other client, so the requests arrive at whichever site is near them and cost the same to serve. Dispersal helps only to the extent that the attacker's own sources are geographically spread — which for a botnet they often are, but the requests still have to be answered.
- Can an attacker target one anycast site?
- By choosing sources whose topology maps to that site, yes, and it happens. The countermeasure is capacity and withdrawal: a site that is being overwhelmed can stop announcing the prefix and let neighbouring sites absorb its share, which is a routine operation on a mature anycast network and a fire drill on an immature one.
Sources
- RFC 4786 (BCP 126) — Operation of Anycast Services
IETF · 2006-12 · standard · accessed 2026-08-15
The operational reference for anycast deployment, including the service-affinity considerations that make it awkward for stateful protocols.
- RFC 9210 — DNS Transport over TCP: Operational Requirements
IETF · 2022-03 · standard · accessed 2026-08-15
Published: August 2026 · Last reviewed: August 2026
Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.
This guide is updated as vendors release new models and pricing. How we compare vendors