Hi Alex. Your use case may be very different to the one I faced in my previous job. But there we did not and could not charge for DNS. It was seen as a necessary but free resource. If you *really* want to account for how many queries clients are making, a quick and dirty solution is enabling querylog, BUT be warned it causes a lot more load on the system. The better tool would be DNStap.
But there is no 1-to-1 correlation between user queries (client side of server) and fetches (Internet side of server). In a perfect (i.e. lab) setup, if all clients make the same query then, apart from the initial fetches to find the answer(s) the server can answer everything from cache and there is no internet traffic at all. (100% cache hit ratio) The other extreme is clients all making random queries (PRSD), which your server cannot cache, so this causes it to generate much more Internet traffic; at least as much as the clients are generating. (0% cache hit ratio) Cheers, Greg On Fri, 6 May 2022 at 16:02, Alex K <rightkickt...@gmail.com> wrote: > Hi all, > > I have the following problem: I run a caching dns server using bind9 > v9.10.3 in a gateway device which it serves several internal LAN IP > addresses (clients). I am doing some traffic accounting in the gateway > device using Linux conntrack so as to calculate the generated client > traffic (mostly HTTP/HTTPs related, in/out) so as to charge the volume > consumed. > > What I cannot charge is the actual DNS traffic that each client is > generating, since each client DNS request is actually two sessions, one > between client and gateway device and the other between gateway and > upstream DNS servers. It seems to me not fare to charge the traffic > observed between the client and the gateway since the internal DNS traffic > includes cached responses and may be much higher from the actual DNS > traffic observed on the WAN side (gateway - upstream). > > I was wondering if there is a solution to this. If bind9 has any feature > that can be used to track the WAN DNS traffic and understand from which > client was first requested/generated. In this way I will be able to > differentiate the DNS traffic per client and avoid accounting DNS traffic > that the gateway generated for its own services. > > Just as an additional note on this, I had in the past the same issue with > the proxy traffic that this same gateway was generating and found a > solution by using TPROXY feature of the squid proxy, which exposes the real > internal client IP address at the WAN traffic which can later be NATed. > > Thanx for any ideas, > Alex > -- > 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 >
-- 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
