Preventing a particular type of nameserver abuse

[Tony Finch]

Peter Coghlan <bind at beyondthepale.ie> wrote:
>
> I wouldn't describe it as background radiation or probes.  It doesn't seem
> to be caused by misconfigured or faulty resolvers or anything of that nature.

Hmm, maybe air pollution would be a better metaphor? What I mean is the
kind of continuous low levels of abuse that's definitely harmful in
aggregate, but it's not clear who is responsible or what can be done about
it. These sl/IN/ANY queries are exactly the kind of thing I had in mind.

> It is possible for me to apply filtering that catches most or maybe all of
> this but this only fixes the problem on my server and does nothing to prevent
> the abuse of lots of other servers out there.

Yeah, it's a wicked problem. There's very little one can do as a server
operator except for relatively limited mitigations. The real fix is to
trace back the traffic and do malware analysis of the sources and all that
fun forensic blue team stuff that is a very long way away from my job or
abilities :-) Before DNS I did anti-spam stuff for several years so I have
had to make peace with protecting my systems and users from the worst of
the abuse, without being in a position to do much about the causes, other
than helping to keep our networks clean.

> Instead, isn't it the case that bind knows what domains it is authoritative
> for (or which ones it is supposed to be authoritative for) and bind is
> therefore in the ideal position to know which queries are abusive and which
> are not rather than wrapping kludgy filtering mechanisms around it?

Not always, sadly, because of misconfigured (lame) delegations. See the
earlier messages from me and Ondřej -

https://lists.isc.org/pipermail/bind-users/2021-April/104408.html

https://lists.isc.org/pipermail/bind-users/2021-April/104423.html

> If there is a resistance to having bind ignore the abusive queries
> altogether, could we at least have something like "errors-per-minute 1"
> which would reduce the problem by a factor of 60 compared with
> "errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)

There is probably something that might improve things, but I'm not sure
what it is. I think the minimum RRL rate of 1 per second might be intended
to work with resolver retry times. I'm wary of suppressing error responses
without thinking through the possible consequences.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Viking, North Utsire, South Utsire, Forties: Northerly or
northwesterly 3 to 5, becoming variable 3 or less later. Moderate
becoming slight. Showers. Good.