Hi everyone, I was hoping that everyone could give me an insight on this. A couple months ago I started facing the issue where I get in my Pi-hole diagnosis.
" DNSMASQ_WARN Warning in
dnsmasq core: Maximum number of concurrent DNS queries reached (max: 150)"
I'm not a networking professional and my knowledge is limited so, since this always happens around early morning and around noon/past noon, I wanted to see if there's a way I could find whether this error is a Network issue, or ISP issue to take the proper claim to them and tell them the internet is having an outage twice every day.
This is also happens at the same time I am working and/or someone on the house is. It's a pain to be on a meeting and get dropped for 2 to 5 minutes until internet comes back.
** I'm running Unify gateway and AP with a Pi-Hole on a RaspberryPi 3b.
This is a home/home office setup since we do remote work from here too.
Although my Unify AP is not routing anything because the ISP would not let me use the router in bridge mode (*shucks).
*Pi-hole version is 5.17.1
Here's the log token in case anyone can help > https://tricorder.pi-hole.net/8Cflqngu/
I don't have a direct answer but If you search the forum there are quite a few posts on the subject. One of those solutions may work for your situation.
Thank you sir! I did in fact search some topics before posting. The thing is I couldn't find any "mechanism" to be able to diagnose if this is an issue with my network/pihole config or the ISP just dropping me four times a day. In fact I was just on a meeting right now and I got disconnected again for just 2 minutes, same behavior as always. I need to understand if this is my problem or the provider's
Sounds like you've created a DNS loop or partial loop somewhere.
This can happen if you've configured Pi-hole's "Conditional Forwarding",
plus configured the Pi-hole IP in the WAN/Internet DNS settings on the router which is a common mistake made.
Some or all DNS queries will just bounce back and forth between router and Pi-hole untill rate-limiting kicks in or resources are depleted.
Like in your case with: "Maximum number of concurrent DNS queries reached".
Or if you've applied some kind of DNS redirecting on the router without exempting the Pi-hole host which would also close a loop.
Below is the preferred way to configure the router for Pi-hole (via the LAN DHCP service):
If you're absolutely sure there is no DNS loop, you could try tweaking with below dnsmasq directive if the HW is beefy enough:
$ man dnsmasq
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 us‐
ing web-server log file resolvers, which can generate large
numbers of concurrent queries.
The dnsmasq code is embedded into the pihole-FTL binary.
Hi Hakke, thanks a lot for taking the time to reply.
I've double checked in case I've forgotten and Conditional forwarding is not enabled on my pi-hole. Below a couple screens with DNS config.
Additionally, DHCP server is not enabled for my Pi-Hole, but I do have it configured as primary DNS within my network's router:
So as I said before, this happens in particular and specific times of the day. The purpose of my question was to see if anyone (clearly not me) that is well versed in networking and the Pi-Hole system could guide me through finding if this is the ISP just having an outage in the morning and afternoon for any particular reason. Or if -on the other hand- there's something wrong with my pihole
THanks a lot again!
Question on your setup. You have google and opendns as upstream servers. Whats the purpose of the custom upstream server which appears to be on a differnet local network?
Well that's actually a good catch. It seems that IP is kind of a leftover from an old network setup and it's there because I imported the config from that old setup.
10.0.0.2 does not exist now and it's actually 192.168.1.2. This is because -as I mentioned before- my ISP does not allow bridge mode for the router, so my local router is sitting on .2 using .1 as gateway, but providing DHCP and the rest of the network related features.
IIRC, someone recommended that I have that 10.0.0.2 sitting as upstream DNS, when it actually was my local router's IP.
Can you provide any insight on whether I should configure that as my local router or not?
Also, could that be causing the issue as it is?
In the meantime I'll go ahead and delete that record since it's pretty much useless
That is a setup I do not have experience with so not sure. I would image that if 192.168.1.2 was set as a custom DNS and were to be used it may cause a loop if either router pointed back to the pihole.
If removing that old entry did nothing for the issue ( guessing it didn't ) all I can suggest is uploading a new log ( tools >debug ). I think those only last for 2 days so you old one might be expired and a dev / moderator will likely need a new one.
Cool, thanks Call.
Like I said these disconnections and errors are happening around morning and at noon, around those times.
I've removed the config for the non existent DNS but will probably have to wait until tomorrow to se an outage. I sincerely hope that was the issue, otherwise ill have to keep digging and file a complain with the ISP.
**Edited first post with a new token.
Some (or all) of your issues may be minimized or eliminated by possibly making some configuration changes. I have a UDM-SE (Ubiquity) with Pihole acting as my exclusive LAN DNS server on a Raspberry Pi device. The DNSMASQ_WARN messages you are getting may be caused by your Unify gateway getting all the DNS requests from your LAN clients and sending them directly from your gateway to your Pihole.
To help with that, I set my UDM-SE to bypass Pihole, but DHCP tells all the LAN clients to use Pihole.
In the "new" Unify interface (not Legacy), under Internet click on your WAN connection and scroll down to IPv4 Configuration. For DNS Server, you can use "Auto" which will likely use your ISP-provided DNS server, or you can uncheck Auto and choose a public DNS server. This effectively tells your Unify network devices (only!) to bypass Pihole, thus eliminating network management traffic from the Pihole.
Then go to Networks and click on your network name. Scoll down to DHCP/DHCP Service Management (click on "Show Options"). Scroll down to "DNS Server" and remove the check mark by "Auto"; enter the IP address of your Pihole device. Apply this change and do the same for any other network name (VLAN) you have created.
You should no longer get these same DNSMASQ_WARN messages about your gateway, but all your LAN clients will still use Pihole. The clients will be directly sending Pihole the DNS requests, instead of them first going to your gateway and your gateway sending them all to the Pihole from one source.
Hope that makes sense!
As your ISP would not send you any DNS requests, it is very unlikely that it would be involved in your observation of maximum concurrent DNS queries.
nprampage's suggestions seem more likely to prove helpful.
Hi Nprampage. Thanks for taking the time to reply.
As it turns out. The "Internet" part of the Unify was already configured as you mentioned, using "auto" as DNS server.
On the other hand, within Networks, the DHCP DNS Server was set as 192.168.1.1 which is the ISP router, this is probably because I used this as a failsafe measure while testing Pi-Hole couple years ago, since my ISP won't let me use bridged connection to manage internet with my Unify Gateway and their modem is also a router with DHCP.
I changed DNS server in Unify to 192.168.1.1 and also removed the 10.0.0.2 on the upstreams that was useless.
I couldn't perform much tests but all I can say is that I started working this morning and I had a brief outage, which led me to believe that these are actually an ISP issue. But also, when I checked the Pi-hole diagnosis I didn't see the DNS_MASQWARN error that I was seeing every time I got disconnected.
Don't know if this makes any sense at this point but anyway thanks for the support. I will keep checking today if I keep getting these outages and if/when I get them I'll check the pi-hole diagnosis again.