Based on this thread, I suggest the following feature:
Statistics for average response times for upstream DNS resolvers
So far, Pi-hole calculates the response time for individual upstream DNS queries:
But this data seems to be discarded afterwards:
It would, however, be quite interesting to have it stored and be able to access it as average response time for different upstream DNS servers (for, let's say, different time periods like last 24h or week). While Pi-hole currently selects the "best" forward resolver, it does not show by how much they differ in response times.
Improved transparency by offering these statistics would makes proper debugging and experimentation with local DNS resolvers like BIND9 and Unbound regarding cache times and the likes quite a lot easier. It would also help when other factors like security and anonymity play a role in the user's decision (e.g. live with a 10% lower response time from DNS server B over server A because of B's superior security).
If you have multiple upstream DNS servers configured, you can observe on the "Queries answered by" pie chart, the servers that gets queried the most.
Those are the ones determined to be the best forward destination by pihole-FTL (correct me if I'm wrong!).
For me personally this is enough info.
You sure can, but this doesn't tell you why Pi-hole selected which one. It could be that most of the queries get sent to server A, because it's 10% faster than server B, although server B has superior privacy and other advantages. Or it could be a 50% speed difference. In the first case, I'd rather go with B, but I cannot make an informed decision without the statistical data to support it.
It wouldn't. It would, as I wrote, tell you which server is faster (and therefore selected by Pi-hole) by which amount.
Again, let's say server B has advantages over server A in areas which a user considers „nice to have“ (e.g. certain security or privacy features):
In scenario 1, A is 10 % faster than B.
In scenario 2, A is 50 % faster than B.
Now depending on how much weight a user puts on the advantages of server B, he may very well take the minor hit in scenario 1 and go with B instead of A. He would probably not do that in scenario 2.
It's all about going from binary „A is faster/slower“ (current implementation) to a granular „A is faster/slower by … %“ (suggested implementation) and therefore allowing the user to make an informed decision.
I found this request while discussing another older one here, which is very related.
Having these stats saved in the database would be really sweet, but as Knapoc pointed out, a simple addition to the logs would make the manual measurements much easier.