On Mon, May 9, 2022 at 11:48 AM Petr Špaček <pspa...@isc.org> wrote:
> On 09. 05. 22 10:34, Alex K wrote: > > Hi Petr, > > > > On Mon, May 9, 2022 at 10:26 AM Petr Špaček <pspa...@isc.org > > <mailto:pspa...@isc.org>> wrote: > > > > On 06. 05. 22 17:02, Alex K 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. > > > > It cannot be done because there is no 1:1 mapping between client and > > authoritative side of BIND. Multiple client queries might be solved > > by a > > single query to authoritative side, or a single query might cause > > multiple interrelated queries. > > > > If money are involved then I say "don't even try": All reasonable > > solutions will cause either overcharging or undercharging, which is > not > > only objectionable but also possibly illegal. > > > > Out of curiosity, is the amount of traffic so large it is worth > > considering it? Compared to all the YouTube videos? :-) > > > > The initial and current approach is to provide DNS free of charge, which > > simplified things for me. Though the traffic in question is satellite > > traffic with monthly allowances of roughly 4 to 8GB, thus every MB > counts. > > The problem now is that I see sometime 700MB of DNS traffic for 2GB of > > Internet browsing within one month. > > Sounds like either: > - Broken caching or, > - Random subdomain attack > to me. > > >Currently I do not monitor what is > > the internal/cached DNS vs external/actual DNS traffic so as to know the > > ratio but it can be significant for such types of deployments. For > > deployments where the monthly allowance is unlimited no-one ever came to > > me to ask why DNS is not charged but in this case the customers will > > need to know where the MBs are consumed. Hope that this clarifies the > > situation. > > > > What I was thinking, as per Josh feedback, is to use ECS and try to find > > out a way to match that WAN/actual DNS traffic which is initially > > generated from clients. Then I could use some math to calculate the per > > client DNS traffic to account, but it's a bit hackish and I cannot think > > of anything else. The other approach would be to just charge all the > > internal traffic with the risk of overcharging, as long the the > > customers agree with it. > > ECS with full client identifier is a terrible idea because: > - It will expose all client IP addresses to rest of the Internet. > - Is not even allowed by ECS RFCs. > - It will lower cache hit ratio and you will end up using much more > traffic for DNS than without ECS. > I have two levels of recursive servers due to the current design thus the final exposed traffic will not include the internal client IP addresses, but I agree, I would like to avoid ECS since I do not have the required subscription and would prefer a more simple approach. > > (All this this assumes you even have access to BIND ECS support is only > in the BIND subscription edition.) > > I recommend just not going there, do something on resolver-client side > instead. Thanx for your feedback. Appreciated. > > -- > Petr Špaček > -- > 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
