18 ms·
It's not simply having enough aggregate capacity though either. The way anycast works is that a host will take the shortest network path to the closest server.
by phil21 12y ago
It's not simply having enough aggregate capacity though either. The way anycast works is that a host will take the shortest network path to the closest server.
So for example (very high-level) you might have a server in the US, and one in Europe. If your are eating a DDoS attack maybe the botnet has tons of US-based IPs, but very few euro. In that scenario, you will have all your US customers down but the EU guys are just fine.
That's pretty simplistic though. It's less by country, more by ASN. And it's also a case of automation killing you. What happens when the DDoS attack takes out a single PoP worth of DNS servers? Usually you have some automated tooling that will take down that PoP entirely, and withdraw the announcement. You want this behaviour in almost all cases. However, now that attack traffic just got sent to the next-closest server (in this example EU - taking down the whole worldwide cluster).
So it's not as simple as having "100gbps worth of inbound DNS capacity" - you need to spread it out properly, and of course deal with attacks like you would otherwise.
The other problem is it's UDP - so spoofed packets and the like are a much bigger problem.
- skuhn 12y agoYou're right, you definitely need significant single site capacity (2-3 sites with 100Gbit/s, not just the entire system, for instance), and you may even have to play routing games to move traffic around if that's not enough. Any other sites may have to get shut off during massive abuse incidents. It's a tough call to say if it's better to protect the rest of the network by trying to isolate the attack, even though that means you are totally down in one region. I'm inclined to keep 1/2 running than to have nothing, but if I have this release valve of moving traffic to the farms designed to soak up abuse traffic then it makes my decision easier. I should be able to get back up worldwide, if I've done my provisioning properly. One of the nice things about this kind of attack is that your attacker has no choice but to follow your routing, whereas if you use your DNS GSLB to re-route an attacker away from your HTTP server farm (to handle a different sort of attack), they may not stop hammering on its IP address. After all, it's pretty unlikely that they respect DNS TTLs. This approach is simplistic, but it's basically the only solution. The nature of a DDOS attack is that you cannot predict its origin, beyond the distribution of compromised client machines around the world. E.g. your attackers are pretty unlikely to come en masse from Africa. Spoofing is an issue. Not much to do about that at your farm level, but you can start working with your upstreams to get ACLs in place to prevent some portion of that. And if the attack is prolonged and sufficiently large, the only way you're going to stop it is to identify sources and get help from involved networks and ISPs.