# Statistics for upstream DNS server response times
**URL:** https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652
**Category:** Implemented
**Created:** [November 28, 2019, 11:12am UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652 "2019-11-28T11:12:23Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@ni-kan](https://discourse.pi-hole.net/u/ni-kan)
#### Post date: [November 28, 2019, 11:12am UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/1 "2019-11-28T11:12:23Z")
Based on [this thread](https://discourse.pi-hole.net/t/statistics-for-average-duration-of-forwarded-requests/25639/3), 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:
> [@Statistics for average duration of forwarded requests?](https://discourse.pi-hole.net/t/statistics-for-average-duration-of-forwarded-requests/25639/4):
>
> Neither [pihole.log](https://discourse.pi-hole.net/t/what-files-does-pi-hole-use/1684) nor the current [long term database](https://docs.pi-hole.net/ftldns/database/) hold response times, unfortunately.
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"](https://docs.pi-hole.net/ftldns/dns-resolver/) 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).
---
### Author:  [@deHakkelaar](https://discourse.pi-hole.net/u/deHakkelaar)
#### Post date: [November 29, 2019, 5:09pm UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/2 "2019-11-29T17:09:23Z")
Makes more sense to continue here 😉
> [@Statistics for average duration of forwarded requests?](https://discourse.pi-hole.net/t/statistics-for-average-duration-of-forwarded-requests/25639/4):
>
> While _FTL_ DNS will pick its fastest responding server from the set of configured upstream servers on its own, it indeed doesn’t supply corresponding statistics.
> Lack of this data does not allow the user to make an informed decision on what servers he actually wants to keep.
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.
> **[DNS resolver - Pi-hole documentation](https://docs.pi-hole.net/ftldns/dns-resolver/)**
---
### Author:  [@ni-kan](https://discourse.pi-hole.net/u/ni-kan)
#### Post date: [November 29, 2019, 10:54pm UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/3 "2019-11-29T22:54:58Z")
> [@deHakkelaar](#):
>
> 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!).
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.
---
### Author:  [@deHakkelaar](https://discourse.pi-hole.net/u/deHakkelaar)
#### Post date: [November 29, 2019, 11:22pm UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/4 "2019-11-29T23:22:16Z")
> [@ni-kan](#):
>
> You sure can, but this doesn’t tell you _why_ Pi-hole selected which one.
Yes you can.
Criteria are in the link I posted:
> **[DNS resolver - Pi-hole documentation](https://docs.pi-hole.net/ftldns/dns-resolver/)**
> [@ni-kan](#):
>
> 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.
How would query stats be helpfull in figuring out which DNS server has which particular features like better privacy ?
---
### Author:  [@ni-kan](https://discourse.pi-hole.net/u/ni-kan)
#### Post date: [November 29, 2019, 11:38pm UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/5 "2019-11-29T23:38:58Z")
> [@deHakkelaar](#):
>
> How would query stats be helpfull in figuring out which DNS server has which particular features like better privacy ?
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.
---
### Author:  [@deHakkelaar](https://discourse.pi-hole.net/u/deHakkelaar)
#### Post date: [November 29, 2019, 11:42pm UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/6 "2019-11-29T23:42:15Z")
You can hover your mouse over the pie chart and you'll get percentages.
---
### Author:  [@DanSchaper](https://discourse.pi-hole.net/u/DanSchaper)
#### Post date: [November 30, 2019, 1:23am UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/7 "2019-11-30T01:23:41Z")
Thanks for the feature request, we'll add it to the list. No need to debate the issue please.
---
### Author:  [@deHakkelaar](https://discourse.pi-hole.net/u/deHakkelaar)
#### Post date: [November 30, 2019, 2:43am UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/8 "2019-11-30T02:43:20Z")
My apologies.
As with any new feature, you dont miss them until you have them 😉
---
### Author:  [@Knapoc](https://discourse.pi-hole.net/u/Knapoc)
#### Post date: [May 28, 2020, 5:32pm UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/9 "2020-05-28T17:32:29Z")
to add to this feature request:
It would be nice if the reply time is printed into the logs.
---
### Author:  [@Leandro\_86](https://discourse.pi-hole.net/u/Leandro_86)
#### Post date: [July 2, 2020, 10:35am UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/10 "2020-07-02T10:35:16Z")
I found this request while discussing another older one [here](https://discourse.pi-hole.net/t/show-dns-performance-in-the-pihole-gui/8499), 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.
---
### Author:  [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)
#### Post date: [July 12, 2026, 11:14am UTC](https://discourse.pi-hole.net/t/statistics-for-upstream-dns-server-response-times/25652/11 "2026-07-12T11:14:57Z")
Pi-hole v6 records this. Each query stores its reply time, and the API reports an average response time per upstream server (top upstreams). Marking this as implemented. (If you mean a dedicated chart in the GUI rather than the data itself, let us know and we can split that off.)