Preventing a particular type of nameserver abuse

Tony Finch dot at dotat.at
Tue Apr 13 10:29:24 UTC 2021


Peter Coghlan <bind at beyondthepale.ie> wrote:
>
> 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.

There have been several helpful replies, but to be honest I wouldn't spend
too much effort on low levels of abuse unless you want to use it as a
learning exercise. (I would care if it was multiple abusive queries per
second...)

> 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.

RRL is designed to avoid interfering with legitimate traffic, but that
does mean that some abuse traffic leaks through. Its aim is to stop
amplification, so that the attackers don't get any benefit from abusing
your server.

But it sounds to me like your problem traffic is more like background
radiation (e.g. probes) than active abuse; if so it's likely that RRL will
not deter them.

> 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.

If all the problem traffic is sl. IN ANY, then I suggest permanently
leaving in place a filter to drop those queries. Use a string match rule,
like Grant Taylor suggested, but match the queries instead of the
responses, so they don't clutter your query logs.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate
becoming rough. Fair. Good.



More information about the bind-users mailing list