DNS traffic tracking

[Alex K]

Hi Greg,

On Mon, May 9, 2022 at 11:17 AM Greg Choules <
gregchoules+bindusers at 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 <rightkicktech at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220509/6338c468/attachment-0001.htm>