[Feature Request] Separate cache for each upstream group

[emlimap]

Blocky at the moment uses one cache for all groups. This works for most cases, except when you want DNS responses intended for one group not to be served to others.

For example, at the moment, I have blocky configured to send DNS requests from TV to Clash program. It will return a fake IP address and any traffic to the fake IP range will be intercepted and sent to Clash by IPtables rule on the router. This allows for a DIY smart DNS to access geo restricted services provided you have access to proxies.

The problem is that if a device other than TV requests a domain shared by TV, blocky will resolve and cache the real IP there by bypassing the proxy and get geo restricted. On the flip side, if TV resolves the domain first, traffic from other devices for that domain will go down the proxy rather than outside.

This feature would also be useful for another scenario where you would want to use Family safe DNS for devices used by kids and standard DNS for others. This may require blocky not to fall back to default group when group specific DNS resolvers aren't available to avoid bypassing the filtering.

[kwitsch]

I get the idea behind it.

But I would rather opt for an caching group approach.

Like:

• all client group's without a configuration are in a default group
• client group's can be configured to use a different cache group
• client group's in the same cach group share the same cache

This would significantly reduce the cache duplicates from an per group approach. Cache duplicates would not only increase memory usage but also network load and upstream requests.

[0xERR0R]

Change in cache handling could be relative complex since we also use redis to synchronize caches between instances.

[kwitsch]

I would implement my proposal by prefixing the cache key with the cache group name. Relatively small change and stays redis compatible. 😅

[0xERR0R]

There is certainly a solution. I just wanted to point out that the issue can quickly become complex.

[kwitsch]

There is certainly a solution. I just wanted to point out that the issue can quickly become complex.

I absolutly agree. It took some releases to get the cache(prefetching & redis included) this stable. The proposal is reasonable but nothing that can be quickly released as it may take some time securing the stability we currently have.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.