DNSMASQ_WARN for Max Concurrent Queries (max is 150) when using VPN or when using Pi-Hole as local network DNS with 35+ devices

[Bucking_Horn]

@MrAnderson175

The reason for this is because whenever I make the token for debugging, 100.66.218.18 actually makes it so that it doesn't send the token to the tricorder, giving this error "curl: (6) Could not resolve host: tricorder.pi-hole.net" Which is why when I share the token, 1.1.1.1 is the nameserver instead of 100.66.218.18 which is the IP of the Pi-Hole on the Tailscale software so it can work.

Oh, I see - so you normally configure your RPi to use its public VPN IP as DNS resolver.

This may well be the reason for those excessive DNS requests:
Your RPi is trying to sync its time with a time server. To that end, is asking 100.66.218.18 to resolve 0.debian.pool.ntp.org, and that may time out due to a DNS loop between your upstream unbound and Pi-hole, introduced by Bullseye's unbound package:

@MrAnderson175

This is what I get for the output of dig flurry.com -p 5355 @127.0.0.1

; <<>> DiG 9.16.27-Debian <<>> flurry.com -p 5335 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22871

@MrAnderson175

Did a clean install of Bullseye 64bit on RP4 4GB. I had no issues or errors installing Pi-hole or Unbound or Tailscale for VPN.

(For a complete background, see WARNING: Raspbian October 2021 release bullseye + unbound ).
You could verify you are affected by inspecting the output of the following command:

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*

If that turns up entries from a file resolvconf_resolvers.conf pointing towards your RPi's addresses, then that's how the loop is closed.

To fix this, try the steps (same as mentioned in deHakkelaar's link above):

1. Edit file /etc/resolvconf.conf and comment out the last line which should read:

unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

2. Delete the unwanted unbound configuration file:

sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

3. Restart unbound:

sudo service unbound restart

Chances are that this would fix your issue.

Still, I wonder why you point resolv.conf to your RPi's public VPN IP.
Is that a Tailscale requirement?
Your linked Tailscale guide says:

Pi-Hole uses DNS servers configured within Linux as its upstream servers, where it will send DNS queries that it cannot answer on its own. Since we’re going to make the Pi-Hole be our DNS server, we don’t want Pi-Hole trying to use itself as its own upstream.

This is plain wrong:
As explained previously, Pi-hole is using the upstream DNS servers you've configured for it, not those configured by its host's Linux OS.

I suspect that if you would have pointed your RPi's resolv.conf to 1.1.1.1, you would at least have avoided the frantic DNS requests for the time servers, but you'd probably still have had to deal with the unbound loop.

If Tailscale does not require to change resolv.conf, you could opt to use 127.0.0.1 and a public DNS IP as nameservers. That way, your RPi's own DNS request would usually be filtered by Pi-hole, it would still be able to resolve DNS requests in case Pi-hole's DNS service should be inaccessible at times.

@MrAnderson175

On the Pi-Hole guide for unbound, I don't recall that it needs an RTC module to work

A battery-backuped RTC is not a requirement.
If your RPi runs with a stable power supply and stable internet connection, then you probably won't notice a difference - until a power cut would down your RPi for a few hours.
Lacking aforementioned RTC, your RPi won't have a correct time upon booting, and it may then not be able to acquire the correct time from a time server on the internet, especially if DNSSEC is enabled.
And until correct time information is restored for your RPi, that may also render those cryptographic services inoperational that rely on a common time frame among all parties involved.

EDIT:
And seeing that your issue was indeed fixed while I typed this lengthy post , you could consider to readjust your RATE_LIMIT, and you won't need to bother with dns-forward-max.