<div dir="ltr"><div><br></div><div>TLD can make class identification to serve the most important client, such as the backend server of isp recursive dns and important public recursive dns. But there are many long-tail clients which can not reject directly, pre-build greylist and whitelist.<br></div><div></div><div>Compare to TLD, SLD is simpler,  it can reject the history-rarely visited clients with less critial infrastructure influnence concern.</div><div><br></div><div>ISP recursive dns  should make the access control, only serve their customers.</div><div></div><div>Public recursive dns  and Root  are global anycast deployed.</div><div><br></div><div>To defend amplify attack, there should be more learning  on the open resolvers.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Steven Miller <<a href="mailto:steve@idrathernotsay.com">steve@idrathernotsay.com</a>> 于2020年4月3日周五 下午7:23写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Essentially, yes.  Some increase in capacity on your side plus RRL will <br>
certainly keep you safer, but it's no guarantee.<br></blockquote><div>+1 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Though to be clear, every few years, someone's going to hit a public DNS <br>
provider with enough load to cause a problem.  IMHO that'll happen less <br>
on average, and the mitigation time will be lower on average, and the <br>
pain level for you will be lower on average (no scrambling for <br>
resources, the ability to say "yeah, a big chunk of the Internet's down, <br>
I'll let you know when it's over" :-)) than it will happen if you run <br>
your own infrastructure.<br>
<br>
It's a really unfortunate state of affairs.<br>
<br>
     -Steve<br>
<br>
On 4/3/2020 5:03 AM, Tessa Plum wrote:<br>
> So no way to stop reflector attack unless migrating servers to <br>
> professional IDC?<br>
><br>
> Thanks.<br>
><br>
> Steven Miller wrote:<br>
>> Adding more servers and going to 10G NICs seems relatively <br>
>> inexpensive and that should be helpful for "casual" attacks where <br>
>> you're being used as a reflector.  In those attacks, no one's out to <br>
>> attack you: they just want you to attack someone else, and don't mind <br>
>> eating all your bandwidth/CPU/whatever in order to do that.<br>
>><br>
>> Adding more bandwidth without enabling RRL or putting some sort of <br>
>> filtering in place will make your facilities more attractive to <br>
>> attackers, though.  I'd expect that attackers are passing around <br>
>> lists of particularly good sites for reflector attacks, and the fewer <br>
>> controls you have, and the more bandwidth you have, the more <br>
>> attractive you are for use in an attack -- and therefore the more <br>
>> likely you are to have your resources saturated.<br>
>><br>
>> I think RRL should be safe to run all the time.  You wouldn't want to <br>
>> scramble to enable it during an attack.<br>
>><br>
>> I don't know if there are commercial devices I would trust to be <br>
>> helpful in these situations, but when I was doing DNS DDoS work, <br>
>> nothing commercial was going to scale enough, so I didn't consider <br>
>> them much. :-)<br>
>><br>
>> The hard thing about these attacks is that there's always some time <br>
>> when local resources aren't enough: when you upgrade to 50Gbit/sec of <br>
>> capacity and the next attack is 60Gbit/sec of traffic.  I'd expect <br>
>> some correlation between "really high bandwidth attacks" and "attacks <br>
>> that are meant to hurt you instead of just use you as a reflector" <br>
>> but that correlation won't be perfect.  It's unfortunate that in the <br>
>> DNS attack world, for a lot of attacks, all you can do is have <br>
>> massively more capacity than you need on a daily basis.<br>
>><br>
>> The advantage to moving DNS into a cloud provider is that they have <br>
>> the resources to massively, crazily overprovision, to the point where <br>
>> it would be hard even for a nation-state to mount a big enough attack <br>
>> to take them down.  I'm most familiar with Cloudflare (I have never <br>
>> worked there, for the record) but certainly there are other companies <br>
>> worth looking at.  However, if you still have your nameservers in the <br>
>> public set of NS records for your domains, you'll still be <br>
>> vulnerable.  Some of these providers can probably load your zones <br>
>> using you as a shadow master: they just do a zone transfer from your <br>
>> DNS infrastructure, then serve all the queries from their own systems.<br>
>><br>
>> That's my perspective.  Hopefully it's not too out of date.<br>
>><br>
>>      -Steve<br>
>><br>
>> On 4/3/2020 4:18 AM, Tessa Plum wrote:<br>
>>> Hi Steve<br>
>>><br>
>>> I am so appreciate to get your kind private message, though I would <br>
>>> like to reply my content to the list.<br>
>>><br>
>>> We are running authoritative name servers only, zone data are for <br>
>>> the university only.<br>
>>><br>
>>> When the attack happened, the bandwidth watched in our gateway was <br>
>>> about 20Gbps. That made name servers totally no response. Each name <br>
>>> server has only 1Gbps interface to internet, so it dies.<br>
>>><br>
>>> We were considering the actions:<br>
>>> 1. increase bandwidth to both inbound gateway and vlan for nameservers.<br>
>>> 2. upgrade the network interface of nameserver to 10Gbps.<br>
>>> 3. run multiple servers as cluster.<br>
>>> 4. try to get a commercial device to analyst and stop such kind of <br>
>>> attack.<br>
>>> 5. enable RRL when attack happens.<br>
>>> 6. I will try to suggest administrator to run secondary nameservers <br>
>>> on professional hosting, such as cloudflare, Akamai, AWS route 53 etc.<br>
>>>   (also easyDNS, DNSimple, DNSMadeEasy, NS1 can be considered?)<br>
>>><br>
>>> How do you think of them?<br>
>>><br>
>>> Thank you.<br>
>>><br>
>>> regards<br>
>>> Tessa<br>
>><br>
>><br>
<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div>