Bind stats - denied queries?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Bind stats - denied queries?

Karl Pielorz

Hi,

We've been seeing a huge increase in 'denied queries' against a couple of
Bind servers we look after (Bind 9.16.9) - these are currently logged as:

"
Nov 30 00:00:00 client @0xXXXXX X.X.X.X#48536 (.): query (cache) './ANY/IN'
denied
"

This appears like it might be someone trying (unsuccessfully) to use us as
an amplifier / reflector.

We've got Bind's statistics file setup - but I can't see there's any entry
for these "denied" queries? - As we'd really like to monitor this.

If anyone knows what stat these turn up in the statistics file (if at all?)

Thanks,

-Karl
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: Bind stats - denied queries?

Marc Roos
 

Are newer version of bind still logging like this


Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
3.9.41.0/24
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
3.9.41.0/24

I already reported, that it is not to smart to log 3.9.41.0/24, better
could be logged 3.9.41.100/24 so you know the offending ip.




-----Original Message-----
From: Karl Pielorz [mailto:[hidden email]]
Sent: Monday, November 30, 2020 11:08 AM
To: [hidden email]
Subject: Bind stats - denied queries?


Hi,

We've been seeing a huge increase in 'denied queries' against a couple
of Bind servers we look after (Bind 9.16.9) - these are currently logged
as:

"
Nov 30 00:00:00 client @0xXXXXX X.X.X.X#48536 (.): query (cache)
'./ANY/IN'
denied
"

This appears like it might be someone trying (unsuccessfully) to use us
as an amplifier / reflector.

We've got Bind's statistics file setup - but I can't see there's any
entry for these "denied" queries? - As we'd really like to monitor this.

If anyone knows what stat these turn up in the statistics file (if at
all?)

Thanks,

-Karl
_______________________________________________
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Lyle Giese
Be careful 'rejecting' these outright.  These queries are UDP
traffic(not TCP) and the source address is easily forged.  RRL is the
correct way to limit these.

Lyle Giese

LCR Computer Services, Inc.

On 11/30/20 4:12 AM, Marc Roos wrote:

>  
>
> Are newer version of bind still logging like this
>
>
> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
> 3.9.41.0/24
> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
> 35.177.154.0/24
> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
> 35.177.154.0/24
> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
> 3.9.41.0/24
>
> I already reported, that it is not to smart to log 3.9.41.0/24, better
> could be logged 3.9.41.100/24 so you know the offending ip.
>
>
>
>
> -----Original Message-----
> From: Karl Pielorz [mailto:[hidden email]]
> Sent: Monday, November 30, 2020 11:08 AM
> To: [hidden email]
> Subject: Bind stats - denied queries?
>
>
> Hi,
>
> We've been seeing a huge increase in 'denied queries' against a couple
> of Bind servers we look after (Bind 9.16.9) - these are currently logged
> as:
>
> "
> Nov 30 00:00:00 client @0xXXXXX X.X.X.X#48536 (.): query (cache)
> './ANY/IN'
> denied
> "
>
> This appears like it might be someone trying (unsuccessfully) to use us
> as an amplifier / reflector.
>
> We've got Bind's statistics file setup - but I can't see there's any
> entry for these "denied" queries? - As we'd really like to monitor this.
>
> If anyone knows what stat these turn up in the statistics file (if at
> all?)
>
> Thanks,
>
> -Karl
> _______________________________________________
> 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Reindl Harald
In reply to this post by Marc Roos


Am 30.11.20 um 11:12 schrieb Marc Roos:

> Are newer version of bind still logging like this
>
> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
> 3.9.41.0/24
> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
> 35.177.154.0/24
> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
> 35.177.154.0/24
> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
> 3.9.41.0/24
>
> I already reported, that it is not to smart to log 3.9.41.0/24, better
> could be logged 3.9.41.100/24 so you know the offending ip

there is nothing like an "offending ip" in case of dns-amplification
which is usually what happens in context of RRL

it's the forged destination of the attack you see and nothing else
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: Bind stats - denied queries?

Marc Roos
 

Regardless if the source is spoofed or not, one should log it.
Especially with this amazon abuse cloud, how can you report abuse, they
want to have an ip address to be able to investigate if something
originated from their network.

If you log 0/24 you might as well log no range at all.





Am 30.11.20 um 11:12 schrieb Marc Roos:

> Are newer version of bind still logging like this
>
> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
> 3.9.41.0/24
> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
> 35.177.154.0/24
> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
> 35.177.154.0/24
> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
> 3.9.41.0/24
>
> I already reported, that it is not to smart to log 3.9.41.0/24, better

> could be logged 3.9.41.100/24 so you know the offending ip

there is nothing like an "offending ip" in case of dns-amplification
which is usually what happens in context of RRL

it's the forged destination of the attack you see and nothing else


