Re: Millions of './ANY/IN' queries denied

2021-12-17 Thread Tony Finch 
Ondřej Surý  wrote:

> FTR RRL will not help on this case. There’s no difference between
> response with TC and response with REFUSED.

Yes and no :-) RRL uses a mixture of "slip" (i.e. truncation) and dropping
responses, so it will attenuate REFUSED spam. (The documentatin is not
very clear about when it drops, tho...)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Utsire: Variable 4 or less becoming westerly or northwesterly 3
or 4. Moderate. Drizzle. Good, occasionally poor.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Reindl Harald 




Am 16.12.21 um 15:29 schrieb Andrew P.:

Reindl Harald  writes:

Am 16.12.21 um 14:56 schrieb Andrew P.:

Reindl Harald  writes:
Am 16.12.21 um 14:22 schrieb Andrew P.:

You don't understand what kind of blacklist I want; I want to blacklist the 
domain name
being asked for, so I don't answer for it. I'm not looking to blacklist forged 
IP addresses
of requestors (since we all know criminals don't use their own identities; they 
use the
identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.


AGAIN: you don't gain anything by not responding on a UDP protocol
because the client can't distinct no response and packet loss


AGAIN, the criminal DDoS attacker who's creating these forged requests isn't 
looking for replies to themselves


but a legit client does while these attacks aren't successful at all


And you still haven't told me who would be a legitimate client making that 
request for the
root domain from my nameserver. Frankly, I can't think of _anyone_ who should 
be making
that request of my nameserver.


it's an example where you introduce more troubles than you solve 
problems when things go bad



they're looking to abuse some poor victim. And the victim can't make the 
attacker shut up


this attacker must be pretty dumb then because the ANY request makes
only sense if it get answered and the response is magnitudes larger then
the request


Not if the attacker has a huge bot-net to make the requests. He doesn't care 
how much of
the bots' network capacity is used up, since the attacker isn't paying for it. 


but it makes not sense playing that over your server instead blow the 
traffic directly out



And, based on the same
philosophy as spam, if they hit enough name servers, some of them will be 
insecure and provide the
full response

still pretty dumb not testing with a single ANY request if you would respond


I suspect they do know what they are doing, or they wouldn't be wasting their
time doing it


"know what they are doing" muste be also the reason why i have a ton of 
hardcoded spam-subjects with specific typos for over 10 years and even 
respond that i don't like the sobject on the MX


pretty sure the original idea was not hitting a specific real word but 
after all that years a famous typo is a 100% spam sign


they don't waste their time but blow out every sort of nonsense in the 
hope someone is hitted by it, your server is immune to what they try, no 
problem exists

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Andrew P . 
Reindl Harald  writes:
>Am 16.12.21 um 14:56 schrieb Andrew P.:
>> Reindl Harald  writes:
>> Am 16.12.21 um 14:22 schrieb Andrew P.:
 You don't understand what kind of blacklist I want; I want to blacklist 
 the domain name
 being asked for, so I don't answer for it. I'm not looking to blacklist 
 forged IP addresses
 of requestors (since we all know criminals don't use their own identities; 
 they use the
 identities of innocent bystanders).

 Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am 
 not a rootserver, and never will be.
>>>
>>> AGAIN: you don't gain anything by not responding on a UDP protocol
>>> because the client can't distinct no response and packet loss
>>
>> AGAIN, the criminal DDoS attacker who's creating these forged requests isn't 
>> looking for replies to themselves
>
>but a legit client does while these attacks aren't successful at all

And you still haven't told me who would be a legitimate client making that 
request for the
root domain from my nameserver. Frankly, I can't think of _anyone_ who should 
be making
that request of my nameserver.

Sure, it's a legitimate request to make of someone's first-hop ISP-provided 
caching-only nameserver, or of
a root nameserver. But not against _my_ nameserver. Or are you claiming there 
is DNS spoofing out
there identifying legitimate name servers as authoritative for domains they are 
not actually
authoritative for? Seems like a rather useless form of DNS spoofing, when such 
attackers could
more usefully (to them) direct victims to nameservers under the attacker's 
control.

>> they're looking to abuse some poor victim. And the victim can't make the 
>> attacker shut up
>
>this attacker must be pretty dumb then because the ANY request makes
>only sense if it get answered and the response is magnitudes larger then
>the request

Not if the attacker has a huge bot-net to make the requests. He doesn't care 
how much of
the bots' network capacity is used up, since the attacker isn't paying for it. 
And, based on the same
philosophy as spam, if they hit enough name servers, some of them will be 
insecure and provide the
full response, while even those who only send an error packet still need to 
have that packet
consumed at the victim.

>hence you need to send them to a server giving a full answer to the victim

No, not if you get enough error responses, it will still work. It just takes 
more.

>with just a error response he could send it's attack traffic directly
>given that the attacker needs the full bandwidth anyways and not using a
>valid DNS request, just blow out traffic to UDP 53

And why should the attacker give away the location of all his bots, when he
can get all these legitimate nameservers to take the blame?

>one couldn't care less about attackers which don't know what they are doing

I suspect they do know what they are doing, or they wouldn't be wasting their
time doing it.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Reindl Harald 




Am 16.12.21 um 14:56 schrieb Andrew P.:

Reindl Harald  writes:
Am 16.12.21 um 14:22 schrieb Andrew P.:

You don't understand what kind of blacklist I want; I want to blacklist the 
domain name
being asked for, so I don't answer for it. I'm not looking to blacklist forged 
IP addresses
of requestors (since we all know criminals don't use their own identities; they 
use the
identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.


AGAIN: you don't gain anything by not responding on a UDP protocol
because the client can't distinct no response and packet loss


AGAIN, the criminal DDoS attacker who's creating these forged requests isn't 
looking for replies to themselves


but a legit client does while these attacks aren't successful at all


they're looking to abuse some poor victim. And the victim can't make the 
attacker shut up


this attacker must be pretty dumb then because the ANY request makes 
only sense if it get answered and the response is magnitudes larger then 
the request


hence you need to send them to a server giving a full answer to the victim

with just a error response he could send it's attack traffic directly 
given that the attacker needs the full bandwidth anyways and not using a 
valid DNS request, just blow out traffic to UDP 53


one couldn't care less about attackers which don't know what they are doing
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Matus UHLAR - fantomas 

You don't understand what kind of blacklist I want; I want to blacklist the 
domain name
being asked for, so I don't answer for it. I'm not looking to blacklist forged 
IP addresses
of requestors (since we all know criminals don't use their own identities; they 
use the
identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.


these answers are minimal, so the problem is made as small as possible.


Reindl Harald  writes:
Am 16.12.21 um 14:22 schrieb Andrew P.:

AGAIN: you don't gain anything by not responding on a UDP protocol
because the client can't distinct no response and packet loss


On 16.12.21 13:56, Andrew P. wrote:

AGAIN, the criminal DDoS attacker who's creating these forged requests
isn't looking for replies to themselves; they're looking to abuse some
poor victim.  And the victim can't make the attacker shut up.


I use fail2ban to block these, so while a few packets always pass, the rest
gets blocked.


so you *increase* the load by retries on the client


No, the attacker is going to send their packets as often as they feel like
it regardless of whether I answer, and they won't know if the load on the
victim is sufficient to crush them (or if I am participating), since the
attacker isn't receiving the attack.  They won't speed up on me just
because I refuse to participate in their ugly little games because they
won't know I'm not playing along (at least until they decide to attack
_me_ instead of someone else).


don't get me wrong but you need to understand the implications of what
you are doing - for DOS attacks "Response Rate Limiting" was invented
and for non-DOS requests there isn't any valid reason to take action


Please tell me what non-DOS requests would be asking _my_ name server to
dump the root domain.  I'm not running a caching-only public nameserver
(such as an ISP might run for their customers), so _no_ _one_ should be
asking my nameserver for the entire root domain.  Even webcrawlers don't
need to harrass non-root-nameservers for root domain information.

Note I haven't done anything yet; I'm asking if there _is_ a way to do it
presently implemented in Bind.


none I know so far.
I'd be glad if someone told me there's better way and what it is.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Support bacteria - they're the only culture some people have.
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Andrew P . 
Reindl Harald  writes:
Am 16.12.21 um 14:22 schrieb Andrew P.:
>> You don't understand what kind of blacklist I want; I want to blacklist the 
>> domain name
>> being asked for, so I don't answer for it. I'm not looking to blacklist 
>> forged IP addresses
>> of requestors (since we all know criminals don't use their own identities; 
>> they use the
>> identities of innocent bystanders).
>>
>> Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am 
>> not a rootserver, and never will be.
>
>AGAIN: you don't gain anything by not responding on a UDP protocol
>because the client can't distinct no response and packet loss

AGAIN, the criminal DDoS attacker who's creating these forged requests isn't 
looking for replies to themselves; they're looking to abuse some poor victim. 
And the victim can't make the attacker shut up.

>so you *increase* the load by retries on the client

No, the attacker is going to send their packets as often as they feel like it 
regardless of whether I answer, and they won't know if the load on the victim 
is sufficient to crush them (or if I am participating), since the attacker 
isn't receiving the attack. They won't speed up on me just because I refuse to 
participate in their ugly little games because they won't know I'm not playing 
along (at least until they decide to attack _me_ instead of someone else).

>don't get me wrong but you need to understand the implications of what
>you are doing - for DOS attacks "Response Rate Limiting" was invented
>and for non-DOS requests there isn't any valid reason to take action

Please tell me what non-DOS requests would be asking _my_ name server to dump 
the root domain. I'm not running a caching-only public nameserver (such as an 
ISP might run for their customers), so _no_ _one_ should be asking my 
nameserver for the entire root domain. Even webcrawlers don't need to harrass 
non-root-nameservers for root domain information.

Note I haven't done anything yet; I'm asking if there _is_ a way to do it 
presently implemented in Bind.


___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Reindl Harald 



Am 16.12.21 um 14:35 schrieb Ondřej Surý:

FTR RRL will not help on this case. There’s no difference between response with 
TC and response with REFUSED.

It would make a difference only if there was NOERROR response with data.


that's true but in case it's a reflection attack it would help

in this case not responding won't help anyways because the request and 
the processing is done


violate the protocol won't gain much, the hammering requests still 
continue, the load continues and all you do is making DNS a gambling machine



On 16. 12. 2021, at 14:28, Reindl Harald  wrote:


Am 16.12.21 um 14:22 schrieb Andrew P.:
Sorry about forgetting to post the list. I hit Reply instead of Reply All. 
Annoying inconsistent list servers


blame your mail-client for not support "reply-list" buttons and "reply-all" is 
breaking this for me  :-)


You don't understand what kind of blacklist I want; I want to blacklist the 
domain name being asked for, so I don't answer for it. I'm not looking to 
blacklist forged IP addresses of requestors (since we all know criminals don't 
use their own identities; they use the identities of innocent bystanders).
Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.



AGAIN: you don't gain anything by not responding on a UDP protocol because the 
client can't distinct no response and packet loss

so you *increase* the load by retries on the client

don't get me wrong but you need to understand the implications of what you are doing - 
for DOS attacks "Response Rate Limiting" was invented and for non-DOS requests 
there isn't any valid reason to take action



From: bind-users  on behalf of Reindl Harald 

Sent: Thursday, December 16, 2021 8:14 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied

Am 16.12.21 um 14:04 schrieb Andrew P.:
So you're claiming that legitimate resolvers would still be pointing at the 
wrong IP address for a public DNS server after over 16 years?

besides that i don't know why you are answering off-list nowhere did i
say anything about 16 years
but it can take time
just because some IP is asking for a domain you don't host is for sure
not a justification for automated blacklisting - that will happen
regulary after domain-transfers for some time

And asking repeatedly and rapidly for the same illegal root domain name in 
synchronized bursts of 10 queries supposedly from 10 different IP addresses?

that's what "Response Rate Limiting" is for

I say that because I have held the particular static IPv4 address that my 
nameserver is running on for that long, and I have never run a root nameserver 
of any sort, or hosted domains for anyone but myself.

fine, that's *your* case - we host 800 domains and all the time some get
transferred to us and some get away

I agree with the concept of a blacklist

i don't because the IP is in most cases FORGED

how do I set up one on my copy of bind so I can refuse to answer those obvious 
DNS DDoS attacks? While still answering legitimate requests for the domains I 
do hosts, that is.

"Response Rate Limiting"
again: the IP you mostly see is FORGED and the victim not the attacker
and all you do is blacklisting the innocent victim which never did
anything bad
with automated blacklisting you expose yourself to a simple DOS attack -
when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i
take your domain offline for anybody on the planet using the google
resolvers
and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP
resolvers for endusers - game over, you blacklisted the world


From: bind-users  on behalf of Reindl Harald 

Sent: Wednesday, December 15, 2021 8:44 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct
it from packet loss leading to retries?

--

"Since no legitimate resolver would be asking a non authoritative server
for information" isn't true at all

years ago we moved a server to a different location and all sorts of ISP
resolvers did respond with old IPs months later, the dumbest one even
played lottery responding 50% old and 50% new IP

i found that out by random complaints because one domain had 60 count
subdomains and started to query all open rsolvers i was able to find
with script's - a tragedy

tha

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Ondřej Surý 
FTR RRL will not help on this case. There’s no difference between response with 
TC and response with REFUSED.

It would make a difference only if there was NOERROR response with data.

Ondřej 
--
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.

> On 16. 12. 2021, at 14:28, Reindl Harald  wrote:
> 
> 
> 
>> Am 16.12.21 um 14:22 schrieb Andrew P.:
>> Sorry about forgetting to post the list. I hit Reply instead of Reply All. 
>> Annoying inconsistent list servers
> 
> blame your mail-client for not support "reply-list" buttons and "reply-all" 
> is breaking this for me  :-)
> 
>> You don't understand what kind of blacklist I want; I want to blacklist the 
>> domain name being asked for, so I don't answer for it. I'm not looking to 
>> blacklist forged IP addresses of requestors (since we all know criminals 
>> don't use their own identities; they use the identities of innocent 
>> bystanders).
>> Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am 
>> not a rootserver, and never will be.
> 
> 
> AGAIN: you don't gain anything by not responding on a UDP protocol because 
> the client can't distinct no response and packet loss
> 
> so you *increase* the load by retries on the client
> 
> don't get me wrong but you need to understand the implications of what you 
> are doing - for DOS attacks "Response Rate Limiting" was invented and for 
> non-DOS requests there isn't any valid reason to take action
> 
>> ____
>> From: bind-users  on behalf of Reindl 
>> Harald 
>> Sent: Thursday, December 16, 2021 8:14 AM
>> To: bind-users@lists.isc.org
>> Subject: Re: Millions of './ANY/IN' queries denied
>>> Am 16.12.21 um 14:04 schrieb Andrew P.:
>>> So you're claiming that legitimate resolvers would still be pointing at the 
>>> wrong IP address for a public DNS server after over 16 years?
>> besides that i don't know why you are answering off-list nowhere did i
>> say anything about 16 years
>> but it can take time
>> just because some IP is asking for a domain you don't host is for sure
>> not a justification for automated blacklisting - that will happen
>> regulary after domain-transfers for some time
>>> And asking repeatedly and rapidly for the same illegal root domain name in 
>>> synchronized bursts of 10 queries supposedly from 10 different IP addresses?
>> that's what "Response Rate Limiting" is for
>>> I say that because I have held the particular static IPv4 address that my 
>>> nameserver is running on for that long, and I have never run a root 
>>> nameserver of any sort, or hosted domains for anyone but myself.
>> fine, that's *your* case - we host 800 domains and all the time some get
>> transferred to us and some get away
>>> I agree with the concept of a blacklist
>> i don't because the IP is in most cases FORGED
>>> how do I set up one on my copy of bind so I can refuse to answer those 
>>> obvious DNS DDoS attacks? While still answering legitimate requests for the 
>>> domains I do hosts, that is.
>> "Response Rate Limiting"
>> again: the IP you mostly see is FORGED and the victim not the attacker
>> and all you do is blacklisting the innocent victim which never did
>> anything bad
>> with automated blacklisting you expose yourself to a simple DOS attack -
>> when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i
>> take your domain offline for anybody on the planet using the google
>> resolvers
>> and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP
>> resolvers for endusers - game over, you blacklisted the world
>>> 
>>> From: bind-users  on behalf of Reindl 
>>> Harald 
>>> Sent: Wednesday, December 15, 2021 8:44 AM
>>> To: bind-users@lists.isc.org
>>> Subject: Re: Millions of './ANY/IN' queries denied
>>> 
>>> 
>>> 
>>> Am 15.12.21 um 14:33 schrieb Andrew P.:
>>>> So why isn't there a way to tell BIND not to respond to queries for which 
>>>> it clearly is not authoritative (such as these attack vectors)? Since no 
>>>> legitimate resolver would be asking a non-authoritative server for 
>>>> information, why should his (or my) public BIND server respond to these 
>>>> even with an error message?
>>> 
>>> because in case of UDP it would make things much wors

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Reindl Harald 



