DNS Benchmark shows lost queries

Please follow the below template, it will help us to help you!

I am a new user of Raspberry Pi and Pi-hole. I set it up a couple of days ago and I am generally pleased with how it works. Ads are definitely being blocked.
But I was a bit worried that it might affect my network performance negatively, so I ran DNS Benchmark, (GRC's | DNS Nameserver Performance Benchmark  ) something I have done many times over the years.

Using new Raspberry Pi 3 Model B+ with Pihole Version 4.1.1, DNS Benchmark 1.3.6668.0. I have a Google WiFi router (and satellites), but the pi-hole is connected through ethernet cable.

Expected Behaviour:

When I run DNS Benchmark I expect to have good performance and no dropped queries. I have tested many routers with DNS Benchmark, while some of them have been a bit slow, none of them has ever indicated any lost queries.

Actual Behaviour:

Most of the time that I run DNS Benchmark, I get ok performance, but I get a high red double bar indicating that I have a significant amount of lost queries (Sometimes I get the expected behaviour of no bar at all). I have never seen these "lost queries" with any other DNS server.

When running 'pihole -d', I got the following error once:
"Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)"
That is the debug token I have attached. I ran 'pihole -d' several more times, and could not repeat the behaviour.

Debug Token:

emap707vr8

This shows that your Pi-Hole was unable to reach the Google DNS server, and usually indicates a connectivity issue for the Pi through the router, or a temporary unavailablity of the requested IP The test is shown here in the debug.sh code:

Of note, in the same debug log, the tail of the pihole.log shows that Pi-Hole used the alternate Google DNS server (8.8.4.4) to successfully resolve domain names. So, from this perspective it does not appear that there were any dropped queries.

   Feb  2 00:00:09 dnsmasq[4804]: query[A] clients4.google.com from 192.168.211.1
   Feb  2 00:00:09 dnsmasq[4804]: forwarded clients4.google.com to 8.8.4.4
   Feb  2 00:00:09 dnsmasq[4804]: query[A] clients4.google.com from 192.168.211.1
   Feb  2 00:00:09 dnsmasq[4804]: forwarded clients4.google.com to 8.8.4.4
   Feb  2 00:00:09 dnsmasq[4804]: reply clients4.google.com is <CNAME>
   Feb  2 00:00:09 dnsmasq[4804]: reply clients.l.google.com is 216.58.211.142
   Feb  2 00:00:09 dnsmasq[4804]: reply clients4.google.com is <CNAME>
   Feb  2 00:00:09 dnsmasq[4804]: reply clients.l.google.com is 216.58.211.142

I'm not familiar with this DNS benchmark software, but is it querying domains that are being blocked by Pi-Hole? If the benchmark expects a reply, but Pi-Hole blocked that domain and returned NULL, does the benchmark see that as a "dropped" query?

The pihole.log and query log will have the results for each DNS query and the reply. If there are no lost or dropped queries in the logs, then I wouldn't worry about what the benchmark software is showing. If the query log shows the query being received, forwarded and the reply being received in a reasonable time frame (perhaps a few 10's of msec for many upstream DNS resolvers), then you don't have problems.

How do I tell if there are dropped queries in the logs? Doing the command

dig +short chaos txt evictions.bind

gives the result "0"
Does that mean that there are no lost queries?

About DNS benchmark, I found that others have been using it successfully with pi-hole

But I was also thinking that maybe some of the domain names that DNS Benchmark uses for testing are blocked by pi-hole and that DNS Benchmark mistakenly classifies those that are blocked as "lost queries". I haven't been able to find any detailed information about what DNS Benchmark classifies as "lost queries". I have asked this question at GRC's | DNS Benchmark & Spoofability Test Feedback  

By the way, thanks for this great piece of software!

This means that there were no evictions from the Pi-Hole DNS cache and is not related to any dropped queries. DNS cache - Pi-hole documentation

I don't use DNS Benchmark or other similar software. Pi-Hole has a pretty good algorithm by which it determines which of your upstream DNS resolvers is the best responder. You might want to try running Pi-Hole with some additional upstream DNS servers for a few days and see which ones rise to the top of use (as determined by Pi-Hole based on performance). You will see this in the "queries answered by" pie chart on the Admin GUI dashboard.

