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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
