DNS traffic tracking

[Petr Špaček]

On 09. 05. 22 10:34, Alex K wrote:
> Hi Petr,
> 
> On Mon, May 9, 2022 at 10:26 AM Petr Špaček <pspacek at isc.org 
> <mailto:pspacek at 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.

(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.

-- 
Petr Špaček