<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 9, 2022 at 11:48 AM Petr Špaček <<a href="mailto:pspacek@isc.org">pspacek@isc.org</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">On 09. 05. 22 10:34, Alex K wrote:<br>
> Hi Petr,<br>
> <br>
> On Mon, May 9, 2022 at 10:26 AM Petr Špaček <<a href="mailto:pspacek@isc.org" target="_blank">pspacek@isc.org</a> <br>
> <mailto:<a href="mailto:pspacek@isc.org" target="_blank">pspacek@isc.org</a>>> wrote:<br>
> <br>
> On 06. 05. 22 17:02, Alex K wrote:<br>
> > Hi all,<br>
> ><br>
> > I have the following problem: I run a caching dns server using bind9<br>
> > v9.10.3 in a gateway device which it serves several internal LAN IP<br>
> > addresses (clients). I am doing some traffic accounting in the<br>
> gateway<br>
> > device using Linux conntrack so as to calculate the generated client<br>
> > traffic (mostly HTTP/HTTPs related, in/out) so as to charge the<br>
> volume<br>
> > consumed.<br>
> ><br>
> > What I cannot charge is the actual DNS traffic that each client is<br>
> > generating, since each client DNS request is actually two<br>
> sessions, one<br>
> > between client and gateway device and the other between gateway and<br>
> > upstream DNS servers. It seems to me not fare to charge the traffic<br>
> > observed between the client and the gateway since the internal DNS<br>
> > traffic includes cached responses and may be much higher from the<br>
> actual<br>
> > DNS traffic observed on the WAN side (gateway - upstream).<br>
> ><br>
> > I was wondering if there is a solution to this. If bind9 has any<br>
> feature<br>
> > that can be used to track the WAN DNS traffic and understand from<br>
> which<br>
> > client was first requested/generated. In this way I will be able to<br>
> > differentiate the DNS traffic per client and avoid accounting DNS<br>
> > traffic that the gateway generated for its own services.<br>
> <br>
> It cannot be done because there is no 1:1 mapping between client and<br>
> authoritative side of BIND. Multiple client queries might be solved<br>
> by a<br>
> single query to authoritative side, or a single query might cause<br>
> multiple interrelated queries.<br>
> <br>
> If money are involved then I say "don't even try": All reasonable<br>
> solutions will cause either overcharging or undercharging, which is not<br>
> only objectionable but also possibly illegal.<br>
> <br>
> Out of curiosity, is the amount of traffic so large it is worth<br>
> considering it? Compared to all the YouTube videos? :-)<br>
> <br>
> The initial and current approach is to provide DNS free of charge, which <br>
> simplified things for me. Though the traffic in question is satellite <br>
> traffic with monthly allowances of roughly 4 to 8GB, thus every MB counts.<br>
> The problem now is that I see sometime 700MB of DNS traffic for 2GB of <br>
> Internet browsing within one month. <br>
<br>
Sounds like either:<br>
- Broken caching or,<br>
- Random subdomain attack<br>
to me.<br>
<br>
>Currently I do not monitor what is<br>
> the internal/cached DNS vs external/actual DNS traffic so as to know the <br>
> ratio but it can be significant for such types of deployments. For <br>
> deployments where the monthly allowance is unlimited no-one ever came to <br>
> me to ask why DNS is not charged but in this case the customers will <br>
> need to know where the MBs are consumed. Hope that this clarifies the <br>
> situation.<br>
> <br>
> What I was thinking, as per Josh feedback, is to use ECS and try to find <br>
> out a way to match that WAN/actual DNS traffic which is initially <br>
> generated from clients. Then I could use some math to calculate the per <br>
> client DNS traffic to account, but it's a bit hackish and I cannot think <br>
> of anything else. The other approach would be to just charge all the <br>
> internal traffic with the risk of overcharging, as long the the <br>
> customers agree with it.<br>
<br>
ECS with full client identifier is a terrible idea because:<br>
- It will expose all client IP addresses to rest of the Internet.<br>
- Is not even allowed by ECS RFCs.<br>
- It will lower cache hit ratio and you will end up using much more <br>
traffic for DNS than without ECS.<br></blockquote><div>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. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(All this this assumes you even have access to BIND ECS support is only <br>
in the BIND subscription edition.)<br>
<br>
I recommend just not going there, do something on resolver-client side <br>
instead. </blockquote><div>Thanx for your feedback. Appreciated. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Petr Špaček<br>
-- <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></div>