DNS traffic accounting

Sat Jul 22 18:51:21 UTC 2017

Interesting project the packetbeat.

I was wondering if bind9 can support TPROXY. This would facilate my
accounting as then all WAN traffic would have the client IP as the source
IP. ( I have a similar configuration with squid where I was able to account
the WAN traffic using this trick without having to deal with squid stats
and cache)

On Jul 19, 2017 20:36, "Maile Halatuituia" <maile.halatuituia at tcc.to> wrote:

> Not sure it would help but I have a current project where I  send bind raw
> data using packetbeat to elk stack allow me to see what individual user
> lookup at any given time and also how many …
>
>
>
> Thank You Once Again.
>
> ICT Team.
>
>
>
> *From:* bind-users [mailto:bind-users-bounces at lists.isc.org] *On Behalf
> Of *Bob Harold
> *Sent:* Thursday, 20 July 2017 2:27 a.m.
> *To:* Abi Askushi
> *Cc:* bind-users at lists.isc.org
> *Subject:* Re: DNS traffic accounting
>
>
>
>
>
> On Wed, Jul 19, 2017 at 6:20 AM, Abi Askushi <rightkicktech at gmail.com>
> wrote:
>
>
>
> I enabled logging for the queries and am getting now queries from clients
> in the below form:
>
> 19-Jul-2017 10:11:29.310 client 192.168.200.102#27975: view auth: query:
> mobile.in.gr IN A + (192.168.200.1)
> 19-Jul-2017 10:11:29.794 client 192.168.200.102#32874: view auth: query:
> static.adman.gr IN A + (192.168.200.1)
> 19-Jul-2017 10:11:31.564 client 192.168.200.102#36746: view auth: query:
> android.clients.google.com IN A + (192.168.200.1)
> 19-Jul-2017 10:11:32.721 client 192.168.200.102#60248: view auth: query:
> mobilefeed.in.gr IN A + (192.168.200.1)
> 19-Jul-2017 10:11:39.440 client 192.168.200.102#53832: view auth: query:
> stats.g.doubleclick.net IN A + (192.168.200.1)
> 19-Jul-2017 10:11:44.523 client 192.168.200.102#22693: view auth: query:
> mqtt-mini.facebook.com IN A + (192.168.200.1)
> 19-Jul-2017 10:11:51.429 client 192.168.200.102#37734: view auth: query:
> www.googleapis.com IN A + (192.168.200.1)
> 19-Jul-2017 10:11:55.603 client 192.168.200.102#62531: view auth: query:
> clients3.google.com IN A + (192.168.200.1)
> 19-Jul-2017 10:11:57.352 client 192.168.200.102#11788: view auth: query:
> clients4.google.com IN A + (192.168.200.1)
> 19-Jul-2017 10:11:57.353 client 192.168.200.102#19409: view auth: query:
> clients4.google.com IN A + (192.168.200.1)
> 19-Jul-2017 10:12:06.365 client 192.168.200.102#51726: view auth: query:
> graph.instagram.com IN A + (192.168.200.1)
>
> I could count the queries by parsing the logs though this seems to be
> somehow inefficient.
>
> Is there any way that bind9 could be queries otherwise to provide such
> info?
>
>
>
> Read up on the statistics channel in the BIND manual.
>
>
>
> --
>
> Bob Harold
>
>
>
>
>
> Many thanx,
>
> Abi
>
>
>
> On Wed, Jul 19, 2017 at 12:04 AM, Abi Askushi <rightkicktech at gmail.com>
> wrote:
>
> This could do.
>
> I just have to get those counters.
>
>
>
> Thanx,
>
> Abi
>
>
>
> On Jul 18, 2017 18:37, "Matthew Seaman" <m.seaman at infracaninophile.co.uk>
> wrote:
>
> On 07/18/17 16:09, Abi Askushi wrote:
> > I am trying to figure out how could I account the DNS traffic generated
> > from clients in terms of bytes. My setup is a simple caching DNS with
> > several clients querying the DNS server.  I can measure the DNS traffic
> > that is generated from the DNS server on the WAN side by using some
> > monitoring tool (pmacct) but I am not sure how could I account this
> traffic
> > to the clients that are generating this traffic. By simply monitoring the
> > internal DNS traffic from clients I expect to not be accurate since it
> will
> > include also cached responses which do not generate WAN traffic.
> >
> > Any suggestion how to approach this problem?
>
> The implication of what you're suggesting is that if client A looks up
> some address that isn't in the cache, then they will be charged for
> that. However, if client B then comes along and looks up the exact same
> address shortly afterwards, they'll get a response from cache and so not
> be charged.  That seems a bit arbitrary.
>
> Why not charge your clients based simply on the number of queries they
> make against your resolver?  You know or can easily find out how many
> queries your resolver is handling in total and how much the WAN traffic
> that generates is costing you so it should be fairly easy to come up
> with a charging scheme based on the average cost per DNS query.
>
>         Cheers,
>
>         Matthew
>
>
>
>
>
>
>
> Confidentiality Notice: This email (including any attachment) is intended
> for internal use only. Any unauthorized use, dissemination or copying of
> the content is prohibited. If you are not the intended recipient and have
> received this e-mail in error, please notify the sender by email and delete
> this email and any attachment.
> Confidentiality Notice: This email (including any attachment) is intended
> for internal use only. Any unauthorized use, dissemination or copying of
> the content is prohibited. If you are not the intended recipient and have
> received this e-mail in error, please notify the sender by email and delete
> this email and any attachment.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170722/0d5c2d7c/attachment.html>