Maximum number of concurrent DNS queries reached?

Hi,

Since a week or two I'm getting this error in my log. It happens a few times per day and seems to align with getting my internet connection really unresponsive while i'm not doing much (just some light browsing).

Tue Jan 11 21:25:51 2022 daemon.warn dnsmasq[3935]: Maximum number of concurrent DNS queries reached (max: 150)

My router is a R7800 with latest 21.02.1. Installed packages are https-dns-proxy, nlbwmon and luci-statistics.

Unfortunately, I don't know how to start debugging this, which user is responsible for this.

I found a reference that also report this:

The same issue is described but the root cause seems not to be found (only delayed).


config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'
	option ednspacket_max '1232'
	option noresolv '1'
	option doh_backup_noresolv '-1'
	list doh_backup_server ''
	list server '127.0.0.1#5054'
	list server '127.0.0.1#5053'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled 'false'

config include
	option path '/etc/firewall.user'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option dest_ip '192.168.1.125'
	option name 'XBoxOne'
	option src_port '3544'
	option src_dport '50426'
	option dest_port '50426'
	option proto 'tcp udp'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option dest_ip '192.168.1.126'
	option name 'XBox360'
	option proto 'tcp udp'
	option dest_port '3074'
	option src_dport '3074'

config redirect
	option src 'wan'
	option name 'XBoxX'
	option target 'DNAT'
	option dest 'lan'
	option dest_ip '192.168.1.132'
	option dest_port '50007'
	list proto 'tcp'
	list proto 'udp'
	option src_dport '50007'


You can extend those values in the config dnsmasq stanza of /etc/config/dhcp, dnsforwardmax and cachesize.

1 Like

You can extend those values in the config dnsmasq stanza of /etc/config/dhcp , dnsforwardmax and cachesize .

That's what @xiaobo did.
My point was that this Dnsmasq behavior only started recently without any change to my network or clients/programs. There has to be a reason why Dnsmasq starts "complaining". The original 150 queries never was a problem before.
Also, will extending the proposed values get rid of the symptom of unresponsiveness? (I will try it).

Is there a way to see which client could be responsible for the extra DNS queries?

Are you sure ? an updated app could be enough for this to happen ....

1 Like

I realize that. In my case apps get updated frequently and never produced any problems or similar issues.
When it happens it clogs the internet connection for like a minute which is very annoying and goes beyond a remark in the system log.

So i would like to investigate it further but have no idea how to trace the culprit (like client or app).

if you're not using adblock or anything else requiring you to host your own DNS, you could redirect your clients to 8.8.8.8 or whichever DNS you'd like, on internet.

Not so elegant but it should do the job. Paste the following into /etc/firewall.user, changing the network if necessary.

NET="192.168.1."
iptables -N DNSCOUNTER
iptables -I INPUT -m udp -p udp --dport 53 -j DNSCOUNTER
IP=2
while [ $IP -le 254 ]
do
iptables -A DNSCOUNTER -s $NET$IP -j RETURN
let "IP+=1"
done

After restarting the firewall, it will create a chain that will count the DNS traffic, originating from each lan IP address.

Sort the results by the number of packets.

iptables -nvL DNSCOUNTER | sort -nr
1 Like

@Jack007 try it

	option ednspacket_max	1232
	option cachesize '10000'
	option dnsforwardmax '10000'
	option dhcpleasemax '10000'

I want to give this a try. One question; The router is using dns-https-proxy.

Should this be altered?

iptables -I INPUT -m udp -p udp --dport 53 -j DNSCOUNTER

TIA

The script (?) seems to be running. After a short time this is the result:

/etc$ iptables -nvL DNSCOUNTER | sort -nr
   15  1035 RETURN     all  --  *      *       192.168.1.40         0.0.0.0/0           
    8   528 RETURN     all  --  *      *       192.168.1.30         0.0.0.0/0           
    3   207 RETURN     all  --  *      *       192.168.1.177        0.0.0.0/0           
    1    69 RETURN     all  --  *      *       192.168.1.100        0.0.0.0/0           
    1    61 RETURN     all  --  *      *       192.168.1.101        0.0.0.0/0

I guess i should focus on the first number (like 15, 8 and 3,....)?

I let it running for the next days. Let's see what cums up.
Remarkable; 192.168.1.40 is my thermostat (Honeywell Evo). I didn't expect that.

does it have some kind of cloud based integration ?
like remote control, via app, etc ?
in that case it'll be polling some internet host, frequently.

1 Like

Yes it does.

No. The initial request is sent to port 53 of the router.

The first number is the number of packets. The second is the amount of traffic in bytes.

1 Like

Just a little feedback on this issue.
It most probably turns out that my ISP modem is the culprit. If I put a load on the device (like starting a few torrents) it seems to stress the modem that much that it spontaneous reboots (I don't know if it always reboots or can recovers before a reboot).

|10-02-2022 15:36:47|warning|MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xx:xx:xx:xx:xx:xx:xx:xx;CMTS-MAC=xx:xx:xx:xx:xx:xx:xx:xx;CM-QOS=1.1;CM-VER=3.0;|
|---|---|---|
|01-01-1970 01:01:25|notice|Cable Modem Reboot - due to power reset;CM-MAC=xx:xx:xx:xx:xx:xx:xx:xx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0;|

As others suggested the reboot results in a lot of missing DNS requests.

After some reading up on this modem (Compal CH7465LG) it turns out that its not uncommon for it to loose stability under load (because of the Intel Puma chipset?).

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