Open seang96 opened 1 week ago
What problem would the cache solve that the current in-memory cache does not address?
Is the use-case sharing the cache between several Leng instances?
Yes that would be the use case. I imagine most records would have a decent enough ttls for it to be beneficial in reducing lookups to the upstream dns server.
I am not super convinced of how beneficial this would be, considering the complexity it adds. Assuming the shared cache is on a different node:
I don't think we can answer (1) without knowing the built-in cache hit-rate. I think I will add a metric for this in the next release, it is something that I am now curious about!
As for (2), I guess that very much depends on your setup. Even if your redis cache is in the same datacenter as Leng, and you are going to 1.1.1.1
for DNS, I'd expect the difference to be under 10ms. So you get an idea, ping 1.1.1.1
gives me an average of 1.4ms in a Contabo server, and 4.2ms in a Hetzner server.
So I think I can only see this being very useful if your machines are wired up together in your house, but the internet is far away?
At any rate, I will build a new metric for the cache hit-rate and we can see how that does. Let me know what you think!
That would be a good metric to add!
Another note that was pointed out would be increased privacy from the upstream DNS server, they wouldn't be able to see as much / track your habits.
That being said I am also not sure how much of an advantage it is to be worth it, it wouldn't be complex for me to configure at least and I'd be happy to test, but code complexity for saving a couple ms may not be worth it.
Edit: also jealous of your ping time. I get 20+ on my coax and 50+ on my backup 5g wan!
Saw this mention in another DNS service, and thought it would be a nice addition though may also be an anti goal of keeping it simple, keeping existing support would hopefully eliminate that as a concern.