[dns-operations] solutions for DDoS mitigation of DNS

Tessa Plum tessa at plum.ovh
Fri Apr 3 09:03:30 UTC 2020


So no way to stop reflector attack unless migrating servers to 
professional IDC?

Thanks.

Steven Miller wrote:
> 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.
> 
>      -Steve
> 
> 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