What to do when you reach maximum allowed DNS requests

Help Community Help
1

The issue I am facing:
Some device on the local network is exceeding the maximum allowed number of DNS requests.

Basically can't access internet.

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.

DNSMASQ_WARN Warning in `dnsmasq` core:
 
Maximum number of concurrent DNS queries reached (max: 150)

Details about my system:
Running Pihole on Raspberry Pi Zero W with
Unbound as Upstream DNS.
DNSSEC is enabled
DHCP is not enabled
Conditional forwarding is not enabled

I suspect that the abusive device is a Roku Streaming Player.
It looks like it knows it is dealing with a Pihole and is just brute forcing it to jam the Pihole???

Is there any workaround for abusive devices?

 echo ">top-clients >quit" | nc localhost 4711
0 16281 :: pi.hole
1 13397 192.168.0.89 Roku

 $ echo ">top-ads >quit" | nc localhost 4711
0 7650 scribe.logs.roku.com

Look at the query log
13 QUERIES PER SECOND

Apr  4 22:44:20: query[A] cloudservices.roku.com from 192.168.0.89
Apr  4 22:44:20: exactly blacklisted cloudservices.roku.com is 0.0.0.0
Apr  4 22:44:20: query[A] scribe.logs.roku.com from 192.168.0.89
Apr  4 22:44:20: gravity blocked scribe.logs.roku.com is 0.0.0.0
Apr  4 22:44:20: query[A] cloudservices.roku.com from 192.168.0.89
Apr  4 22:44:20: exactly blacklisted cloudservices.roku.com is 0.0.0.0
Apr  4 22:44:20: query[A] scribe.logs.roku.com from 192.168.0.89
Apr  4 22:44:20: gravity blocked scribe.logs.roku.com is 0.0.0.0
Apr  4 22:44:20: query[A] scribe.logs.roku.com from 192.168.0.89
Apr  4 22:44:20: gravity blocked scribe.logs.roku.com is 0.0.0.0
Apr  4 22:44:20: query[A] scribe.logs.roku.com from 192.168.0.89
Apr  4 22:44:20: gravity blocked scribe.logs.roku.com is 0.0.0.0
Apr  4 22:44:20: query[A] scribe.logs.roku.com from 192.168.0.89
Apr  4 22:44:20: gravity blocked scribe.logs.roku.com is 0.0.0.0
Apr  4 22:44:21: query[AAAA] hulu.com from 192.168.0.89

Long term Data shows in the last 7 days 65,000 queries to scribe.roku.com

2

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

By themselves, none of those numbers look overwhelmingly scary.
13 queries per second per client wouldn't yet trigger Pi-hole's default rate limit of 1,000 requests per minute, and they wouldn't be nearly enough to trigger Pi-hole's Maximum number of concurrent DNS queries reached warning.

At what time did that warning register in Pi-hole's log?
You should then take a look at the DNS requests directly preceeding that warning.

3

If I understood right, in my case there are less than 1000 requests per minute, so the issue could be with Unbound not Pihole.

I don't know why the debug log is taking hours, and never generates. Tried it few times.

I rebooted the pihole, and unbound and that resolves the issue for the time being.

Next time it shows the warning, I will look at the time and go through the log.

Thank you @Bucking_Horn

4

I have a similar issue with my phone when I started using my Tailscale VPN. I never had this issue before and I understand there is a certain amount that Pi-hole or Raspberry Pi can handle. But before the update, I never had any issues or problems. I just want to increase the max size of the concurrent queries, not disable it.

1 Like
5

Thank you for letting me know MrAnderson.
I am not sure if increasing the size will help in the long run.

Do you use DNSSEC? You can check in
https://pi.hole//admin/settings.php?tab=dns
Under Advanced DNS settings:

I had DNSSEC enabled.
I unchecked "Use DNS" and all my issues instantly vanished. Pihole works just like before.

Looking back at the Pihole-FTL.log I noticed a lot of errors

ERR: Port mismatch for 192.168.1.1: we derived 53, dnsmasq told us 48

And a lot of these errors
/var/log/pihole.log

 dnsmasq[513]: dnssec-retry[DNSKEY] . to 192.168.1.1

It makes me think that this might be the issue.

Unchecking DNSSEC solved it all, I believe.

6

Not quite.

I'm not discarding the idea of your Roku playing a part in this, but the numbers you've quoted don't bear significance unless you can directly connect them to that *max concurrent* warning, e.g. by means of the logs I suggested to scrutinise (click for details)

You are correct in assuming that using unbound as an upstream recursive resolver along with DNSSEC enabled in Pi-hole may tip the balance for an increased load (as recursion takes longer, and DNSSEC multiplies the number of actual DNS requests Pi-hole would forward upstream).

However, those factors would not come into play for blocked domains, as those are handled by Pi-hole exclusively alone and never forwarded upstream, usually completing in under a millisecond.

When viewed in isolation, your 13 requests per second would roughly translate to one request every ~77ms. But to trigger the warning, DNS requests must arrive faster than Pi-hole can respond to them. For those 13 blocked requests, that wouldn't even happen if Pi-hole would process them strictly sequentially (i.e. with no concurrency at all). Pi-hole would idle for ~76 ms before the next request would arrive.

To reach a volume of DNS queries high enough to trigger that max concurrent warning in that isolated example, your client would have to issue well over 1,000 requests per second - but long before that would have happened, Pi-hole's per-client rate limt of 1,000 requests per minute would have kicked in, and you likely would have noticed a different message instead (e.g. Rate-limiting 10.0.1.39 for at least 44 seconds).

(Of course, that isolated view is not taking into account DNS activity of your other clients, but it should still give you a better idea what's involved)

Often, a DNS loop may trigger excessively high volumes of DNS traffic.
But in your case, we can at least rule out a partial DNS loop caused by Conditional Forwarding, as you've reported that to be disabled.

So without further analysis, we won't know what triggered your warning.

Since analysis of sally's observation isn't complete, I wouldn't be too sure about MrAnderson175's issue being related. For a start, sally's observation does not comprise a VPN, and the device in question is not a smartphone.

While that linked issue produces unwanted log errors, it wouldn't affect DNS processing:

I'm glad if disabling DNSSEC has solved your issue (unbound still does DNSSEC verification in your case, so you don't really lose anything), but that may have been coincidental.

1 Like
7

My setup is Pi-Hole, Unbound as upstream, and Tailscale for VPN, but use Pi-Hole as it's upstream DNS. I followed the official installation guides on Pi-Hole for Unbound and on Tailscale's website for installation on Bullseye 64bit. I use DNSSEC because of Unbound and only forward port 5335 for DNS upstream cause that's what's mentioned on the guide.

Again, I never had the issue of RATE_LIMIT warning, or DNSMASQ_WARN of max concurrent queries reached, which is 150.

8

That sounds very much like yours would be a different observation altogether.
You could consider to open a new topic if you'd like specific support for your issue.

1 Like
9

Got it, I'll do that one and once I get back I'll redo my setup as it was.

10

I posted the new topic but probably won't be back until later tonight to get the logs of when the warnings are triggered.

11

A post was merged into an existing topic: DNSMASQ_WARN for Max Concurrent Queries (max is 150) when using VPN or when using Pi-Hole as local network DNS with 35+ devices

12

I has been almost 3 weeks since I disabled DNSSEC on Pihole, and I haven't seen any of the myriad issues I had, works like before.

Disabling DNSSEC was a simple fix.

13

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