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

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.

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.

[MrAnderson175]

@Bucking_Horn

( 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. )

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.

@Bucking_Horn

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

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.

@Bucking_Horn

Thus, it is not yet clear why your tailscaled service would use Pi-hole for DNS at all

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

@Bucking_Horn

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 dig s should have been handled by 1.1.1.1.

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

[MrAnderson175]

@Bucking_Horn

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.

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.

[deHakkelaar]

@MrAnderson175

; <<>> 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

Try do below:

Problems with unbound/unbound servfail

This may be your problem: Edit file /etc/resolvconf.conf and comment out the last line which should read: unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf Delete the unwanted unbound configuration file: sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf Restart unbound: sudo service unbound restart

[MrAnderson175]

I will try this soon but thank you so much

[MrAnderson175]

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.

[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.

[deHakkelaar]

@MrAnderson175

Thank you so much

Thank @Bucking_Horn for it as he adviced you to run below:

@Bucking_Horn

dig flurry.com -p 5335 @127.0.0.1

If want to read bit more about it:

WARNING: Raspbian October 2021 release bullseye + unbound

remember this one? been busy the entire day to find out bullseye (fresh install) reconfigures unbound the solution is the same, comment out the unbound entry in /etc/resolvconf.conf, however, if resolvconf managed to run with the entry active, it creates a file /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf. You need to delete that file and restart unbound to resume normal behaviour. The file created on my system contained only IPv6 info (IP address masked): # Generated by resolvconf …

Good luck with the showcase!

[MrAnderson175]

@Bucking_Horn

You could verify you are affected by inspecting the output of the following command

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"

@Bucking_Horn

Is that a Tailscale requirement?

I am not quite sure myself, I only noticed it when the token could not upload to the tricorder.

@Bucking_Horn

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.

Yes, even after chaining the nameserver to 1.1.1.1, I still had the flood of DNS request because of the unbound loop.

@Bucking_Horn

You could consider to readjust your RATE_LIMIT

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.

[MrAnderson175]

Thank you, have a great day

[chrbre]

Same issue with my setup pihole, unbound,tailscale

[Bucking_Horn]

@chrbre

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.

[MrAnderson175]

Got it, thank you