Sites taking a long time to resolve and begin to load.

I have been experiencing slow site loads, DNS resolution seems to be taking a long time.

Have Cable Modem (no DNS/DHCP here) > Firewalla Gold (DHCP here) then
– Pi4B running Pi-hole connected to its own network on Firewalla
– Eero 6 Pros connected to another network on Firewalla.
– Firewalla settings directing everything DNS related to hit the Pi4B. This is setup how Firewalla recommends and has been working for ~3 years.

I started noticing the issue several months ago and just really haven’t had a good look into it so wondering if anyone has suggestions?
I ran on CloudFlare for a long time and switched to Quad9 ~4-5 months ago as a test, it seemed better for a day or so then got bad again.

Affecting 20,222 of 727,854 queries or about 3% over 7 days. (feels like every manual query, not just 3%)
87.6 avg response over 7 days
I got these numbers after following links in another post I found about slow response times.

I also noticed there was maximum number of DNS queries error stored in PiHole.
Followed this post tonight to attempt to resolve that issue but unsure what is causing it?

Expected Behaviour:

Fast resolution/load times
Pi4B 2gb RAM on Bullseye - all updates run

Actual Behaviour:

I’m seeing many sites taking a long time to initially load. Progress bar just stalls in browsers on various devices, iOS and Mac alike.

Debug Token:

https://tricorder.pi-hole.net/IfRQ0Hs5

I would not recommend to follow that post you've linked, as it does not address those max concurrent warnings at all, it just throws more resources at it. That's similar to throwing more wood in the broad direction of smoke instead of trying to find the fire.

Often, Maximum number of concurrent DNS queries reached is triggered by a DNS loop configuration.
Occasionally, an unreachable or unresponsive upstream DNS server could have Pi-hole exhaust its connection pool quickly while waiting for unanswered forwarded queries to complete.
And less often, a misbehaving client excessively requesting resolution for a set of domains in rapid succession could also trigger it.

Your debug log shows your router to distribute itself as local DNS server:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 300 bytes from eth0:192.168.1.1
     Offered IP address: 192.168.1.10
     DHCP options:
      Message type: DHCPOFFER (2)
      dns-server: 192.168.1.1
      router: 192.168.1.1

This is a valid configuration, as long as your router would be using Pi-hole as its sole upstream DNS server. However, as Pi-hole would receive all DNS requests from your router, you won't be able to attribute DNS requests to individual clients in such a configuration (and consequently, to take advantage of client-specific filtering).
Of course, this would make it harder to identify an excessively requesting client.

Your debug log shows Pi-hole's Conditional Forwarding as disabled, which is good, as enabling it in that configuration would have closed a partial DNS loop.

Regarding other possible loops:

Would that apply to one of Pi-hole's upstreams as well (9.9.9.9 or 149.112.112.112)?
Then that would close a DNS loop.
To avoid that, your Pi-hole machine has to be exempted from those DNS redirection rules.

Your debug log shows a few instances where concurrent queries where maxed out:

*** [ DIAGNOSING ]: contents of /var/log/pihole

-rw-r--r-- 1 pihole pihole 13K Oct 26 22:20 /var/log/pihole/FTL.log
   -----head of FTL.log------
(...)
   [2024-10-26 04:02:23.412 658M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)
   [2024-10-26 04:02:32.549 658M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)
   [2024-10-26 04:02:42.232 658M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)
   [2024-10-26 04:03:09.115 658M] WARNING in dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)

You could take a closer look at the DNS replies immediately preceding those warnings, e.g. by running:

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, reply_type, client, count(*) FROM queries \
WHERE timestamp > strftime('%s','2024-10-26 04:03:09.115', '-5 minutes', 'utc') \
AND timestamp <= strftime('%s','2024-10-26 04:03:09.115', 'utc') \
GROUP BY domain, reply_type;"

Thank you for the response/advice (I am not allowed to @ you, apparently). I removed the file I created as part of following that post and rebooted my Pi.

As far as the DHCP config you pointed out, yes my pi-hole is on another network segment and is the only upstream server and I am not taking advantage of client-specific filtering. Everything just shows up in the Pi-Hole log as coming from "firewalla.lan”.

When I first got the Firewalla ~3 years ago I was having issues with pi-hole running on the same network segment as the rest of my stuff for some reason. It would randomly stop blocking ads.
I was directed to this page by one of the FW support reps: https://help.firewalla.com/hc/en-us/articles/360062551673-How-to-run-an-external-pi-hole-with-Firewalla. Now, referencing the aforementioned URL several years later, I am curious as to what has changed because I don't think I quite recall all of those things above the config instructions I followed. It was presented to me as "you have to create another network segment if you want to run separate pi-hole hardware, here's how." I did not change the WAN DNS setting to point to Pi-hole. I don't know that I should.

Consequently I setup a "Pi-Hole" network segment (192.168.1.1) on 1 ethernet port of my Firewalla with only the Pi-Hole on it, reserved @ 192.168.1.10.

I pointed the DNS settings of the "Home" network segment (192.168.2.1) to two other ports, where the 80 other connected devices live, to the Pi-hole's IP, 192.168.1.10, everything has more or less worked fine since, with the exception of this problem.

Now, reviewing the DNS settings of the pi-hole network segment, I do see it is set to 192.168.1.1 which I think the log was showing you as it was pointed out. I Should it be set to point at the pi-hole IP directly... because I just changed that to point to Pi-hole and everything seems extra snappy loading sites, though I'm not sure I understand why given there's nothing else on that network segment but the pi-hole.

Thanks