Re: Preventing a particular type of nameserver abuse

I started this thread back in April in response to high levels of abuse of my nameserver. A short summary of the discussion which resulted is that bind does not provide any way of preventing abuse I was experiencing. (The abuse was clearly designed to get past any use of rate-limiting to mitigate

Re: Preventing a particular type of nameserver abuse

> On 15 Apr 2021, at 11:35, @lbutlr wrote: > > On 14 Apr 2021, at 01:48, Anand Buddhdev wrote: >> This is a short-sighted opinion. If just one authoritative server sends >> out REFUSED responses towards an innocent, it won't matter. But if 1000 >> authoritative servers all send out REFUSED

Re: Preventing a particular type of nameserver abuse

On 14 Apr 2021, at 01:48, Anand Buddhdev wrote: > This is a short-sighted opinion. If just one authoritative server sends > out REFUSED responses towards an innocent, it won't matter. But if 1000 > authoritative servers all send out REFUSED responses towards an innocent > IP address, their

Re: Preventing a particular type of nameserver abuse

Tony Finch wrote: >Peter Coghlan wrote: >> 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

Re: Preventing a particular type of nameserver abuse

Peter Coghlan 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

Re: Preventing a particular type of nameserver abuse

Thanks Sten > On 14 Apr 2021, at 19.47, Carl Byington via bind-users > wrote: > > Signed PGP part > On Wed, 2021-04-14 at 12:58 -0400, Paul Kosinski via bind-users wrote: > > Interesting, although we host different domains, in and from different > > geographic areas, we got the same queries

Re: Preventing a particular type of nameserver abuse

Tony Finch wrote: > Peter Coghlan 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

Re: Preventing a particular type of nameserver abuse

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2021-04-14 at 12:58 -0400, Paul Kosinski via bind-users wrote: > Interesting, although we host different domains, in and from different > geographic areas, we got the same queries as yours on the same day, > with some at about the same time

Re: Preventing a particular type of nameserver abuse

Interesting, although we host different domains, in and from different geographic areas, we got the same queries as yours on the same day, with some at about the same time (we're EDT). 13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied

Re: Preventing a particular type of nameserver abuse

sth...@nethelp.no wrote: > > Agree that you should be able to ignore them. But as a practical matter, > ignoring them *may* result in the question being asked again and again, > while REFUSED *may* stop the client from asking more. REFUSED leads to retries too: if the client is a legit resolver

Re: Preventing a particular type of nameserver abuse

> I'm not talking of DNS *resolvers* here. I'm talking of authoritative > servers. If my authoritative server is authoritative for zones A, B and > C, then I should only get queries for those zones from legitimate > resolvers and clients. Queries for any other zones should *not* be > coming to my

Re: Preventing a particular type of nameserver abuse

Anand, I understand that this topic is something you feel passionate about, but alas, it’s more complicated than just dropping REFUSED answers. Any lame delegation would be then susceptible to cache poisoning. Also it would be a protocol violation. A small well-maintained authoritative server

Re: Preventing a particular type of nameserver abuse

On 14/04/2021 00:29, @lbutlr wrote: >> A legitimate client, following a normal chain of referrals, has *no* >> reason to query a server for zones it is not authoritative for. > > Well, that's not really true. A mobile user might have their device > configured to always check their corporate DNS

Re: Preventing a particular type of nameserver abuse

Interesting observation. I just did lookups on 4 recent (< 24 hrs ago) 'sl/ANY/IN' queries logged by our BIND and got: 2 Comcast cable IPs (hsd1.tx.comcast.net and hsd1.ma.comcast.net) 1 OVH Hosting IP (Montreal) 1 Afranet IP (Tehran!) The whois info for the OVH IP contains the line:

Re: Preventing a particular type of nameserver abuse

On 13 Apr 2021, at 04:02, Anand Buddhdev wrote: > A legitimate client, following a normal chain of referrals, has *no* > reason to query a server for zones it is not authoritative for. Well, that's not really true. A mobile user might have their device configured to always check their corporate

Re: Preventing a particular type of nameserver abuse

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2021-04-13 at 22:32 +0200, Julien Salort wrote: > Reading this thread, I considered simply enabling the fail2ban > named-refused jail, but they advise against it because it would end > up > blocking the victim rather than the attacker. In

Re: Preventing a particular type of nameserver abuse

Le 13/04/2021 à 00:55, Richard T.A. Neal a écrit : That's exactly what I do - I have some code that's watching for a frequent occurrence of these sorts of queries and then adds a firewall rule for a predetermined amount of time to simply drop the incoming packets at the firewall - this

Re: Preventing a particular type of nameserver abuse

Anand Buddhdev wrote: > > A legitimate client, following a normal chain of referrals, has *no* > reason to query a server for zones it is not authoritative for. That's true for cases like .sl and other domains whose delegations are set up correctly, but if a server is accidentally lame then it's

Re: Preventing a particular type of nameserver abuse

Peter Coghlan 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

Re: Preventing a particular type of nameserver abuse

Hi Ondrej, and others, A legitimate client, following a normal chain of referrals, has *no* reason to query a server for zones it is not authoritative for. Most of the time, such a query would only arrive at a name server from a naughty client. And then, replying with any response, even REFUSED,

Re: Preventing a particular type of nameserver abuse

> On 13 Apr 2021, at 11:31, Julien Salort wrote: > > Is there really a usefulness to reply with code 5, instead of silently > ignoring the request? Yes, we do it. imagine a customer who uses to connect from different locations (hence different ISPs) and for whatever reason keeps a static

Re: Preventing a particular type of nameserver abuse

Yes, the legitimate client would be susceptible to spoofing. No answer means larger time windows to guess the port+msgid combination. -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

Re: Preventing a particular type of nameserver abuse

Le 13/04/2021 à 07:12, Ondřej Surý a écrit : BIND 9.11 has minimal-any option that’s helpful to reduce the attack impact: https://www.isc.org/blogs/bind-release-911/ RRL should also help to limit the responses: https://kb.isc.org/docs/aa-01000

Re: Preventing a particular type of nameserver abuse

BIND 9.11 has minimal-any option that’s helpful to reduce the attack impact: https://www.isc.org/blogs/bind-release-911/ RRL should also help to limit the responses: https://kb.isc.org/docs/aa-01000 Usually the source IP is spoofed, so blocking it might be causing collateral damage in case the

Re: Preventing a particular type of nameserver abuse

We also get *lots* of suspicious queries of the same kind, from various privileged and unprivileged ports, which I'm pretty sure are DDoS attempts. For example: 12-Apr-2021 23:44:17.767 security: info: client 107.213.131.17#80 (sl): query (cache) 'sl/ANY/IN' denied 12-Apr-2021 23:44:19.477

RE: Preventing a particular type of nameserver abuse

Grant Taylor wrote: > You might be able to apply the same methodology to filter unwanted inbound > queries to completely avoid sending the reply code at all. That's exactly what I do - I have some code that's watching for a frequent occurrence of these sorts of queries and then adds a firewall

Re: Preventing a particular type of nameserver abuse

[ 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

Re: Preventing a particular type of nameserver abuse

On 4/12/21 1:41 PM, Peter Coghlan wrote: 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