Hi all, Wanted to congratulate you on great work with unbound ! My use case of unbound is on ships using satellite uplinks, so in other words high-latency and high-bandwidth... relatively speaking, but surely enough bandwidth for DNS queries.So idea would be to cache and then preemptively re-cache DNS queries as much as possible so to speed up Internet access for users.
This could cut up to 500-800 ms from every DNS query and remove lag on DNS side. This, together with WAN TCP optimization (SYN) would make satellite uplink not so laggy for users onboard. So I notice most of the DNS entries rarely change and local unbound onboard could surely cache lots of entries considering memory and CPU are available nowadays. Thus instead of expiring cached entries after TTL I would like to keep refreshing them regularly and keep them available for some pre-defined time (eg. 2-3 weeks configurable) due to cruise length. I believe this proactive approach with cache & refresh would be more appropriate for such environment. Checking out for options in Unbound I have identified couple of mechanisms to enable this but all seem to lack some features. Prefetch is great feature but seems somewhat limited for entries to be refreshed during last 10% of TTL and only if user resolve entry during that last 10% of TTL time.Furthermore that 10% seems not configurable in config. I know setting it like this increases cache hit ratio for often used entries (ones that also get hit during last 10%) but is not flexible enough. I am trying to cache much beyond that time frame (2-3 weeks - parameter 1) and cannot always guarantee users will be resolving within last 10% of TTL (eg. during night) so I would like to set automated refresh to do refresh on 90% TTL, if DNS entry was asked for more or equal to 0 ... n times after being cached (parameter 2). Of course all up to maximum number of cached entries which would be set appropriately. This would allow for preemptive caching based on number of times entry is queried during TTL and overall length of time to keep such entries in cache.So in other words we would trade-off some bandwidth used in order to reduce DNS latency. Serve-expired is another great feature, but what I am proposing above would work similarly and wouldn't break DNS in case entries are changed, though with some bandwidth trade-off for refreshes. cache-min-ttl would definitely break certain resolutions, but I would use it with 30 - 60 min TTL which is sensible trade off so refresh doesn't happen too often and any changes are still picked up with regular refreshes. Is there anything else that I could use out of the box? What other existing parameters would help towards this caching goal? Thanks,Tiho
