Preventing a particular type of nameserver abuse

[Kevin Darcy]

[ 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 <bind at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210412/c9effbd2/attachment-0001.htm>