[dns-operations] solutions for DDoS mitigation of DNS

Steven Miller steve at idrathernotsay.com
Fri Apr 3 08:50:57 UTC 2020

Adding more servers and going to 10G NICs seems relatively inexpensive 
and that should be helpful for "casual" attacks where you're being used 
as a reflector.  In those attacks, no one's out to attack you: they just 
want you to attack someone else, and don't mind eating all your 
bandwidth/CPU/whatever in order to do that.

Adding more bandwidth without enabling RRL or putting some sort of 
filtering in place will make your facilities more attractive to 
attackers, though.  I'd expect that attackers are passing around lists 
of particularly good sites for reflector attacks, and the fewer controls 
you have, and the more bandwidth you have, the more attractive you are 
for use in an attack -- and therefore the more likely you are to have 
your resources saturated.

I think RRL should be safe to run all the time.  You wouldn't want to 
scramble to enable it during an attack.

I don't know if there are commercial devices I would trust to be helpful 
in these situations, but when I was doing DNS DDoS work, nothing 
commercial was going to scale enough, so I didn't consider them much. :-)

The hard thing about these attacks is that there's always some time when 
local resources aren't enough: when you upgrade to 50Gbit/sec of 
capacity and the next attack is 60Gbit/sec of traffic.  I'd expect some 
correlation between "really high bandwidth attacks" and "attacks that 
are meant to hurt you instead of just use you as a reflector" but that 
correlation won't be perfect.  It's unfortunate that in the DNS attack 
world, for a lot of attacks, all you can do is have massively more 
capacity than you need on a daily basis.

The advantage to moving DNS into a cloud provider is that they have the 
resources to massively, crazily overprovision, to the point where it 
would be hard even for a nation-state to mount a big enough attack to 
take them down.  I'm most familiar with Cloudflare (I have never worked 
there, for the record) but certainly there are other companies worth 
looking at.  However, if you still have your nameservers in the public 
set of NS records for your domains, you'll still be vulnerable.  Some of 
these providers can probably load your zones using you as a shadow 
master: they just do a zone transfer from your DNS infrastructure, then 
serve all the queries from their own systems.

That's my perspective.  Hopefully it's not too out of date.


On 4/3/2020 4:18 AM, Tessa Plum wrote:
> Hi Steve
> I am so appreciate to get your kind private message, though I would 
> like to reply my content to the list.
> We are running authoritative name servers only, zone data are for the 
> university only.
> When the attack happened, the bandwidth watched in our gateway was 
> about 20Gbps. That made name servers totally no response. Each name 
> server has only 1Gbps interface to internet, so it dies.
> We were considering the actions:
> 1. increase bandwidth to both inbound gateway and vlan for nameservers.
> 2. upgrade the network interface of nameserver to 10Gbps.
> 3. run multiple servers as cluster.
> 4. try to get a commercial device to analyst and stop such kind of 
> attack.
> 5. enable RRL when attack happens.
> 6. I will try to suggest administrator to run secondary nameservers on 
> professional hosting, such as cloudflare, Akamai, AWS route 53 etc.
>   (also easyDNS, DNSimple, DNSMadeEasy, NS1 can be considered?)
> How do you think of them?
> Thank you.
> regards
> Tessa

More information about the dns-operations mailing list