[Feature Request] DNS prefetching (Blocky alike)

[Wabuo]

I would love if dnscrypt-proxy would support some sort of DNS prefetching.

Something on the lines of if the request has been made more than, let's say, for example 5 times within the last hour.
Then the domain will be prefetched for the next 24h.
Prefetching in this case would mean the domain will automatically be looked up again just before the cache/TTL expires, obviously without bumping the counter only actual clients should increase the threshold counter and therefore also reset the prefetch duration timer.

Useful settings for DNS prefetching I see:

# amount of time all clients collectively have to request a domain before it gets prefetched
prefetch_threshold = 5
# time period within the above-mentioned requests for a given domain have to occur, for that domain to trigger prefetching
prefetch_threshold_period = 1h
# time period for how long a domain that has met above thresholds shall be prefetched 
prefetch_duration = 24h
# Supports time in: seconds, minutes, and % of mean response time added to response time
## lets say our mean responses time is 100ms, setting it to 20% would mean the lookup will be done 120ms before the cache/TTL expires
prefetch_before_expiry = 20%

[Wabuo]

Another cool feature along the same line would be to export the top n requested domains of the last x hours or days, and to use that list on start-up to (re-)populate the cache by looking them all up once, within the first seconds after start-up.
Maybe at a rate of 1 request every 10ms or what ever rate is well below the that feels like abuses, so there's still room for a bunch of client requests on top.

I'm thinking something on the lines of those defaults:

• export list of top 500 requested domains within the last 24h after every 12h of uptime of dnscrypt-proxy.
  • this ensures a reasonable amount of data even in case of a bunch of restarts in quick succession
  • while guaranteeing blazing fast responses within seconds after a restart, instead of feeling kinda sluggish for the first minutes while clients slowly painfully fill the cache.

I see no problem with this process adding to any of the above introduced counters because that one initial request barely qualifies as noise but on the other hand the functionality to filter internal requests from the counters should exist already because of the prefetching logic ...

[jedisct1]

All modern web browsers already do this!

In a way that's way smarter than any DNS cache could, since they know about resource types, content-specified prefetch rules, and what was loaded in private mode.

Privacy-oriented browsers intentionally don't do that.

Doing it would bring a couple issues:

• It wouldn't be blazing fast. A lot of records have very short TTLs, so they will expire until you actually start a web browser (or use them immediately, but background services are not latency-sensitive)
• It would be redundant and less efficient than what web browsers do
• It would leak more information than browsers already do. Namely, it would tremendously help DNS servers learn the correlation between domains, and the set of prefetched domains also composes a unique fingerprint, that a VPN or relay can't protect against.
• It would put more load on resolvers. Possibly 100x. Most of them are run by volunteers, who pay bandwidth and servers from their own pocket. Telling them they'll have to pay way more so that, occasionally, people would load a page 0.1 second faster the first time after they open their laptop, is not nice. What may actually happen is that more load means that these servers will either give up, or become slower, so eventually, this is not a win for anyone.

[Wabuo]

Fair points!

I'm currently using dnscrypt-proxy on an OpenWrt router with around 30 regular clients behind it and on events that number might climb regularly to around a 100, but on any regular day during work hours it might actually only be in use by 1 or two people at a time and that's obviously when the painfully long response times show and feel annoying.

I'm using a bunch of physically close oblivious relays to relay to physically close servers.
From the logs I can tell that on average it's using 3 to 4 relays relaying to the best 4(p4) servers out of around 7 to 10 or so servers with some having drastically different response times through the day, so they seem to get nicely rotated through.

With a response time somewhere from around 45ms to 150ms (dnscrypt-proxy is configured to time out after that for the initial speed rating)

Resolution is painfully slow, as in a lot of requests take 1.5 seconds to resolve because it seems the upstream servers quite often needs to look up the domain first too, which often means the server times me out and then another server gets queried and when it finally queries the original server again - by then that server finally has an answer ready.
I'm in New Zealand and use servers and relays in NZ and Australia, but they seem to not get much traffic, especially for European sites ... therefore painfully slow lookups of around up to 1.5 and in rare cases 2 seconds.

So currently a lot of requests are supper painfully slow to the point where the end-users rightfully so complain, especially because they are used to the fast responses from 1.1.1.1 that was autoconfigured by Starlink previously with a response time of around 20ms.

Also, I don't fully see how prefetched domains behind a relay would expose a fingerprint because latest at the relay it should drown in the noise, and the relay will just see slightly increased traffic.
And even before that, having a bunch of domains getting looked up shortly before they expire should be indistinguishable from an end-user requesting it again as son as the TTL expires and me running no cache on the proxy.
It's also not like they would all happen at the same time because the request would happen at what ever random time the last lookup was after it entered the prefetching state plus the min cache time or the expiry of the TTL.

Same with prefilling the cache with the last top 100 0r 500 requested domains after start up.
Again, latest the relay should hide any possible fingerprinting, especially considering that request on average get spread to a bunch of servers and relays.
Also, those requests wouldn't be instantaneous when the connection comes online, but instead be spread out over the first few seconds, heck we could even get a bunch answered while rating relays and servers.

And after that only end up in the prefetching list if they make the threshold of client requests, so it shouldn't look any different from a bigger, slightly busy network to come up.

I would love if you could elaborate why you see fingerprinting privacy issues.

And maybe if you feel like it also how you would set up things in my situation.