I use the Pihole as the DNS resolver for my Tailscale network devices, which is a VPN using WireGuard, when I travel outside of my network.
I copied pasted what you asked and I didn't get an output unless I have to write in the domain and client IP in.
My bad - you should run that command for your tailscale0 client IP address 100.66.218.18. I've edited my previous post accordingly.
So you are running Tailscale on your machine hosting Pi-hole as well as on some network clients, and clients are
The vast majority of DNS activity (over 90%) on your Pi-hole at 192.168.1.186 is caused by that client IP of your tailscale0 interface, which matches your observation of those max concurrent warnings appearing since you introduced Tailscale:
At the time you were producing the logs, were you traveling?
How many of your clients do use Tailscale?
Yes, but I did not have any devices connected to Pi-Hole via the Tailscale at the time of the errors, it is only the hosting Pi-Hole device that is always connected.
I have no issues when I connect my device to the VPN, its all mostly from the Pi-Hole the 192.168.1.186 is the IP of the Pi-Hole on the local network while 100.66.218.18 is the Tailscale IP.
At the time of the logs, no device was connected, it was only when I installed and connected the Pi-Hole device to the VPN network. I typically use 3 device on Tailscale.
Here is the output it gave
Here's also the most recent warning message token: https://tricorder.pi-hole.net/awvWnQtl/
I think I may have figured it out, so the Pi-hole local time is correct, however the sync to the system and RTC in local TZ are off as show here.
Then I tried running these two commands below
I found these commands from these two threads from 2-3 years ago
Not quite sure why the problem didn't arise until now when the recent update came out with the RATE_LIMIT and DNSMASQ_WARN messages.
And I don't know how I can apply this fix to Bullseye version.
(Could you consider to post console output as text?
It would be easier to read, easier to copy and paste from, easier to redact for sensitive information, and it uses less storage. I'll help with the formatting if required.)
DNS traffic from your Tailscale IP 100.66.218.18 seems desperate to get the IP of a time server. Correct time information is crucial for many cryptographic procedures, so may be as well for your Tailscale VPN service.
Your debug log shows a process tailscaled running, which I assume is your Tailscale VPN software.
Note that DNS resolution on Pi-hole's host system is completely independent from Pi-hole's DNS operation:
While Pi-hole is accepting incoming DNS requests from your clients and forwarding allowed requests to its configured upstream DNS servers, its host system will continue to use whatever it is configured for.
Your debug log shows your host system to point to 1.1.1.1 for DNS resolution:
*** [ DIAGNOSING ]: contents of /etc
-rw-r--r-- 1 root root 45 Apr 11 11:45 /etc/resolv.conf
nameserver 1.1.1.1
Thus, it is not yet clear why your tailscaled service would use Pi-hole for DNS at all.
Moreover, it is strange that dig 0.debian.pool.ntp.org failed because no servers could be reached, while a dig directed at @1.1.1.1 would resolve correctly, when both of those digs should have been handled by 1.1.1.1.
Please run the following commands on your RPi:
dig flurry.com
dig flurry.com @192.168.1.186
dig flurry.com -p 5335 @127.0.0.1
I'd expect to see IP address replies for all of those but the one that goes to your Pi-hole's IP.
As an attempt to address your issue for the moment, you could try to stop your Tailscale VPN service on your Pi-hole host (if you are currently not travelling), probably by running:
sudo systemctl stop tailscaled.service
But please:
Run the three dig commands twice - once before you stop Tailscale, and once after.
RPis do lack a battery-backuped RTC, so that field will always be no.
If the time is correct, but not yet synced, that wouldn't be an immediate concern.
If you employ services that absolutely rely on correct time information (e.g. DNSSEC, and potentially your VPN software), you should probably consider to fit an RTC on your RPi.
Yes please do, I am new to this platform and don't know how to format the IP addresses or the cli outputs. Aslo apologies for the late replys, I'm in between classes and away from my local network for a few days.
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.
Tailscale uses Pi-Hole for DNS so the devices on the VPN can have the filtering of Pi-Hole. I have done this method before following this tutorial: Access a Pi-hole from anywhere · Tailscale Docs
This is because of what I mentioned earlier when the nameserver is 100.66.218.18
The following outputs are when connected to Tailscale.
This is what I get for the output for dig flurry.com
; <<>> DiG 9.16.27-Debian <<>> flurry.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9872
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flurry.com. IN A
;; ANSWER SECTION:
flurry.com. 2 IN A 0.0.0.0
;; Query time: 3 msec
;; SERVER: 100.66.218.18#53(100.66.218.18)
;; WHEN: Tue Apr 12 13:04:08 EDT 2022
;; MSG SIZE rcvd: 55
This is what I get for the output for dig flurry.com @192.168.1.186
; <<>> DiG 9.16.27-Debian <<>> flurry.com @192.168.1.186
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18039
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flurry.com. IN A
;; ANSWER SECTION:
flurry.com. 2 IN A 0.0.0.0
;; Query time: 0 msec
;; SERVER: 192.168.1.186#53(192.168.1.186)
;; WHEN: Tue Apr 12 13:04:23 EDT 2022
;; MSG SIZE rcvd: 55
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
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flurry.com. IN A
;; Query time: 3167 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Tue Apr 12 13:04:41 EDT 2022
;; MSG SIZE rcvd: 39
On the Pi-Hole guide for unbound, I don't recall that it needs an RTC module to work, as I have been using unbound for over a year and never encountered this issue before. DNSSEC worked before the update for the RATE_LIMIT and DNSMASQ were added. Same with the Tailscale VPN, I've used Pi-Hole as the DNS for the VPN for years and never had a RTC issue. Even now I can still connect to it, but the debian.pool.npt.org requests continues.
Try do below:
I will try this soon but thank you so much
I just followed the instructions and it now works, its no longer pinging the debian.pool.ntp servers. Thank you so much, I'm doing a student showcase for my college about this and was in a panic to get it fixed.
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:
(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):
/etc/resolvconf.conf and comment out the last line which should read:unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
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.
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.
Thank @Bucking_Horn for it as he adviced you to run below:
If want to read bit more about it:
Good luck with the showcase!
This is what I got for the output:
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf: interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf: port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf: prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf: edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf: prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf: so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fe80::/10
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf: auto-trust-anchor-file: "/var/lib/unbound/root.key"
I am not quite sure myself, I only noticed it when the token could not upload to the tricorder.
Yes, even after chaining the nameserver to 1.1.1.1, I still had the flood of DNS request because of the unbound loop.
I changed it to 4000/300 because I'll change it back as the main DNS for my local network at home.
Thank you and everyone else for your help in this matter. 
Thank you, have a great day
Same issue with my setup pihole, unbound,tailscale
I've moved your post to the topic that actually deals with Tailscale.
Have a read and see if the solution would apply to you.
If it doesn't, please start a new topic with a full description.
Got it, thank you
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.