Hi Greg, On Mon, May 9, 2022 at 11:17 AM Greg Choules < gregchoules+bindus...@googlemail.com> wrote:
> 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. > I would rather prefer to avoid enabling query logs. One other thing I was thining is to just see if bind9 logs the cache hit ratio in the stats and use that as as rough coefficient for the internal client traffic accounting. > > 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
