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

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. I saved everything from the previous pihole that I had running 2 years using the teleporter feature on Pi-Hole settings.

Now I got the same errors a before when running buster: DNSMASQ_WARN & RATE_LIMIT. I figured out how to adjust the RATE_LIMIT in /etc/pihole/pihole-FTL.conf by adding 10000/300 under the privacy line. But I don't know where I can change or add the line to adjust the limit of concurrent DNS queries requested.

Another issue I noticed when using the Tailscale VPN is that the warning "Non-local device ignored" last time I set up the VPN was by changing the listing options in DNS settings to permit all origins and it worked.

There is a dnsmasq option that would allow to lift the concurrent limit.
However, I would recommend establishing the actual cause for excessive DNS requests flooding first, before applying this setting blindly. No amount of limit increase will alleviate a DNS loop.

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

-0, --dns-forward-max=

Set the maximum number of concurrent DNS queries. The default value is 150, which should be fine for most setups. The only known situation where this needs to be increased is when using web-server log file resolvers, which can generate large numbers of concurrent queries. This parameter actually controls the number of concurrent queries per server group, where a server group is the set of server(s) associated with a single domain. So if a domain has it's own server via --server=/example.com/1.2.3.4 and 1.2.3.4 is not responding, but queries for *.example.com cannot go elsewhere, then other queries will not be affected. On configurations with many such server groups and tight resources, this value may need to be reduced.

Here is my token, sorry for taking so long: https://tricorder.pi-hole.net/a5eB1v0M/

This token is with just my phone using the Pi-Hole as the resolver.

I see the line to put in, but where to put it in the pi-hole file configuration is my question. The same place as the rate limit in /etc/pihole/pihole-FTL.conf?

Put this in a new configuration file in directory /etc/dnsmasq.d.

Then restart Pi-hole.

So when I enter sudo nano /etc/dnsmasq.d, it says that /etc/dnsmasq.d is a directory in red and won't let me save it. How do I access the directory to add that line and save it?

Also here's a token with 24 clients after 40mins: https://tricorder.pi-hole.net/h0BWk8Po/

You want to make a new file, not edit the directory.

sudo nano /etc/dnsmasq.d/99-concurrent.conf

So I made the new file and entered -0, --dns-forward-max=300 and restarted the DNS resolver, it stopped the DNS from being active. Once I removed the line, and restarted the DNS resolver it was working normally.

Please do not try to blindly increase your concurrent queries limit.
If you do not address the underlying cause, all that will likely do is to inflate your log files with additional amounts of requests before that other arbitrary limit is exceeded.

Your debug log shows your router to distribute multiple DNS servers:

*** [ 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.186
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 192.168.1.1
      dns-server: 192.168.1.186
      dns-server: 192.168.1.129
      --- end of options ---

Only the .186 is associoated to your Pi-hole host machine.
DHCP clients may use .129 to by-pass Pi-hole.
Pi-hole has to be your sole DNS server.

Please share extracts of your /var/log/pihole.log (or possibly /var/log/pihole.log.1) around the time your diagnostic warnings:

*** [ DIAGNOSING ]: Pi-hole diagnosis messages
id   timestamp            type           message    
---  -------------------  -------------  ----------------------------------------------------------
8    2022-04-09 22:42:58  DNSMASQ_WARN   Maximum number of concurrent DNS queries reached (max: 150)

Run from your Pi-hole host, what do the following commands return:

echo ">stats >quit" | nc localhost 4711
echo ">top-domains >quit" | nc localhost 4711
echo ">top-ads >quit" | nc localhost 4711
echo ">top-clients >quit" | nc localhost 4711

I don't understand, I've been using .129 as the redundant Pi-hole on a Zero2, with 1.1.1.2, 1.0.0.2 as the upstream DNS, without issue on the Ubiquiti EdgeRouter-X.

So you're telling me I can only have one Pi-hole server as the DNS service without a backup?

Also this is what I can in the output of the commands in the image below

Here's the newest token log: https://tricorder.pi-hole.net/wkAN8gGa/

You didn't mention you were running two Pi-holes before. :wink:
In that case, it wouldn't hurt if your clients by-pass your Pi-hole#1 for Pi-hole#2.

Your results show that you've got two public IPs among your top clients (starting with 100).
The top one seems to be related to a tailscale0 interface of your host -something VPN related?

*** [ DIAGNOSING ]: Network interfaces and addresses
   4: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
       link/none 
       inet 100.66.218.18/32 scope global tailscale0

That client IP has issued about 458,000 requests - by far the most requests, dwarfing the next in line by a factor of roughly 45.

Let's check what domains are requested by that client most often.
Please share the output of:

pihole-FTL sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT domain, count(domain) FROM queries WHERE client='100.66.218.18' GROUP BY domain ORDER BY 2 DESC LIMIT 10;"

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.


I'm not sure how this command works. But I am still able to access the admin page and the SSH.

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

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.

1 Like