[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