_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Reindl Harald
the source of dns amplification is *always* spoofed because it's by
design the IP of the victim and not the offender

the goal of dns amplification is to flood the connection of the victim
until no regular traffic is possible

the same /24 is sharing the same line and so it doesn't make sense in
that context talk about single ip's at all

it also doesn't make sense to write abuse reports for such things
because additionally to the technical packet flood you also flood human
ressources with nosense there

they aren't the offender, they can't do anything about your issue
because the are *the victim*

you are one of thousands or even millions of hosts the attacker is
trying to get responses from to the victim

please try to understand
https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/ 
and RRL is only useful for that type of attack, everything else don't
matter for a DNS server and more important you can't distinct it anyways

Am 30.11.20 um 18:23 schrieb Marc Roos:

> Regardless if the source is spoofed or not, one should log it.
> Especially with this amazon abuse cloud, how can you report abuse, they
> want to have an ip address to be able to investigate if something
> originated from their network.
>
> If you log 0/24 you might as well log no range at all.
>
> Am 30.11.20 um 11:12 schrieb Marc Roos:
>> Are newer version of bind still logging like this
>>
>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
>> 3.9.41.0/24
>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
>> 35.177.154.0/24
>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
>> 35.177.154.0/24
>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
>> 3.9.41.0/24
>>
>> I already reported, that it is not to smart to log 3.9.41.0/24, better
>
>> could be logged 3.9.41.100/24 so you know the offending ip
>
> there is nothing like an "offending ip" in case of dns-amplification
> which is usually what happens in context of RRL
>
> it's the forged destination of the attack you see and nothing else

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: Bind stats - denied queries?

Marc Roos
 
You assume incorrectly that every such log entry is from spoofed
traffic.

