Re: forwarding zone setup from a BIND slave (without recursion?)

On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote: My situation is due to a security requirement.  We have DNS servers at our site running BIND that allow recursion, but I’ve been requested to set up some additional DNS servers for another project that is expected to **only**

Re: FW: Preventing a particular type of nameserver abuse

Of the small amount of name servers I run, each and every name server has had persistent attacks (I guess) in the form of "(sl): query (cache) 'sl/ANY/IN' denied". These attacks appear to be originating from legitimate ISP resolvers, but the majority of the attacks appear to be drones/malware

Re: FW: Preventing a particular type of nameserver abuse

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2021-04-13 at 22:42 +, Richard T.A. Neal wrote: > Yes, another individual & I were discussing this off-list today. We > wonder if those queries are from malware on infected hosts that are > trying to determine whether a given nameserver

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: forwarding zone setup from a BIND slave (without recursion?)

I have been banging my head against the wall regarding this very topic and then found this thread from last week. I’m also looking for a solution to this problem, and wondered if anyone may have some suggestions (including potential alternatives). My situation is due to a security

FW: Preventing a particular type of nameserver abuse

> In the particular case of the .sl denied queries, I don't think these are > forged queries from the attack victim. Something else is going on here. We > see queries from systems like these, almost exclusively consumer endpoints: [snipped] > It seems unlikely that someone is trying to attack

FW: Preventing a particular type of nameserver abuse

Julien Salort wrote: > Do you block specifically the dns queries in the firewall, or straight out > block the IP? I specifically block both UDP 53 and TCP 53, but that's essentially a full block because these servers are only running BIND, nothing else. > Reading this thread, I considered

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: No logging of failed queries

Real world configurations would have a catch all view after the more specific views. Add one. -- Mark Andrews > On 13 Apr 2021, at 22:41, Sachchidanand Upadhyay via bind-users > wrote: > >  > Hi, > >I am using bind's geoip feature, created one ACL to allow country IN. I am > not

No logging of failed queries

Hi, I am using bind's geoip feature, created one ACL to allow country IN. I am not getting logs of a failed query if the client IP is other than than country IN. Rest all is working fine, getting logs of successful queries. Below find the config details: BIND 9.16.13 (Stable Release)

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