<div dir="ltr">I'm very confused that why people on the list are suggesting RRL (even BCP38) to the victim of DoS attack? If I remember correctly, the goal of both RRL and BCP38 is to reduce the chance of participating the attack as a innocent helper.<div><br></div><div>In the introduce of RRL (<a href="https://kb.isc.org/docs/aa-01000">https://kb.isc.org/docs/aa-01000</a>)  , it goes : "RRL helps mitigate DNS denial-of-service attacks by reducing the rate at which authoritative servers respond to high volumes of malicious queries. "  </div><div><br></div><div>Please correct me .</div><div><br></div><div>Davey</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 2 Apr 2020 at 17:45, Ray Bellis <<a href="mailto:ray@isc.org">ray@isc.org</a>> wrote:<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>
<br>
On 02/04/2020 10:12, Tessa Plum wrote:<br>
<br>
> All the packages were DNS requests, some queries like 'dig <a href="http://domain.com" rel="noreferrer" target="_blank">domain.com</a> any'.<br>
> but their IP address seems spoofed.<br>
> A request from the fake address to our nameserver, but nameserver try<br>
> its best to reply to this unreal address.<br>
<br>
If it's a recursive server, apply an ACL so that only expected clients<br>
can query.<br>
<br>
If it's an authoritative server, turn on Response Rate Limiting (RRL) if<br>
it's BIND, or the equivalent feature if is isn't.<br>
<br>
Ray<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>