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.halatuit...@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-boun...@lists.isc.org] *On Behalf > Of *Bob Harold > *Sent:* Thursday, 20 July 2017 2:27 a.m. > *To:* Abi Askushi > *Cc:* bind-users@lists.isc.org > *Subject:* Re: DNS traffic accounting > > > > > > On Wed, Jul 19, 2017 at 6:20 AM, Abi Askushi <rightkickt...@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 <rightkickt...@gmail.com> > wrote: > > This could do. > > I just have to get those counters. > > > > Thanx, > > Abi > > > > On Jul 18, 2017 18:37, "Matthew Seaman" <m.sea...@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. >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
