Network Crashes related to Maximum number of concurrent DNS queries reached (max: 150)?

[ToWn3r]

Hi Pi-Hole friends!

I was hoping members of this community might be able to help answer if my whole network going down (wireless and hardwired LAN devices lose connection to the router) could be occurring due to Pi-Hole hitting the max number of concurrent DNS queries.

I’m trying to figure out if it’s my router that is starting to die, and when it goes down, the connectivity to the upstream DNS server is lost which causes all of my devices to “panic” and start spamming the Pi-Hole with queries resulting in major spikes and the Maximum number of concurrent DNS queries reached (max: 150) error.

The latest spike on the Client Activity chart is the last time my network went down.

I’m giving the following a try but figured I’d ask if hitting that max could cause a router to freeze up and require a reboot.

[Resolved] Maximum number of concurrent DNS queries reached

I have been working to find solutions based on the above concern; most posts on the forum explain in some regards how to troubleshoot to attempt to overcome this concern, and rarely have a guide or how-to, to resolve the concern in detail. Below list the following detailed steps that were taking to attempt to resolve this concern: Connect to pihole via SSH Navigate to /etc/dnsmasq.d/ check to see if the following .conf exists on your Pihole instance 02-custom-settings.conf If this …

Thanks in advance!

Debug Token:
https://tricorder.pi-hole.net/0bUBjHGL/

[Bucking_Horn]

A Maximum number of concurrent message is commonly triggered by a faulty DNS configuration closing a DNS loop of sorts, or by an unresponsive or inaccessible upstream DNS server (e.g. due to loss of upstream connectivity), or seldom by some misbehaving clients excessively requesting resolution.

That linked post is more of an attempt to duckshoot the messenger instead of taking a look at the message than a universally applicable remedy.
It may perhaps have helped that one user in their specific circumstances, but setting some arbitrary config variables to random values will just delay that message at best.

Instead, I'd recommend to investigate what is causing the warning in your case, and then address that cause, if possible. Only if not, I'd consider to try to mitigate the potential impact of the warning by trying to tweak Pi-hole's embedded pihole-FTL/dnsmasq.

In your case, if you suspect your router to completely lose its upstream connectivity, Pi-hole would be forced to wait until that upstream answers, or until time-out (usually, a few seconds).

In that scenario, any 150 requests would be enough to use up all connections, and Pi-hole would have to turn down any DNS request arriving after that, resulting in the Maximum concurrent warning, and probably triggering clients to immediate repetitions of those refused DNS requests.

If indeed upstream connectivity would be your issue, you should probably consider to switch your router and/or ISP.

If it would just be your specific upstreams, you could try to use a different set of upstream DNS servers.

Note that according to your debug log, you do not have IPv6 connectivity, so there would be no use in picking IPv6 upstreams for Pi-hole.

I also not that your machine hosting Pi-hole has two active network interfaces, eth0 and wlan0.
If you do not need wlan0 for reasons, you could consider to disable that interface altogether, to avoid potential routing issues (and to save some mA of power).

Your debug log also suggest that you run some third party speedtest addon with your Pi-hole.
You should consider to disable that, to help you rule out that it would have an impact on your upstream connectivity issues.

[ToWn3r]

Thank you so much for the response!

I had a feeling the “solution” in that other thread was just a bandaid on a severed arm type problem.

How can I figure out if the issue is indeed upstream connectivity due to my router?

use a different set of upstream DNS servers.

Which DNS Upstream server is recommended over Cloudflare?

It’s been so long, I can’t quite remember why I left wlan0 enabled when I think everything should be utilizing the eth0 interface.

The Speedtest Pi-Hole Mod should already be disabled/uninstalled. Surprised it’s showing up in the logs.

[ToWn3r]

LOL

Yup, even after applying the fix, the issue (network went down) occurred again just now this morning.

New Debug Log: https://tricorder.pi-hole.net/Ul2LgXxJ/

[Bucking_Horn]

Your most recent debug log still shows those speedtest remnants in configuration and version files, and your wlan0 interface is still active.

If you observe your issue again, you could try to do a lookup directly through one of your Pi-hole's upstreams, to verify whether it's accessible:

nslookup google.com 1.1.1.1

Similarly, you could investigate how Pi-hole handled queries as well as upstream replies in the most recent hour:

pihole-FTL sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT status, count(status) FROM queries WHERE timestamp > strftime('%s','now', '-1 hour')  GROUP BY status ORDER BY 2 DESC;"

pihole-FTL sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT reply_type, count(reply_type) FROM queries WHERE timestamp > strftime('%s','now', '-1 hour')  GROUP BY reply_type ORDER BY 2 DESC;"

Also try to ping 1.1.1.1 as well as google.com, to verify upstream connectivity, e.g.

ping -c 3 google.com