https://docs.pi-hole.net/ftldns/dns-resolver/

The query log on the dashboard will show a summary for each query. In the "Reply" column, you should see the reply and the time to receive that reply. In the example below, each of the green (non-blocked) queries shows a reply and time to receive the reply. In this example, none of the replies were cached and all had to be fetched from the upstream resolver. If you have query with no reply, that would indicate a problem.

Another resource that shows the same data in a different form is the log located at /var/log/pihole.log. You can tail this log with a pihole command; pihole -t, which nicely color codes the output. An example of a log appears below - the color was corrupted in the text translation, your screen will look different. In this example, you can see that each query received a reply, but the time lag for the reply is not shown in msec detail as in the query log.

 pihole -t
  [i] Press Ctrl-C to exit
Feb  2 11:40:59 dnsmasq[31962]: query[A] beacon.dropbox.com from 192.168.0.135
Feb  2 11:40:59 dnsmasq[31962]: forwarded beacon.dropbox.com to 127.0.0.1
Feb  2 11:40:59 dnsmasq[31962]: reply beacon.dropbox.com is <CNAME>
Feb  2 11:40:59 dnsmasq[31962]: reply beacon.v.dropbox.com is 162.125.34.129
Feb  2 11:41:26 dnsmasq[31962]: query[A] api.mixpanel.com from 192.168.0.135
Feb  2 11:41:26 dnsmasq[31962]: /etc/pihole/black.list api.mixpanel.com is 0.0.0.0
Feb  2 11:41:38 dnsmasq[31962]: query[A] mobile.pipe.aria.microsoft.com from 192.168.0.135
Feb  2 11:41:38 dnsmasq[31962]: /etc/pihole/black.list mobile.pipe.aria.microsoft.com is 0.0.0.0
Feb  2 11:41:43 dnsmasq[31962]: query[A] nexus.officeapps.live.com from 192.168.0.135
Feb  2 11:41:43 dnsmasq[31962]: /etc/pihole/gravity.list nexus.officeapps.live.com is 0.0.0.0
Feb  2 11:42:10 dnsmasq[31962]: query[PTR] db._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.135
Feb  2 11:42:10 dnsmasq[31962]: forwarded db._dns-sd._udp.0.0.168.192.in-addr.arpa to 127.0.0.1
Feb  2 11:42:10 dnsmasq[31962]: query[A] reddit.map.fastly.net from 192.168.0.135
Feb  2 11:42:10 dnsmasq[31962]: forwarded reddit.map.fastly.net to 127.0.0.1
Feb  2 11:42:10 dnsmasq[31962]: query[A] c.aaxads.com from 192.168.0.135
Feb  2 11:42:10 dnsmasq[31962]: /etc/pihole/gravity.list c.aaxads.com is 0.0.0.0
Feb  2 11:42:10 dnsmasq[31962]: query[A] www.googletagservices.com from 192.168.0.135
Feb  2 11:42:10 dnsmasq[31962]: /etc/pihole/gravity.list www.googletagservices.com is 0.0.0.0
Feb  2 11:42:10 dnsmasq[31962]: query[A] c.amazon-adsystem.com from 192.168.0.135
Feb  2 11:42:10 dnsmasq[31962]: /etc/pihole/gravity.list c.amazon-adsystem.com is 0.0.0.0
Feb  2 11:42:10 dnsmasq[31962]: reply reddit.map.fastly.net is 151.101.185.140
Feb  2 11:42:11 dnsmasq[31962]: query[A] www.googletagmanager.com from 192.168.0.135

This worked for me. Since I added some more upstream DNS servers, I never get any lost queries.

Right now I have two ip-specified upstream DNS servers, and I have three of the predefined checked. What number of upstream servers is best practice? Can I keep it at this amount, or should I remove the ones that Pi-Hole deems slowest?

There is no defined answer for this. If the best performing server is consistently the same server, I would drop the others and stick with what works. It doesn't hurt to keep the extras in there (you aren't hindering performance), but I like to keep things simple where I can.

As long as you keep at least two different servers, hosted on different networks, you should be protected from local (to them) outages. Keeping more won't hurt anything.

I have two IP v4 and two v6 servers configured.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.