Am 16.12.21 um 14:22 schrieb Andrew P.:

Sorry about forgetting to post the list. I hit Reply instead of Reply All. 
Annoying inconsistent list servers


blame your mail-client for not support "reply-list" buttons and 
"reply-all" is breaking this for me  :-)



You don't understand what kind of blacklist I want; I want to blacklist the 
domain name being asked for, so I don't answer for it. I'm not looking to 
blacklist forged IP addresses of requestors (since we all know criminals don't 
use their own identities; they use the identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.



AGAIN: you don't gain anything by not responding on a UDP protocol 
because the client can't distinct no response and packet loss


so you *increase* the load by retries on the client

don't get me wrong but you need to understand the implications of what 
you are doing - for DOS attacks "Response Rate Limiting" was invented 
and for non-DOS requests there isn't any valid reason to take action




From: bind-users  on behalf of Reindl Harald 

Sent: Thursday, December 16, 2021 8:14 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 16.12.21 um 14:04 schrieb Andrew P.:

So you're claiming that legitimate resolvers would still be pointing at the 
wrong IP address for a public DNS server after over 16 years?


besides that i don't know why you are answering off-list nowhere did i
say anything about 16 years

but it can take time

just because some IP is asking for a domain you don't host is for sure
not a justification for automated blacklisting - that will happen
regulary after domain-transfers for some time


And asking repeatedly and rapidly for the same illegal root domain name in 
synchronized bursts of 10 queries supposedly from 10 different IP addresses?


that's what "Response Rate Limiting" is for


I say that because I have held the particular static IPv4 address that my 
nameserver is running on for that long, and I have never run a root nameserver 
of any sort, or hosted domains for anyone but myself.


fine, that's *your* case - we host 800 domains and all the time some get
transferred to us and some get away


I agree with the concept of a blacklist


i don't because the IP is in most cases FORGED


how do I set up one on my copy of bind so I can refuse to answer those obvious 
DNS DDoS attacks? While still answering legitimate requests for the domains I 
do hosts, that is.


"Response Rate Limiting"

again: the IP you mostly see is FORGED and the victim not the attacker
and all you do is blacklisting the innocent victim which never did
anything bad

with automated blacklisting you expose yourself to a simple DOS attack -
when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i
take your domain offline for anybody on the planet using the google
resolvers

and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP
resolvers for endusers - game over, you blacklisted the world



From: bind-users  on behalf of Reindl Harald 

Sent: Wednesday, December 15, 2021 8:44 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct
it from packet loss leading to retries?

--

"Since no legitimate resolver would be asking a non authoritative server
for information" isn't true at all

years ago we moved a server to a different location and all sorts of ISP
resolvers did respond with old IPs months later, the dumbest one even
played lottery responding 50% old and 50% new IP

i found that out by random complaints because one domain had 60 count
subdomains and started to query all open rsolvers i was able to find
with script's - a tragedy

that machine was sadly the primary NS for 800 domains and over the
months the old ip could have been ru-used for a new customer running a
nameserver for completly different domains

--

long story short: no sane service should supress replies completly
unless a explicit blacklist saying so is involved



From: bind-users  on behalf of Ondřej Surý 

Sent: Wednesday, December 15, 2021 7:18 AM
To: Danilo Godec
Cc: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied


Would I be doing a

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Andrew P . 
Sorry about forgetting to post the list. I hit Reply instead of Reply All. 
Annoying inconsistent list servers

You don't understand what kind of blacklist I want; I want to blacklist the 
domain name being asked for, so I don't answer for it. I'm not looking to 
blacklist forged IP addresses of requestors (since we all know criminals don't 
use their own identities; they use the identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.


From: bind-users  on behalf of Reindl Harald 

Sent: Thursday, December 16, 2021 8:14 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 16.12.21 um 14:04 schrieb Andrew P.:
> So you're claiming that legitimate resolvers would still be pointing at the 
> wrong IP address for a public DNS server after over 16 years?

besides that i don't know why you are answering off-list nowhere did i
say anything about 16 years

but it can take time

just because some IP is asking for a domain you don't host is for sure
not a justification for automated blacklisting - that will happen
regulary after domain-transfers for some time

> And asking repeatedly and rapidly for the same illegal root domain name in 
> synchronized bursts of 10 queries supposedly from 10 different IP addresses?

that's what "Response Rate Limiting" is for

> I say that because I have held the particular static IPv4 address that my 
> nameserver is running on for that long, and I have never run a root 
> nameserver of any sort, or hosted domains for anyone but myself.

fine, that's *your* case - we host 800 domains and all the time some get
transferred to us and some get away

> I agree with the concept of a blacklist

i don't because the IP is in most cases FORGED

> how do I set up one on my copy of bind so I can refuse to answer those 
> obvious DNS DDoS attacks? While still answering legitimate requests for the 
> domains I do hosts, that is.

"Response Rate Limiting"

again: the IP you mostly see is FORGED and the victim not the attacker
and all you do is blacklisting the innocent victim which never did
anything bad

with automated blacklisting you expose yourself to a simple DOS attack -
when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i
take your domain offline for anybody on the planet using the google
resolvers

and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP
resolvers for endusers - game over, you blacklisted the world

> 
> From: bind-users  on behalf of Reindl 
> Harald 
> Sent: Wednesday, December 15, 2021 8:44 AM
> To: bind-users@lists.isc.org
> Subject: Re: Millions of './ANY/IN' queries denied
>
>
>
> Am 15.12.21 um 14:33 schrieb Andrew P.:
>> So why isn't there a way to tell BIND not to respond to queries for which it 
>> clearly is not authoritative (such as these attack vectors)? Since no 
>> legitimate resolver would be asking a non-authoritative server for 
>> information, why should his (or my) public BIND server respond to these even 
>> with an error message?
>
> because in case of UDP it would make things much worser
>
> how do the client smell that you didn't respond by purpose and distinct
> it from packet loss leading to retries?
>
> --
>
> "Since no legitimate resolver would be asking a non authoritative server
> for information" isn't true at all
>
> years ago we moved a server to a different location and all sorts of ISP
> resolvers did respond with old IPs months later, the dumbest one even
> played lottery responding 50% old and 50% new IP
>
> i found that out by random complaints because one domain had 60 count
> subdomains and started to query all open rsolvers i was able to find
> with script's - a tragedy
>
> that machine was sadly the primary NS for 800 domains and over the
> months the old ip could have been ru-used for a new customer running a
> nameserver for completly different domains
>
> --
>
> long story short: no sane service should supress replies completly
> unless a explicit blacklist saying so is involved
>
>> ________
>> From: bind-users  on behalf of Ondřej Surý 
>> 
>> Sent: Wednesday, December 15, 2021 7:18 AM
>> To: Danilo Godec
>> Cc: bind-users@lists.isc.org
>> Subject: Re: Millions of './ANY/IN' queries denied
>>
>>> Would I be doing a bad thing by using fail2ban to block these IPs?
>>
>> That’s the question that only you can answer.  The IP addresses are
>> not attacker’s but victim’s and you would be punishing those networks
>> by blocking a

Re: Millions of './ANY/IN' queries denied

2021-12-16 Thread Reindl Harald 



Am 16.12.21 um 14:04 schrieb Andrew P.:
So you're claiming that legitimate resolvers would still be pointing at the wrong IP address for a public DNS server after over 16 years? 


besides that i don't know why you are answering off-list nowhere did i 
say anything about 16 years


but it can take time

just because some IP is asking for a domain you don't host is for sure 
not a justification for automated blacklisting - that will happen 
regulary after domain-transfers for some time


And asking repeatedly and rapidly for the same illegal root domain name in synchronized bursts of 10 queries supposedly from 10 different IP addresses? 


that's what "Response Rate Limiting" is for


I say that because I have held the particular static IPv4 address that my 
nameserver is running on for that long, and I have never run a root nameserver 
of any sort, or hosted domains for anyone but myself.


fine, that's *your* case - we host 800 domains and all the time some get 
transferred to us and some get away



I agree with the concept of a blacklist


i don't because the IP is in most cases FORGED


how do I set up one on my copy of bind so I can refuse to answer those obvious 
DNS DDoS attacks? While still answering legitimate requests for the domains I 
do hosts, that is.


"Response Rate Limiting"

again: the IP you mostly see is FORGED and the victim not the attacker 
and all you do is blacklisting the innocent victim which never did 
anything bad


with automated blacklisting you expose yourself to a simple DOS attack - 
when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i 
take your domain offline for anybody on the planet using the google 
resolvers


and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP 
resolvers for endusers - game over, you blacklisted the world




From: bind-users  on behalf of Reindl Harald 

Sent: Wednesday, December 15, 2021 8:44 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct
it from packet loss leading to retries?

--

"Since no legitimate resolver would be asking a non authoritative server
for information" isn't true at all

years ago we moved a server to a different location and all sorts of ISP
resolvers did respond with old IPs months later, the dumbest one even
played lottery responding 50% old and 50% new IP

i found that out by random complaints because one domain had 60 count
subdomains and started to query all open rsolvers i was able to find
with script's - a tragedy

that machine was sadly the primary NS for 800 domains and over the
months the old ip could have been ru-used for a new customer running a
nameserver for completly different domains

--

long story short: no sane service should supress replies completly
unless a explicit blacklist saying so is involved



From: bind-users  on behalf of Ondřej Surý 

Sent: Wednesday, December 15, 2021 7:18 AM
To: Danilo Godec
Cc: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied


Would I be doing a bad thing by using fail2ban to block these IPs?


That’s the question that only you can answer.  The IP addresses are
not attacker’s but victim’s and you would be punishing those networks
by blocking access from them to your network.

Do you absolutely know that these IP addresses doesn’t need access
to your DNS?  If yes, then go ahead.

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-15 Thread Grant Taylor via bind-users 

On 12/15/21 4:51 AM, Danilo Godec via bind-users wrote:

Hello,


Hi,

I'm noticing some unusual activity where 48 external IPs generated over 
2M queries that have all been denied (just today):


15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0 
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied


I see this type of thing on occasion.

I'm guessing this is some sort of an reflection attack attempt, but I 
don't quite understand if these are the perpetrators or victims?


I'd bet a reasonable lunch that these are spoofed addresses of intended 
victims.



Would I be doing a bad thing by using fail2ban to block these IPs?


As others have indicated, there are likely side effects to blocking the 
IPs, be it with fail2ban or otherwise.


I'd suggest investigating response rate limiting.  It seems like it can 
fairly gracefully help ensure that your server doesn't participate in a 
DoS reply attack while still playing fairly well with otherwise well 
behaving clients.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-15 Thread Reindl Harald 




Am 15.12.21 um 15:01 schrieb John Kristoff:

Would I be doing a bad thing by using fail2ban to block these IPs?


This might be dangerous.  If someone spoofs a well formed UDP query
that does what the above does and you block it, what if the spoofed
source is something you don't want blocked?  This doesn't happen often,
but I've seen it happen and people have gotten badly burned by it


it's even an attack surface

nothing easier than forge udp queries to trigger fail2ban for whatever 
IP the attacker wants


feed it with ISP and google resolvers to take your domains down for a 
large part of the world


it's called "self-DOS" - "denial of service" don't need much resources, 
it's enough when you are taking you down at your own

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-15 Thread John Kristoff 
On Wed, 15 Dec 2021 12:51:19 +0100
Danilo Godec via bind-users  wrote:

[...]
> 15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0
> 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied

This can be common noise you'll see if any external source can get
queries to your server.  It looks like you are denying the queries,
which are probably rd=1 queries.  That is good.  If your server is
auth-only, then it is probably easiest and least harmful.  These are
most likely clients looking for open resolvers.  For example, the
address below has shown up in the signals data doing just that since at
least early November with a project associated with the domain of my
email.

> I'm guessing this is some sort of an reflection attack attempt, but I
> don't quite understand if these are the perpetrators or victims?

If you're refusing the queries, most likely they are Internet surveyors
and scanners.  Some of that may be for reasonable cataloging and
alerting services, other times it is by miscreants looking for servers
to use for reflection attacks.

> Would I be doing a bad thing by using fail2ban to block these IPs?

This might be dangerous.  If someone spoofs a well formed UDP query
that does what the above does and you block it, what if the spoofed
source is something you don't want blocked?  This doesn't happen often,
but I've seen it happen and people have gotten badly burned by it.

John
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-15 Thread Reindl Harald 



Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct 
it from packet loss leading to retries?


--

"Since no legitimate resolver would be asking a non authoritative server 
for information" isn't true at all


years ago we moved a server to a different location and all sorts of ISP 
resolvers did respond with old IPs months later, the dumbest one even 
played lottery responding 50% old and 50% new IP


i found that out by random complaints because one domain had 60 count 
subdomains and started to query all open rsolvers i was able to find 
with script's - a tragedy


that machine was sadly the primary NS for 800 domains and over the 
months the old ip could have been ru-used for a new customer running a 
nameserver for completly different domains


--

long story short: no sane service should supress replies completly 
unless a explicit blacklist saying so is involved




From: bind-users  on behalf of Ondřej Surý 

Sent: Wednesday, December 15, 2021 7:18 AM
To: Danilo Godec
Cc: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied


Would I be doing a bad thing by using fail2ban to block these IPs?


That’s the question that only you can answer.  The IP addresses are
not attacker’s but victim’s and you would be punishing those networks
by blocking access from them to your network.

Do you absolutely know that these IP addresses doesn’t need access
to your DNS?  If yes, then go ahead.

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-15 Thread Ondřej Surý 
Not responding would make the client susceptible to spoofing,
and named have no way of deciding whether the other side
is legitimate or not.  The out-of-configure-zone question could
come from misconfiguration somewhere and not be malicious
at all.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 15. 12. 2021, at 14:33, Andrew P.  wrote:
> 
> So why isn't there a way to tell BIND not to respond to queries for which it 
> clearly is not authoritative (such as these attack vectors)? Since no 
> legitimate resolver would be asking a non-authoritative server for 
> information, why should his (or my) public BIND server respond to these even 
> with an error message?
> 
> 
> 
> 
> From: bind-users  on behalf of Ondřej Surý 
> 
> Sent: Wednesday, December 15, 2021 7:18 AM
> To: Danilo Godec
> Cc: bind-users@lists.isc.org
> Subject: Re: Millions of './ANY/IN' queries denied
> 
>> Would I be doing a bad thing by using fail2ban to block these IPs?
> 
> That’s the question that only you can answer.  The IP addresses are
> not attacker’s but victim’s and you would be punishing those networks
> by blocking access from them to your network.
> 
> Do you absolutely know that these IP addresses doesn’t need access
> to your DNS?  If yes, then go ahead.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
>> On 15. 12. 2021, at 12:51, Danilo Godec via bind-users 
>>  wrote:
>> 
>> Hello,
>> 
>> 
>> I'm noticing some unusual activity where 48 external IPs generated over
>> 2M queries that have all been denied (just today):
>> 
>> 15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0
>> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
>> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
>> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
>> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
>> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
>> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
>> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
>> 15-Dec-2021 00:01:42.123 security: info: client @0x7f9618019e20
>> 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
>> 15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0
>> 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
>> 
>> 
>> I'm guessing this is some sort of an reflection attack attempt, but I
>> don't quite understand if these are the perpetrators or victims?
>> 
>> Would I be doing a bad thing by using fail2ban to block these IPs?
>> 
>> 
>>Regards,
>> 
>> Danilo
>> 
>> 
>> ___
>> 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@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-15 Thread Andrew P . 
So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?




From: bind-users  on behalf of Ondřej Surý 

Sent: Wednesday, December 15, 2021 7:18 AM
To: Danilo Godec
Cc: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied

> Would I be doing a bad thing by using fail2ban to block these IPs?

That’s the question that only you can answer.  The IP addresses are
not attacker’s but victim’s and you would be punishing those networks
by blocking access from them to your network.

Do you absolutely know that these IP addresses doesn’t need access
to your DNS?  If yes, then go ahead.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 15. 12. 2021, at 12:51, Danilo Godec via bind-users 
>  wrote:
>
> Hello,
>
>
> I'm noticing some unusual activity where 48 external IPs generated over
> 2M queries that have all been denied (just today):
>
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.123 security: info: client @0x7f9618019e20
> 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0
> 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
>
>
> I'm guessing this is some sort of an reflection attack attempt, but I
> don't quite understand if these are the perpetrators or victims?
>
> Would I be doing a bad thing by using fail2ban to block these IPs?
>
>
> Regards,
>
>  Danilo
>
>
> ___
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Millions of './ANY/IN' queries denied

2021-12-15 Thread Ondřej Surý 
> Would I be doing a bad thing by using fail2ban to block these IPs?

That’s the question that only you can answer.  The IP addresses are
not attacker’s but victim’s and you would be punishing those networks
by blocking access from them to your network.

Do you absolutely know that these IP addresses doesn’t need access
to your DNS?  If yes, then go ahead.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 15. 12. 2021, at 12:51, Danilo Godec via bind-users 
>  wrote:
> 
> Hello,
> 
> 
> I'm noticing some unusual activity where 48 external IPs generated over
> 2M queries that have all been denied (just today):
> 
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
> 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.123 security: info: client @0x7f9618019e20
> 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
> 15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0
> 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
> 
> 
> I'm guessing this is some sort of an reflection attack attempt, but I
> don't quite understand if these are the perpetrators or victims?
> 
> Would I be doing a bad thing by using fail2ban to block these IPs?
> 
> 
> Regards,
> 
>  Danilo
> 
> 
> ___
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Millions of './ANY/IN' queries denied

2021-12-15 Thread Danilo Godec via bind-users 
Hello,


I'm noticing some unusual activity where 48 external IPs generated over
2M queries that have all been denied (just today):

15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.123 security: info: client @0x7f9618019e20
45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0
45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied


I'm guessing this is some sort of an reflection attack attempt, but I
don't quite understand if these are the perpetrators or victims?

Would I be doing a bad thing by using fail2ban to block these IPs?


    Regards,

 Danilo


___
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users