This is about correct logging. Even if it is spoofed, logging the
correct spoofed address is better than logging a range (that include
ip's that are maybe not even participating)

There is only, but only one advantage I can think of, and that is
grouping to one log entry.




-----Original Message-----
Subject: Re: Bind stats - denied queries?

the source of dns amplification is *always* spoofed because it's by
design the IP of the victim and not the offender

the goal of dns amplification is to flood the connection of the victim
until no regular traffic is possible

the same /24 is sharing the same line and so it doesn't make sense in
that context talk about single ip's at all

it also doesn't make sense to write abuse reports for such things
because additionally to the technical packet flood you also flood human
ressources with nosense there

they aren't the offender, they can't do anything about your issue
because the are *the victim*

you are one of thousands or even millions of hosts the attacker is
trying to get responses from to the victim

please try to understand
https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/
and RRL is only useful for that type of attack, everything else don't
matter for a DNS server and more important you can't distinct it anyways

Am 30.11.20 um 18:23 schrieb Marc Roos:
> Regardless if the source is spoofed or not, one should log it.
> Especially with this amazon abuse cloud, how can you report abuse,
> they want to have an ip address to be able to investigate if something

> originated from their network.
>
> If you log 0/24 you might as well log no range at all.
>
> Am 30.11.20 um 11:12 schrieb Marc Roos:
>> Are newer version of bind still logging like this
>>
>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
>> to
>> 3.9.41.0/24
>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
>> to
>> 35.177.154.0/24
>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
>> to
>> 35.177.154.0/24
>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
>> to
>> 3.9.41.0/24
>>
>> I already reported, that it is not to smart to log 3.9.41.0/24,
>> better
>
>> could be logged 3.9.41.100/24 so you know the offending ip
>
> there is nothing like an "offending ip" in case of dns-amplification
> which is usually what happens in context of RRL
>
> it's the forged destination of the attack you see and nothing else



_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Reindl Harald


Am 30.11.20 um 20:01 schrieb Marc Roos
> You assume incorrectly that every such log entry is from spoofed
> traffic.

every relevant one, yes

> This is about correct logging. Even if it is spoofed, logging the
> correct spoofed address is better than logging a range (that include
> ip's that are maybe not even participating)

there is nothing like "not even participating" in a /24 in case of
reflection

> There is only, but only one advantage I can think of, and that is
> grouping to one log entry.

no, it logs what it does: responses to that /24 are rate-limited because
otherwise you won't be able to reduce the impact

you still refuse to understand wo is attacker and who is victim! *you
are* the attacker sending responses larger then the request to the
forged sources

you are *not* target, you are part of the attack und you have no way to
do anything against that on a UDP protocol except rate-limit your
responses because you have no way to find out the real source

> -----Original Message-----
> Subject: Re: Bind stats - denied queries?
>
> the source of dns amplification is *always* spoofed because it's by
> design the IP of the victim and not the offender
>
> the goal of dns amplification is to flood the connection of the victim
> until no regular traffic is possible
>
> the same /24 is sharing the same line and so it doesn't make sense in
> that context talk about single ip's at all
>
> it also doesn't make sense to write abuse reports for such things
> because additionally to the technical packet flood you also flood human
> ressources with nosense there
>
> they aren't the offender, they can't do anything about your issue
> because the are *the victim*
>
> you are one of thousands or even millions of hosts the attacker is
> trying to get responses from to the victim
>
> please try to understand
> https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/
> and RRL is only useful for that type of attack, everything else don't
> matter for a DNS server and more important you can't distinct it anyways
>
> Am 30.11.20 um 18:23 schrieb Marc Roos:
>> Regardless if the source is spoofed or not, one should log it.
>> Especially with this amazon abuse cloud, how can you report abuse,
>> they want to have an ip address to be able to investigate if something
>
>> originated from their network.
>>
>> If you log 0/24 you might as well log no range at all.
>>
>> Am 30.11.20 um 11:12 schrieb Marc Roos:
>>> Are newer version of bind still logging like this
>>>
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
>>> to
>>> 3.9.41.0/24
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
>>> to
>>> 3.9.41.0/24
>>>
>>> I already reported, that it is not to smart to log 3.9.41.0/24,
>>> better
>>
>>> could be logged 3.9.41.100/24 so you know the offending ip
>>
>> there is nothing like an "offending ip" in case of dns-amplification
>> which is usually what happens in context of RRL
>>
>> it's the forged destination of the attack you see and nothing else
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: Bind stats - denied queries?

Marc Roos

Every entry is relevant, because that is how you configured it to be. Do
you even know that this limit is configured in your config at
'rate-limit {};'? It logs everything that exceeds this limit. (<- notice
the . period)

So you can dump queries from a host 192.168.a.b, exceeding this limit
and your log entry is incorrect! Because it will have 192.168.a.0 and
not 192.168.a.b. Let me put it like this, logging 192.168.a.0 is just
plain stupid. Your log an incorrect event! The idea about logs, is that
they are correct.


-----Original Message-----
Sent: Monday, November 30, 2020 10:45 PM
To: Marc Roos; bind-users; kpielorz.lst
Subject: Re: Bind stats - denied queries?



Am 30.11.20 um 20:01 schrieb Marc Roos
> You assume incorrectly that every such log entry is from spoofed
> traffic.

every relevant one, yes

> This is about correct logging. Even if it is spoofed, logging the
> correct spoofed address is better than logging a range (that include
> ip's that are maybe not even participating)

there is nothing like "not even participating" in a /24 in case of
reflection

> There is only, but only one advantage I can think of, and that is
> grouping to one log entry.

no, it logs what it does: responses to that /24 are rate-limited because
otherwise you won't be able to reduce the impact

you still refuse to understand wo is attacker and who is victim! *you
are* the attacker sending responses larger then the request to the
forged sources

you are *not* target, you are part of the attack und you have no way to
do anything against that on a UDP protocol except rate-limit your
responses because you have no way to find out the real source

> -----Original Message-----
> Subject: Re: Bind stats - denied queries?
>
> the source of dns amplification is *always* spoofed because it's by
> design the IP of the victim and not the offender
>
> the goal of dns amplification is to flood the connection of the victim

> until no regular traffic is possible
>
> the same /24 is sharing the same line and so it doesn't make sense in
> that context talk about single ip's at all
>
> it also doesn't make sense to write abuse reports for such things
> because additionally to the technical packet flood you also flood
> human ressources with nosense there
>
> they aren't the offender, they can't do anything about your issue
> because the are *the victim*
>
> you are one of thousands or even millions of hosts the attacker is
> trying to get responses from to the victim
>
> please try to understand
> https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack
> / and RRL is only useful for that type of attack, everything else
> don't matter for a DNS server and more important you can't distinct it

> anyways
>
> Am 30.11.20 um 18:23 schrieb Marc Roos:
>> Regardless if the source is spoofed or not, one should log it.
>> Especially with this amazon abuse cloud, how can you report abuse,
>> they want to have an ip address to be able to investigate if
>> something
>
>> originated from their network.
>>
>> If you log 0/24 you might as well log no range at all.
>>
>> Am 30.11.20 um 11:12 schrieb Marc Roos:
>>> Are newer version of bind still logging like this
>>>
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
>>> to
>>> 3.9.41.0/24
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
>>> to
>>> 3.9.41.0/24
>>>
>>> I already reported, that it is not to smart to log 3.9.41.0/24,
>>> better
>>
>>> could be logged 3.9.41.100/24 so you know the offending ip
>>
>> there is nothing like an "offending ip" in case of dns-amplification
>> which is usually what happens in context of RRL
>>
>> it's the forged destination of the attack you see and nothing else


_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Karl Pielorz
In reply to this post by Lyle Giese


--On 30 November 2020 at 08:53:27 -0600 Lyle Giese <[hidden email]>
wrote:

> Be careful 'rejecting' these outright.  These queries are UDP
> traffic(not TCP) and the source address is easily forged.  RRL is the
> correct way to limit these.

So, as the original person that posted the question :)

My question still stands (I'd never presumed this was valid traffic) - what
I'm trying to find out if buried within the trove of stats produced by
'rndc stats' is there any counter, that counts:

"
 Nov 30 00:00:00 client @0xXXXXX X.X.X.X#48536 (.): query (cache)
'./ANY/IN' denied
"

i.e. 'Denied' queries. I can see stats for pretty much everything, e.g.
Queried, notified, all the different record types - there's a block in the
stats file of:

"
              749045 queries resulted in nxrrset
                  45 queries resulted in SERVFAIL
               15291 queries resulted in NXDOMAIN
"

But I was expecting to see something like:

               34343 queries resulted in DENIED

But I can't see it - or anything that's really applicable?

And, as everyone else is talking about RRL - is there a stat that would
appear for that, e.g.

              234829 queries resulted in RATELIMIT

Or similar?

Currently we're just trying to easily graph the DENIED queries to see how
much of the total traffic it is.

-Karl

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Chuck Aurora
On 2020-12-01 04:43, Karl Pielorz wrote:

> So, as the original person that posted the question :)
>
> My question still stands (I'd never presumed this was valid traffic) -
> what I'm trying to find out if buried within the trove of stats
> produced by 'rndc stats' is there any counter, that counts:
>
> "
> Nov 30 00:00:00 client @0xXXXXX X.X.X.X#48536 (.): query (cache)
> './ANY/IN' denied
> "

I think you are asking the wrong question and looking at the wrong
feature.  You can probably do what you're after with
statistics-channels.

https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/html/reference.html#statistics-channels-statement-grammar
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Karl Pielorz


--On 1 December 2020 at 10:14:50 -0600 Chuck Aurora <[hidden email]> wrote:

> On 2020-12-01 04:43, Karl Pielorz wrote:
>> So, as the original person that posted the question :)
>>
>> My question still stands (I'd never presumed this was valid traffic) -
>> what I'm trying to find out if buried within the trove of stats
>> produced by 'rndc stats' is there any counter, that counts:
>>
>> "
>> Nov 30 00:00:00 client @0xXXXXX X.X.X.X#48536 (.): query (cache)
>> './ANY/IN' denied
>> "
>
> I think you are asking the wrong question and looking at the wrong
> feature.  You can probably do what you're after with
> statistics-channels.
>
> https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/html/reference.html#statis
> tics-channels-statement-grammar

Thanks - I'll go check that out - it looks far better / correct than
parsing the stats file.

As for the wrong question - I don't get why it's 'wrong' to ask if there's
a better way of getting the total number of "denied" entries such as the
one above, rather than 'cat /var/log/messages | grep | wc -l' type affair ?
- Unless 'denied' effectively appears as some other stat already?

At this stage we're trying to work out how much traffic is getting denied
(as it's likely junk) vs. regular responses etc.

-Karl
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Chuck Aurora
On 2020-12-01 10:25, Karl Pielorz wrote:

> --On 1 December 2020 at 10:14:50 -0600 Chuck Aurora <[hidden email]>
> wrote:
>
>> On 2020-12-01 04:43, Karl Pielorz wrote:
>>> So, as the original person that posted the question :)
>>>
>>> My question still stands (I'd never presumed this was valid traffic)
>>> -
>>> what I'm trying to find out if buried within the trove of stats
>>> produced by 'rndc stats' is there any counter, that counts:
>>>
>>> "
>>> Nov 30 00:00:00 client @0xXXXXX X.X.X.X#48536 (.): query (cache)
>>> './ANY/IN' denied
>>> "
>>
>> I think you are asking the wrong question and looking at the wrong
>> feature.  You can probably do what you're after with
>> statistics-channels.
>>
>> https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/html/reference.html#statis
>> tics-channels-statement-grammar
>
> Thanks - I'll go check that out - it looks far better / correct than
> parsing the stats file.
>
> As for the wrong question - I don't get why it's 'wrong' to ask if
> there's a better way of getting the total number of "denied" entries

Sorry, I skimmed the post quickly and thought you simply were asking
about
parsing the stats file.
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind stats - denied queries?

Karl Pielorz


--On 1 December 2020 at 10:30:21 -0600 Chuck Aurora <[hidden email]> wrote:

>> As for the wrong question - I don't get why it's 'wrong' to ask if
>> there's a better way of getting the total number of "denied" entries
>
> Sorry, I skimmed the post quickly and thought you simply were asking about
> parsing the stats file.

np - I'm happily staring at statistics channel output now,

Cheers,

-Karl
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users