Pi-Hole does not respect RATE_LIMIT...... again!

This is my single problem with Pi-Hole, my entire home network goes RIP because of this problem.

I have already RATE_LIMIT=0/0 under /etc/pihole/pihole-FTL.conf
I went to unblock my 3D printer to update it and I noticed the Maximum number of concurrent DNS queries reached (max: 150)

I don't get it, this feature ( Pi-hole FTL v5.7 and Web v5.4 released ) is giving me nothing but hell and Pi-Hole is clearly not respecting settings in place.

The device is question was my Samsung SmartTV ( nothing new there ), Youtube stopped so did my phone, it was past midnight so I couldn't bother and went to bed thinking it was my ISP, go figure.

I WFH, the internet was crappy whole day because when this happens, I must reboot Pi-Hole and because it didn't fully crash, Pi-Hole02 won't assume as primary.
Why would I check Pi-Hole if I knew this change was already in place??? Right???

I will try to find a solution to move this to my OPNSense Firewall coz man, the entire goddamn network goes down when this happens.
I am sorry, I am annoyed with this.
Each Pi-Hole VM is using 20% of memory and 0.3% CPU

Tuning RATE_LIMIT won't affect your observation at all - this isn't a rate limit warning:
The system tells you that it is out of concurrent threads, so it is impossible to accept any new requests until current threads complete their work.

If you'd provided a debug token, we could've looked for hints at what may be causing this.

That message is commonly triggered by a faulty DNS configuration closing a DNS loop of sorts, or by an unresponsive upstream DNS server, or seldom by some misbehaving clients excessively requesting resolution.

So to address this, you'd have to remove the DNS loop, or pick a more reliable upstream DNS server, or configure the misbehaving client to stop making those requests.

Another possible cause next to what @Bucking_Horn mentioned is indeed a flaky Internet connection which made the upstream DNS server unreachable. As UDP DNS packets are connection-less, there is no way Pi-hole can know if the queries ever made it to the target if no reply is ever received.

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

Understood, it is annoying because every time that happens, the entire network "goes down"
In my setup, I have Pi-Hole forwarding everything to Unbound as recursive DNS running on the very same VM.

My bloody 2019 Samsung SmartTV picked 3.282 requests to cdn.samsungcloudsolution.com, that is the root cause of the problem.
Pi-Hole didn't like my Linux laptop once making a ton of API calls with Insomnia, I didn't know about the rate limit was a new feature back then.

I will whitelist these problematic domains on Pi-Hole and let OPNSense to deal with that.
To be honest I should have done this ages ago, Pi-Hole isn't firewall, I reported this because I thought it was the rate limit like before, again.

Thank you guys :slight_smile:

I will move this to OPNSense Firewall to deal with and remove this pressure from Pi-Hole + Unbound Recursive DNS.
I have whitelisted https://cdn.samsungcloudsolution.com/ to stop this drama.

Token: https://tricorder.pi-hole.net/Y4TA1a1W/

Who can access this token?
I tried to open but it shows the company GitHub organization so I cannot grant access without knowing what is happening in the background.
IIRC, I tried to open it once and it requested authentication, from what I can tell there are no sensitive data into the log but better ask

Thank you so much.

Only developers and Discourse moderators.
I don't know the exact number, but currently there are around 8 or 9 people able to open it.

You won't be able to open it.
You can see your own log at /var/log/pihole/pihole_debug.log

All good, just double checking :slight_smile:
Thank you

Your debug log shows your Pi-hole's Conditional Forwarding is disabled, and your router's DHCP server is distributing two local IPs as DNS servers.

This would rule out the most common causes for a partial DNS loop, leaving us with excessive requests or unavailable upstreams.

Likely, unblocking that domain would not affect your observation - it could even make your observation worse.

This observation may be a symptom rather than the cause.

3.000 requests are not enough to overwhelm pihole-FTL's/dnsmasq's connection pool, especially if those have been blocked. Pi-hole could handle those requests using a single connection.
Assuming that requests arrive with a 1 ms network latency, Pi-hole would be blocking them instantly within a few nanoseconds, i.e. the connection would be free long before the next request would arrive.

Now, if the request would be forwarded, then Pi-hole's upstream server's latency would determine how quick a thread could complete.

Assuming a 100 ms upstream latency, that would mean Pi-hole could free the first connection when the 101st request arrives, employing 100 connections - still not enough to exhaust the connection pool.
Furthermore, since requests are for the same domain, Pi-hole may collate those requests and not forward duplicates upstream before the first reply is received, and it would then serve replies from the cache, which again would be instantly.

But if your upstream would be unresponsive or unreachable at times, Pi-hole would have 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.

Thus, it seems most likely that your upstream is somehow causing your issue.

As you are using unbound, and unbound in recursive mode would be talking to authoritative DNS servers directly, you should probably verify if only those specific domain requests would not be answered by unbound in time, which in turn could suggest that the respective authoritative DNS servers would be unresponsive.

If it'd turn out that all of unbound's requests would time out, that could suggest an unreliable internet connection, or perhaps an incorrect time on your unbound machine.

You should investigate Pi-hole's Query Log for unbound's replies at the time of a Maximum concurrent warning.

Hi there,

First of all, thank you so much for the reply and all the info :slight_smile:

I have two Pi-Hole + Unbound recursive DNS instances so I can afford to take one down and OPNSense should do its thing to redirect the traffic..... in theory but in practice it takes a few seconds still ( topic for another day )

Dramas aside, I have moved this headache to OPNSense hopping to have a better visibility and this is what I have found:

  1. OPNSense firewall actually accepted cdn.samsungcloudsolution.com as aliases instead of IP address which are prone to change and never be static
  2. It automatically resolved that as two IPs, 184.84.165.123 and 23.46.179.91
  3. With a firewall rule in place, the log shows my bloody TV trying to access those IP:80
  4. Trying to access those address on my phone, well, it goes nowhere but an invalid HTML message from Akamai Edgeworker. It should have displayed either a 401 or 403 or the HTTP content but nope.

With all the above, your statement seems correct:

But if your upstream would be unresponsive or unreachable at times, Pi-hole would have 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.

But here comes the twist, cdn.samsungcloudsolution.com has been blacklisted on Pi-Hole from the start so Pi-Hole was never forwarding those requests out so it shouldn't be reaching its 150 requests limit because it isn't waiting for the upstream response or I got this all wrong haha

If I had it whitelisted before, yes, RIP 150 requests limit but no, something is missing here.


So anyway, the REJECT IN FROM LAN firewall rule prevents the TV's/PC request to those IP:80 from leaving OPNSense and Pi-Hole no longer even see those requests, problem solved.

Thank you so much again.

UPDATE: For the first time in ages my TV while on is no longer the most active client.
This is the way!!!

4 posts were split to a new topic: Posts removed Pi-Hole does not respect RATE_LIMIT....... again!

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.