I mean if the attacker tries to ask all the open DNS resolver respond to a web server. The web server can just block its UDP ports. If the all the DNS response go to a Authoritative Nameserver(victim), it can just drop all DNS response.

Or is DNS Amplification all about bandwidth?

6 Answers 6


DNS Amplification attacks are very easy to prevent by filtering UDP packets at the edge routers. This is how Cloudflare is able to easily thwart a 300+ gb/s DDoS attack.

  • "Very easy to prevent" is relative. If you set up your edge routers to filter UDP packets, and get hit by 300+ gbps, you are going down unless you have a service like cloudflare or akamai.
    – JZeolla
    Commented May 21, 2013 at 19:19
  • 1
    @Steel City Hacker so did you just say: "if you do what cloudflare does then you will fail because you are not using a service like cloudflare"...
    – rook
    Commented May 21, 2013 at 21:48
  • 2
    What I am saying is that cloudflare and akamai are specifically designed with huge pipes to the Internet, capable of actually passing well over 300gbps easily. Unless you design your network in the same way (infeasible), you will not be successful. The reason their filters work is because they also have pipes big enough to handle it in the first place, thereby absorbing the attack and not passing it on to you.
    – JZeolla
    Commented May 22, 2013 at 13:00
  • @Steel City Hacker Cloudflare has had problems with neighboring nodes becoming initiated with traffic. However, this does not change the solution. CERT suggests restricting DNS clients to 5 resolutions per second... that times 27 million hosts is still a massive amount of traffic. A real solution is to segregate the internet, HTTP servers do not need UDP traffic routed to them. In the highly unlikely event of a Neighbor node to your Amazon EC2 host goes down, then that is their problem, they should consider segregation.
    – rook
    Commented May 22, 2013 at 14:44
  • DNS Amplification attacks are NOT easy to prevent. The best way is to block attacks using per-flow rate limiting, which most Cisco routers do not have a way to do this without special add-ons, and most DNS servers do not have, without special add-ons. If it were that easy, everybody would do it.
    – Brain2000
    Commented Feb 4, 2014 at 6:00

We can but...

At the point the query makes it to your server it's already too late. Your server will waste its resources trying to do something with the packets and the requests. Even if you have something like iptables drop all connections it's still going to use up all of the bandwidth on the server inbound. Redirecting all traffic someplace else eats up your outbound bandwidth and propagates the network failure between your server and the now new target.

It's a network infrastructure issue. Not a server issue (unless it's an open recursive resolver). The traffic needs to be handled (killed) further up the pipe. Here's a CERT advisory from March 23rd.

Unfortunately, due to the overwhelming traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based distributed denial-of-service attack. While the only effective means of eliminating this type of attack is to eliminate open recursive resolvers, this requires a large-scale effort by numerous parties.


Source IP Verfication: Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to appear as the victim’s system, the first step to reducing the effectiveness of DNS amplification is for Internet Service Providers to deny any DNS traffic with spoofed addresses.


The problem is that you need to drop the traffic before it reaches your network. So even when dropping packets at your server is way too late. The best way to reduce risk is to use packet scrubbing services like Akamai or Cloudfare who have DDoS mitigation techniques in place to prevent this traffic from reaching your network.


Blocking the traffic on the server will not stop the DDoS from eventually saturating its uplink and possibly other links within the network. DNS amplification attacks are all about generating large amounts of bandwidth.


The uplink will still be saturated.

The only way to mitigate this is to turn on RRL (response rate limiting) on servers and get rid of open resolvers. And for legitimate open resolvers, have them send UDP packets as small as possible with the TC bit set ("please retry using TCP") so that amplification doesn't happen yet it doesn't break legitimate traffic.

Other mitigation techniques for resolvers include enforcing a minimum TTL (which also helps against poisoning) and a reasonable maximum payload size for responses sent using UDP. Google DNS are using a 512 bytes limit for this reason.


Disabling recursion responses on public DNS servers to random internet IPs - ie closing the "open resolver" hole - does NOT mitigate this because you can still do a spoofed DNS reflector/amplification attack simply by sending queries that result in a "can't give you an answer" response, which can still be much larger than the incoming query.

Really need to use some combination of response-rate limiting or upstream measures as mentioned here previously. Technically you could use egress-filtering to block outgoing packets that originated on a different link/interface than the route to the spoofed destination, but on simple networks (ie with a single internet link) that's not feasible.

Here's an old whitepaper that discusses some other mitigation measures, like using packet hop-counts to guess about the legitimacy of an incoming packet:


But of course filtering and rate-limiting responses at the "reflector point" still doesn't mitigate the large incoming packet-stream that is being directed at your DNS server. It does spare the intended target from being DDoS'd by your DNS server and your DNS server from being bogged-down with junk traffic.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .