The issue I am facing:
Over the weekend, I rebuilt my setup on a Pi 4 w/ a 64-bit version of Pi OS w/ recursive DNS via Unbound.
Upon rebooting, I'm finding that I immediately get warnings from DNSMASQ and the Tailscale IP assigned to the device gets rate-limited. In addition, the device seems to run hot frequently (~145 F).
I'm only using one additional list in addition to StevenBlack's master list, so I wouldn't have expected that this would generate quite as many requests.
I'm thinking about moving away from the recursive setup and using one of Cloudflare's resolvers - which I ran for several years in a prior setup and are generally fast - but wanted to know if there are config changes that might improve the conditions I'm seeing.
Details about my system:
Pi 4 w/ 64-bit Raspberry OS
It very well could be normal - a concerning prospect - my recently decommissioned Pi 3 didn't exhibit this kind of behavior during the entire time I used it.
This particular board started out as a RetroPie and was in a case that included a fan in addition to the heatsinks, so I'll see if that makes a difference. The official Pi 4 case doesn't help much in this regard, but as I said, the 3 w/ the official case never gave me this particular trouble.
I'm also thinking Unbound may be more trouble than it's worth, as what was a 100 Mb/s connection is routinely in the 20's with tremendous latency (~500ms). Fortunately, reverting that change doesn't require taking the entire software stack apart and reassembling from scratch.
Your debug log shows Maximum number of concurrent DNS queries reached warnings as well as rate limiting messages for 100.103.119.45 (the IP address that is associated to your tailscale interface).
Those messages may suggest that you've created a DNS loop.
What is the complete output of the following command from the Pi terminal:
DNS would only be involved in determining the speedtest domain's IP address.
It has has absolutely no impact on download speeds - once that IP address is known, the download communication is via that IP.
Reading a bit more, it appears this issue isn'tnew and is likely the result of an error in how Pi OS configures Unbound.
It's entirely plausible I may have copied this part incorrectly during that initial setup. I presume the official documentation has been updated to address this issue?
The grep statement is indeed intended to check for that unbound misconfiguration, but your system is not affected (no resolvconf_resolvers.conf pointing to the machine itself).
This makes it more likely that your tailscale network would be involved somehow.
This would be further supported if you'd be able to confirm that Pi-hole is working if you disable tailscale.
This appears to have been the root cause. While there remains a small hit to download speed with Pi-hole running, numbers are routinely the 80-90 Mb/s range with low ping latency - in line with what I saw before.
Operating load/temps are also back in the green/blue @ ~130F.
