[dns-operations] solutions for DDoS mitigation of DNS

[Steven Miller]

Essentially, yes.  Some increase in capacity on your side plus RRL will 
certainly keep you safer, but it's no guarantee.

Though to be clear, every few years, someone's going to hit a public DNS 
provider with enough load to cause a problem.  IMHO that'll happen less 
on average, and the mitigation time will be lower on average, and the 
pain level for you will be lower on average (no scrambling for 
resources, the ability to say "yeah, a big chunk of the Internet's down, 
I'll let you know when it's over" :-)) than it will happen if you run 
your own infrastructure.

It's a really unfortunate state of affairs.

     -Steve

On 4/3/2020 5:03 AM, Tessa Plum wrote:
> 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
>>
>>