Your debug log shows something's amiss with your Pi-hole's network connectivity:
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
192.168.86.200/24 matches the IP found in /etc/pihole/setupVars.conf
[i] Default IPv4 gateway: 192.168.86.1
192.168.86.1
* Pinging 192.168.86.1
192.168.86.1...
[✗] Gateway did not respond
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve cpatext.ru via localhost (127.0.0.1)
[✗] Failed to resolve cpatext.ru via Pi-hole (192.168.86.200)
[✓] doubleclick.com is 172.217.14.206 via a remote, public DNS server (8.8.8.8)
It also shows you are running a few additional software packages on the same machine:
*** [ DIAGNOSING ]: Ports in use
*:32400 Plex Me (IPv6)
127.0.0.1:32401 Plex Me (IPv4)
*:22 sshd (IPv4)
*:22 sshd (IPv6)
*:548 afpd (IPv6)
[::1]:4700 cnid_metad (IPv6)
[80] is in use by lighttpd
[80] is in use by lighttpd
127.0.0.1:35983 Plex Sc (IPv4)
127.0.0.1:32600 Plex Tu (IPv4)
*:445 smbd (IPv6)
*:139 smbd (IPv6)
*:445 smbd (IPv4)
*:139 smbd (IPv4)
[53] is in use by pihole-FTL
[53] is in use by pihole-FTL
[4711] is in use by pihole-FTL
[4711] is in use by pihole-FTL
(I am reasonably sure the public DNS servers in your test don't also run a Plex media server)
This may very well contribute to memory shortages, resulting in forced stops of Pi-hole's lighttpd, in the vain hope to acquire enough memory on restart:
*** [ DIAGNOSING ]: contents of /var/log/lighttpd
-rw-r--r-- 1 www-data www-data 2073 Oct 1 09:53 /var/log/lighttpd/error.log
2020-09-27 00:00:22: (server.c.1759) logfiles cycled UID = 0 PID = 15264
2020-09-27 13:23:51: (mod_fastcgi.c.421) FastCGI-stderr: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes) in /var/www/html/admin/scripts/pi-hole/php/FTL.php on line 80
2020-09-27 16:39:41: (server.c.2059) server stopped by UID = 0 PID = 1
2020-09-27 16:39:42: (server.c.1464) server started (lighttpd/1.4.53)
You may try to increase PHP memory allocation, but you should keep a keen eye on your other processes memory consumption as well.
EDIT: Honestly I just flushed the pihole log and my DNS resolution speed is normal again? To be clear, I did a reboot and repair on pihole before the previous debug and benchmark. Now that I've flushed the log, the new benchmark shows normal DNS resolution speeds. Interesting!
*** [ DIAGNOSING ]: Networking
[i] Default IPv4 gateway: 192.168.86.1
192.168.86.1
* Pinging 192.168.86.1
192.168.86.1...
[✗] Gateway did not respond
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve youbora.com via localhost (127.0.0.1)
[✓] youbora.com is 0.0.0.0 via Pi-hole (192.168.86.200)
[✓] doubleclick.com is 172.217.14.206 via a remote, public DNS server (8.8.8.8)
The Gateway did not respond message should not be overrated, any device may reject pings for reasons. I am puzzled by its IP address being repeated 3 times; it would normally just show the IP and the ping.
It's also strange that loopback resolution via 127.0.0.1 still fails.
It won't necessarily hurt Pi-hole's operation (resolution by Pi-hole's IP works), but it would imply that your RPi doesn't have DNS resolution for itself. While this wouldn't prompt any issues with clients, it could well cause problems for processes running on that machine.
As for your tests:
It's hard to comment on those without knowing what tools you used, how those derived their values, and how your Pi-hole was configured at the time of testing.
But we could try to approach this by starting with some more simple commands.
First, let's see how your network resolves DNS queries:
What's the result of the following command, run from both your Pi-hole machine as well as a client each?
nslookup flurry.com pi.hole
EDIT: I must have missed you editing your answer while I was compiling mine.
Let me know if it's still an issue.
It is back to being a problem, which is odd. For example, ESPN will hang while resolving and fully fail out in Chrome. A reload will then immediately resolve it (I assume using cache). As for the DNS benchmark, I am just using DNS Benchmark on Windows which quantitively confirms that I saw with ESPN.
nslookup flurry.com
Server: testwifi.here
Address: 192.168.86.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to testwifi.here timed-out
Of netsh interface ipv6 show dnsservers. All non-wifi adapters have fec0:0:0:ffff::1%1, fec0:0:0:ffff::2%1, fec0:0:0:ffff::3%1
Configuration for interface "Wi-Fi"
DNS servers configured through DHCP: None
Register with which suffix: Primary only
Of netsh interface ipv4 show dnsservers. All non-wifi adapters have DNS server = None.
Configuration for interface "Wi-Fi"
DNS servers configured through DHCP: 192.168.86.1
Register with which suffix: Primary only
Your Windows client is still using your router as its DNS server, not Pi-hole.
Even if that may be a valid configuration for certain situations, there is definitely something wrong with the way DNS resolution is handled by your router.
This is demonstrated by the timeouts in your commands' output.
Timeouts may e.g occur if you'd configured a DNS loop.
In contrast, you should see normal resolution durations when directing DNS queries directly to your Pi-hole.
Assuming your Pi-hole still resides at 192.168.86.200, you could confirm this by running the following commands, this time from your Pi-hole machine:
dig discourse.pi-hole.net @8.8.8.8.8 | grep time
Above will show resolution speed sample for Google's DNS servers.
dig discourse.pi-hole.net @192.168.86.200 | grep time
Above will show resolution speed sample for Pi-hole on first hit.
dig discourse.pi-hole.net @192.168.86.200 | grep time
Above will show resolution speed sample for Pi-hole on consecutive hits.
Yes, the Windows machine is using the router as DNS. However, the router should be resolving via my RPi with pi-hole. Isn't this the typical setup? You might be right that there is ultimately something wrong it how it is routing this logic, but it is going to pi-hole (eventually, at least). When I ran the nslookup from client, I can see the DNS request be blocked in pi-hole.
The first lookup through Pi-hole would be expected to return at about the same speed or just a tiny bit slower than via 8.8.8.8, the second lookup through Pi-hole would go straight to Pi-hole's cache: It should therefore return instantly (<10 msecs).
Sorry, just had the chance to do this now. I think the cause is within pi-hole itself. I've reproduced this with several log flushes.
Right when I flush the log - 38 ms on first resolution, then cached response. Wait a little bit... then it not only no longer caches, but it also takes much longer.
Indeed, enabling Conditional Forwarding in Pi-hole while configuring your router to use Pi-hole as its upstream DNS - as opposed to distributing PI-hole as local DNS server via DHCP - will close a partial DNS loop:
Your Pi-hole will send DNS queries for devices on your local network to your router, which may send them back to your Pi-hole, continuing back and forth forever or until timeout.
