[ Classification Level: GENERAL BUSINESS ]
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. - kevin On Mon, Apr 12, 2021 at 4:10 PM Peter Coghlan <b...@beyondthepale.ie> wrote: > Hello, > > I have a nameserver which is authoritative for three or four domain names. > It receives around 1000 queries per day that could be regarded as plausably > legitimate. It receives around ten times that number of absive queries per > day from presumably spoofed ip addresses, the vast majority of them IN ANY > queries for the "sl" domain or for the root nameservers all of which my > nameserver responds to with return code 5 ie refused. > > In many cases, the source port is a low number such as 53, 80, 96 or 443 > for example which might make some sense if these were TCP queries but they > are all UDP queries and apart from attempting to target port 53, attempting > to target the other low UDP port numbers make no sense to me. > > I have searched high up and low down for any discussion about this kind > of abuse and found very little regarding abusive queries for the root > nameservers, none at all regarding the sl domain (although it is a > difficult > term to search for) and nothing at all regarding the oddball source ports > either. > > Even though the "refused" responses from my nameserver are "small", the > general persistence of the abusers over a long period of time suggests to > me that they are finding these queries effective for some kind of abuse, > perhaps by way of having a very large number of nameservers return them > (unless they are too stupid to care whether the queries are answered or > refused which I suppose is also possible). > > As far as I can see providing no response at all in any instance when a > code 5 refused response would normally be returned would be the appropriate > thing for my nameserver to do here and doing this would cause no > difficulties > at all with any legitimate queries or anyone who is not an abuser. Am I > correct here? > > I have searched for a way to prevent my nameserver from responding > to these queries at all in order to reduce the impact on the targets > of this abuse. All results of my research point to the use of > rate limiting as the only approach available for dealing with this > sort of issue. > > The abusive queries are clearly designed to circumvent the widely > suggested "errors-per-second 5" as they arrive in groups of five > per second and applying this limitation has little or no effect > on them. > > I have tried "errors-per-second 1" and this seems to reduce the abuse > by about four fifths but one fifth of it still manages to get through > and I don't find this acceptable. > > Instead, when I notice particularly heavy abuse of my nameserver, > I apply packet filtering to prevent the abusive queries from reaching > my nameserver and therefore to prevent it responding to them. I > also routinely packet filter all UDP dns queries with source port > numbers less than 1024 which I hope is the appropriate cutoff point. > > Is there anything else I can do to reduce the impact of this abuse > of my nameserver on others? > > My feeling is that mine can't be the only nameserver experiencing this > kind of abuse and that many nameserver admins probably would not even > notice it unless they had query logging or query-error logging turned > on and checked the logs. > > Regards, > Peter Coghlan. > > --Boundary_(ID_/cANmbMgveXk/KlZF+xdIQ)-- > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users