<div dir="ltr"><div dir="ltr"><div>Hi Greg, <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 9, 2022 at 11:17 AM Greg Choules <<a href="mailto:gregchoules%2Bbindusers@googlemail.com">gregchoules+bindusers@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Alex.<div>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.</div><div>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.</div></div></blockquote><div>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. <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>But there is no 1-to-1 correlation between user queries (client side of server) and fetches (Internet side of server).</div><div>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)</div><div>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)</div><div><br></div><div>Cheers, Greg</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 6 May 2022 at 16:02, Alex K <<a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all, <br></div><div><br></div><div>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. <br></div><div><br></div><div>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). <br></div><div><br></div><div>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. <br></div><div><br></div><div>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.<br></div><div><br></div><div>Thanx for any ideas,<br></div><div>Alex<br></div></div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>
</blockquote></div></div>