<div dir="ltr"><div>[ Classification Level: <font color="blue">GENERAL BUSINESS</font> ]</div><br class="cursAfter"><br>It's not a "BIND" solution, per se, but if you have a sufficiently-sophisticated IPS (Intrusion Prevention System) you could have it simply drop all queries of a particular QNAME, or any particular combination of QNAME, QTYPE, QCLASS, before those packets even get to named. I know SNORT-based IPSes can do this, not so sure about other IPSes, but most of them have a custom rule/signature capability. As Grant pointed out, it wouldn't even need to be a dedicated IPS -- one could potentially leverage that IPS capabilities of a firewall.<div><br></div><div>                                                                                      - kevin</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 12, 2021 at 4:10 PM Peter Coghlan <<a href="mailto:bind@beyondthepale.ie" target="_blank">bind@beyondthepale.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
I have a nameserver which is authoritative for three or four domain names.<br>
It receives around 1000 queries per day that could be regarded as plausably<br>
legitimate.  It receives around ten times that number of absive queries per<br>
day from presumably spoofed ip addresses, the vast majority of them IN ANY<br>
queries for the "sl" domain or for the root nameservers all of which my<br>
nameserver responds to with return code 5 ie refused.<br>
In many cases, the source port is a low number such as 53, 80, 96 or 443<br>
for example which might make some sense if these were TCP queries but they<br>
are all UDP queries and apart from attempting to target port 53, attempting<br>
to target the other low UDP port numbers make no sense to me.<br>
I have searched high up and low down for any discussion about this kind<br>
of abuse and found very little regarding abusive queries for the root<br>
nameservers, none at all regarding the sl domain (although it is a difficult<br>
term to search for) and nothing at all regarding the oddball source ports<br>
Even though the "refused" responses from my nameserver are "small", the<br>
general persistence of the abusers over a long period of time suggests to<br>
me that they are finding these queries effective for some kind of abuse,<br>
perhaps by way of having a very large number of nameservers return them<br>
(unless they are too stupid to care whether the queries are answered or<br>
refused which I suppose is also possible).<br>
As far as I can see providing no response at all in any instance when a<br>
code 5 refused response would normally be returned would be the appropriate<br>
thing for my nameserver to do here and doing this would cause no difficulties<br>
at all with any legitimate queries or anyone who is not an abuser.  Am I<br>
correct here?<br>
I have searched for a way to prevent my nameserver from responding<br>
to these queries at all in order to reduce the impact on the targets<br>
of this abuse.  All results of my research point to the use of<br>
rate limiting as the only approach available for dealing with this<br>
sort of issue.<br>
The abusive queries are clearly designed to circumvent the widely<br>
suggested "errors-per-second 5" as they arrive in groups of five<br>
per second and applying this limitation has little or no effect<br>
on them.<br>
I have tried "errors-per-second 1" and this seems to reduce the abuse<br>
by about four fifths but one fifth of it still manages to get through<br>
and I don't find this acceptable.<br>
Instead, when I notice particularly heavy abuse of my nameserver,<br>
I apply packet filtering to prevent the abusive queries from reaching<br>
my nameserver and therefore to prevent it responding to them.  I<br>
also routinely packet filter all UDP dns queries with source port<br>
numbers less than 1024 which I hope is the appropriate cutoff point.<br>
Is there anything else I can do to reduce the impact of this abuse<br>
of my nameserver on others?<br>
My feeling is that mine can't be the only nameserver experiencing this<br>
kind of abuse and that many nameserver admins probably would not even<br>
notice it unless they had query logging or query-error logging turned<br>
on and checked the logs.<br>
Peter Coghlan.<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>