Unbound DNS entry pre(caching)

[Eric Luehrsen]

On 4/22/19 8:02 AM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
> To mitigate upstream queries (save bandwidth, speed up queries, enhance 
> privacy) it might be worthwhile to consider (pre)serving a copy of the 
> root (.) for local usage via auth-zone as described in example.conf.in 
> (Authority zones) in the package documentation.
> 
> On 22/04/2019 13:30, Tihomir Loncaric via Unbound-users wrote:
>> 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

The options related to fetch or prefetch may also help. A little more 
sophisticated, download a favorite spam/adblock list and install those 
domains as "local-zone: <zone> static". This may prevent noisy nonsense 
from slowing down web browsing.
-Eric