Hacker News Reader

Comment by lucb1e | Hacker News Reader

What made this unique now? Was it simply a high load?

Typically what you see are "amplification attacks". That's where Alice wants to DOS Bob, so she spoofs a request to Charlie that appears to come from Bob. This results in a message from Charlie to Bob. The message from A->C is crafted such that it results in a much larger return message from C->B (hence "amplification"). That lets you create an attack that produces a multiple of the bandwidth that you actually control. Then you have a bunch of machine spam the message.

In that case, you see many messages from the same source address (meaning the target under attack, i.e. Bob), but the data requested may vary. In this case, the source addresses were uncorrelated, but they all wanted the exact same address, so basically the opposite.

I can't say that I know what it is, but when you see massive spikes like that it's usually a botnet of some kind (whether it's infected machines, injected connections, or whatever method). Perhaps a bunch of bots resolving their next C&C master?

Do you have any links to resources on Botnets. It's an interesting topic that I know very little about (e.g. How they work, how they come into existence, how they're controlled/monitored, etc). It sounds like you know a decent amount about them.

Book by one of my former professors: http://www.amazon.com/Botnets-The-Killer-Web-App/dp/15974913...

Awesome, thanks!

Towards the bottom of the extremely short article/message:

  3.  Analysis

   This event was notable for the fact that source addresses were widely
   and evenly distributed, while the query name was not.  This incident,
   therefore, is different from typical DNS amplification attacks
   whereby DNS name servers (including the DNS root name servers) have
   been used as reflection points to overwhelm some third party.

   The DNS root name server system functioned as designed, demonstrating
   overall robustness in the face of large-scale traffic floods observed
   at numerous DNS root name servers.

   Due to the fact that IP source addresses can be easily spoofed, and
   because event traffic landed at large numbers of anycast sites, it is
   unrealistic to trace the incident traffic back to its source.

   Source Address Validation and BCP-38 should be used wherever possible
   to reduce the ability to abuse networks to transmit spoofed source
   packets.

> was notable for [random source addresses]

I thought that was a common thing to do if it's not reflected. Flooding the pipe is older rather than newer.

Thanks for clarifying though!

   Most, but not all, DNS root name server letters received this query load.

Why would you want to take down every DNS server though? That's not a very effective tactic due to caching, and what's the motive?

Possibly testing or demonstrating a botnet. I doubt the goal was to actually bring down the DNS root servers. That's been tried before and it's never even made a blip - the system is massively over-provisioned, for good reason.

I wonder, what kind of machines are those? How many of those are currently operating, and where?

Every (almost every?) letter is operated by a different organization, so I'd expect the setups to be different.

http://www.root-servers.org/ has the answers you seek. There are currently 13 root servers operated by 12 different entities (Verizon, NASAN, RIPE, ICANN, etc.) and most locations have multiple sites (physical instances).

Thanks.

When things first started, a root server might have actually been something sitting under Jon Postel's desk, or in the back room of a University.

But these days, root "servers" are geographically load balanced clusters of machines. Think of something like the Akamai CDN, but instead of http(s), this CDN serves up mostly UDP/53 and TCP/53 traffic. The IP for a root server is AnyCast, and the root server operators will balance traffic between sites by adjusting BGP.

Most have built their own custom UDP load balancers at each site and behind those load balancers are several hundred physical servers to respond to the incoming queries. Zone updates are pushed to each site from the back office, so each physical server should have a complete copy of the the "." zone.

A root server operator, operating 1 of the world's 13 largest public udp system, is often under attack, either directly or (as mentioned above), used as part of a reflector attack against someone else. Generally speaking, these systems are over provisioned enough so that a direct attack has minimal impact. But reflector attacks are the main concern. Either way, when an attack starts, the operator has to find something unique in the query itself (as eliminating source addresses in a dddos is nigh impossible), create a filtering rule, and push that to all of their load balancers.

Disclaimer: I used to work for a root server org.

The root servers get large traffic spikes quite routinely, this event was simply an order of magnitude or more larger than any previous events (AFAIK). Also, it actually managed to DoS a few instances, by way of saturating their throughput--though as the notice mentions, the overall DNS wasn't significantly affected aside from a few queries having to be retried.

You can clearly see the spike in this graph[0] (scale it down to Dec to see more detail). These graphs[1] show that it was limited to IPv4.

[0] http://a.root-servers.org/metrics.html

[1] http://k.root-servers.org/statistics/ROOT/monthly/

Nice!

Looking at IPv4 Sources, the spike is mind boggling.

Reply on news.ycombinator.com