feat: dns caching

[ohaiibuzzle]

Add a simple TTL cache for the DNS Resolver. Seperated from #129. Re-do from #132

The idea is that since SpoofDPI currently have to perform DNS lookup on every request it make, it would get slow if a domain is requested multiple times over multiple connections (easiest example being something like a social timeline where each image is a new connection). Adding a cache here allows some of them to be kept for later requests which reduces latency.

Note that this cache implementation is NOT optimal. If there is a flood of uncached requests, some may miss the cache even when they have been written by other routines. The issue is that I've not found a way to fix the issue without effectively render the resolver single threaded :(

Also after merge you may want to set a different default TTL (like 300s). 60s might be a bit on the aggressive side for DNS caching

[ohaiibuzzle]

@TeaDove sorry for the (suuuuuuuuuuper) late response. I've take that into account and rebase the code. Please check if the implementation is acceptable

[Ledorub]

Can it lead to issues when client switches from IPv4-only connection to IPv6-only or vice versa? I assume that in such circumstances SpoofDPI will return an address from the cache, which will be unreachable from the client.

[ohaiibuzzle]

In theory, it is an issue, and we could account for that by also caching the queried type, but like, this shouldn’t happen unless you are hopping network to network in a very short amount of time.

Still, something to consider

[LiquidTheDangerous]

@ohaiibuzzle It seems that caching by qType makes no sense. In any case, if the name is resolved, then we can dial a connection with ipv4 or ipv6 address

[ohaiibuzzle]

From what I can tell the matter that is being brought up here is a novel-ish situation where if the cache is on v4, then somehow during cache expiry you jump from a v4-only network to v6-only (or back), it will serve a v4 address to a v6-only network (or vice versa) and fail

@LiquidTheDangerous

[ohaiibuzzle]

@LiquidTheDangerous We could but a daemon scrubbing routine still have to exist to prevent a situation where a cache item that is rarely accessed is indefinitely stored (because it never gets accessed again to be cleared)

[LiquidTheDangerous]

@ohaiibuzzle You can look at this branch, tell please how suitable it is for implementing a cache. Create a new handler and insert it into the chain #250

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity.

[github-actions]

This pull request was closed because it has been stalled for 7 days with no activity.