How to find a noisy client? Maximum number of concurrent DNS queries reached

Help
1

I have a standard install of pinhole on a raspberry pi. My router at 192.168.1.1 is set to use 192.168.1.24 as its DNS. That is the address of my pihole.

Expected Behaviour:

I get very many "Maximum number of concurrent DNS queries reached" errors. I have read many similar help requests - many of them though appear to involve complex setups. Because my setup is straightforward, I think it must be a client that is sending too many DNS requests.

Could someone please give me advice as how to find the client that is noisy? Is there a log on pihole that will tell me this? I found in the pihole admin page the queries.php page - however this says all requests are from the router (which makes sense, but doesn't help me find the bad client).

Any help would be appreciated - thank you.

Debug Token:

https://tricorder.pi-hole.net/RCR7fINL/

2

"Maximum number of concurrent DNS queries reached" often suggests a DNS loop of sorts, but as your debug log doesn't show any hints of such a loop, I agree that your observation is caused by misbehaving client(s).

You likely won't be able to immediately single out the offending client(s) with Pi-hole (click for more)

Since your router is configured to make use of Pi-hole as its upstream DNS server, your clients will talk to your router for DNS, and your router will aggregate traffic from all of its clients and forward it to Pi-hole.

In such a router's upstream configuration, there would be no way to directly observe individual clients in Pi-hole (unless your router can be configured to enable EDNS(0) Client Subnet (ECS) - not many consumer routers support that specific configuration option).

If your router supports it, you could consider to distribute Pi-hole as local DNS server via DHCP instead. Usually, that is a LAN/DHCP option, but not all routers allow changing it. If yours would support it, note that clients won't pick up that new configuration until they've renewed their DHCP lease.
In such a local DNS server configuration, clients would talk directly to Pi-hole for DNS, allowing you to attribute DNS requests to inidividual client IPs in Pi-hole's query log.

If you can't apply ECS nor use Pi-hole as local DNS server with your router, you'd have to resort to other means.

Sometimes, a look at Pi-hole's statistics may hint at device(s), e.g. a lot of apple.com requests may hint at some respective equipment.

To that end, what's the result of the following commands, run from your Pi-hole:

echo ">stats >quit" | nc localhost 4711

echo ">top-domains (12) >quit" | nc localhost 4711
1 Like
3

Thank you for your helpful reply Bucking_Horn. I have an Orbi RBR50 router and I am going to look to see if it supports EDNS(0) Client Subnet (ECS) or whether I can distribute pi-hole as a local dns server via DHCP (I don't know what these mean yet, but I'll look them up).

In the meantime, here is the output of those commands:

echo ">stats >quit" | nc localhost 4711
domains_being_blocked 101236
dns_queries_today 280308
ads_blocked_today 8887
ads_percentage_today 3.170441
unique_domains 9793
queries_forwarded 258603
queries_cached 9969
clients_ever_seen 6
unique_clients 6
dns_queries_all_types 280308
reply_NODATA 12954
reply_NXDOMAIN 84591
reply_CNAME 38642
reply_IP 19942
privacy_level 0
status enabled

echo ">top-domains (12) >quit" | nc localhost 4711
0 76590 lb._dns-sd._udp.0.1.168.192.in-addr.arpa
1 43490 db._dns-sd._udp.0.1.168.192.in-addr.arpa
2 43394 b._dns-sd._udp.0.1.168.192.in-addr.arpa
3 23958 lounge-room-185.openthread.thread.home.arpa
4 4678 la3-c1-ph2.ph2.r.salesforceliveagent.com
5 3010 gateway.fe.apple-dns.net
6 1932 www.google.com
7 1702 play.google.com
8 1670 www.netgear.com
9 1474 mobile.l.google.com
10 1428 ssl.gstatic.com
11 1350 star-mini.c10r.facebook.com
4

That's an appleTV btw. In case that is doing something.

5

Those would suggest that you have have some Apple devices which are trying to issue OpenThread-related service discovery queries. Apple seems to have rolled out premature support of some yet just drafted DNS-SD behaviour.

From the discussion at Rate limit due to openthread queries - #23 by Coro, it seems yet unclear why some Apple devices would expose such a misbehaviour while others don't.
I don't think that any of the CNAME measures discussed there would have any effect, but the current last post in that topic claims that Apple may have fixed the behaviour with its recent OS upgrades.

1 Like
6

Great - thanks for this. This evening I will update the appleTV and see how it goes. If that doesn’t help, I’ll turn it off and see what that does. I’ll get back in couple of days. Thanks

7

Thanks for your advice. I have been monitoring my system after updating every apple device we own. It appears that the upgrade has worked. I have no warning messages about rate limits any longer. The top permitted domains are still all arpa ones, but it doesn't appear to be causing a problem any longer.

I am now only getting an error from DNSMASQ core about packet sizes. I will look into that. Thanks for your help.

1 Like
8

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