running the app (docker version) floods router dns server with dns request of IPs (not domains)

[rezad1393]

• [ x] I have checked the existing issues to avoid duplicates
• [x ] I have redacted any info hashes and content metadata from any logs or screenshots attached to this issue

I used the sample docker to use this app. when I run this docker app my dnscrypt throws errors about

daemon.warn dnsmasq[1]: Maximum number of concurrent DNS queries reached (max: 150)
daemon.err dnscrypt-proxy[ [WARNING] Too many incoming connections

it seems that this app floods the router dns server with dns request about IPs of IPs (instead of domains)

192.168.1.101/52376 query[PTR] 146.214.167.91.in-addr.arpa from 192.168.1.101
192.168.1.101/52376 forwarded 146.214.167.91.in-addr.arpa to 192.168.1.1#55
192.168.1.101/61512 query[PTR] 53.194.97.177.in-addr.arpa from 192.168.1.101
192.168.1.101/61512 forwarded 53.194.97.177.in-addr.arpa to 192.168.1.1#55
192.168.1.101/55319 query[PTR] 166.248.102.183.in-addr.arpa from 192.168.1.101
192.168.1.101/55319 forwarded 166.248.102.183.in-addr.arpa to 192.168.1.1#55
192.168.1.101/57711 query[PTR] 149.174.162.178.in-addr.arpa from 192.168.1.101
192.168.1.101/57711 forwarded 149.174.162.178.in-addr.arpa to 192.168.1.1#55
192.168.1.101/64067 query[PTR] 196.41.104.223.in-addr.arpa from 192.168.1.101
192.168.1.101/64067 forwarded 196.41.104.223.in-addr.arpa to 192.168.1.1#55
192.168.1.101/63038 query[PTR] 119.160.99.113.in-addr.arpa from 192.168.1.101
192.168.1.101/63038 forwarded 119.160.99.113.in-addr.arpa to 192.168.1.1#55
192.168.1.101/61814 query[PTR] 37.234.162.112.in-addr.arpa from 192.168.1.101
192.168.1.101/61814 forwarded 37.234.162.112.in-addr.arpa to 192.168.1.1#55
192.168.1.101/51985 query[PTR] 244.40.92.153.in-addr.arpa from 192.168.1.101
192.168.1.101/51985 forwarded 244.40.92.153.in-addr.arpa to 192.168.1.1#55
192.168.1.101/56061 query[PTR] 252.30.227.5.in-addr.arpa from 192.168.1.101
192.168.1.101/56061 forwarded 252.30.227.5.in-addr.arpa to 192.168.1.1#55
192.168.1.101/64486 query[PTR] 206.8.189.117.in-addr.arpa from 192.168.1.101
192.168.1.101/64486 forwarded 206.8.189.117.in-addr.arpa to 192.168.1.1#55
192.168.1.101/49290 query[PTR] 230.93.68.208.in-addr.arpa from 192.168.1.101
192.168.1.101/49290 forwarded 230.93.68.208.in-addr.arpa to 192.168.1.1#55
192.168.1.101/62256 query[PTR] 29.157.159.185.in-addr.arpa from 192.168.1.101
192.168.1.101/62256 forwarded 29.157.159.185.in-addr.arpa to 192.168.1.1#55
192.168.1.101/60732 query[PTR] 184.174.162.178.in-addr.arpa from 192.168.1.101
192.168.1.101/60732 forwarded 184.174.162.178.in-addr.arpa to 192.168.1.1#55
192.168.1.101/49173 query[PTR] 107.130.66.178.in-addr.arpa from 192.168.1.101
192.168.1.101/49173 forwarded 107.130.66.178.in-addr.arpa to 192.168.1.1#55
192.168.1.101/53000 query[PTR] 219.132.187.188.in-addr.arpa from 192.168.1.101
192.168.1.101/53000 forwarded 219.132.187.188.in-addr.arpa to 192.168.1.1#55
192.168.1.101/59901 query[PTR] 82.54.62.92.in-addr.arpa from 192.168.1.101
192.168.1.101/59901 forwarded 82.54.62.92.in-addr.arpa to 192.168.1.1#55
192.168.1.101/57042 query[PTR] 145.173.233.193.in-addr.arpa from 192.168.1.101
192.168.1.101/57042 forwarded 145.173.233.193.in-addr.arpa to 192.168.1.1#55
192.168.1.101/49696 query[PTR] 189.10.239.120.in-addr.arpa from 192.168.1.101
192.168.1.101/49696 forwarded 189.10.239.120.in-addr.arpa to 192.168.1.1#55
192.168.1.101/50442 query[PTR] 9.153.94.113.in-addr.arpa from 192.168.1.101

and this flood of equerries causes the dns-server to refuse serving dns answers.

• Bitmagnet version: [latest docker version]
• OS and version: [archlinux]

[jduerstock]

This happens without Docker as well. A flood of DNS requests for the bootstrap nodes also occurs, which seems horribly wrong.

[rezad1393]

This happens without Docker as well. A flood of DNS requests for the bootstrap nodes also occurs, which seems horribly wrong.

I wanted to specify so that if the bug was only present in docker then the dev(s) could narrow it down.
but your report helps too so.
thanks for confirming it.

I still don't understand the flooding even for non dns requests, but this is for requesting IPs of IPs (instead of domains) so it has to be a bug.

[bentrop]

This issue brought my home network to its knees, and it took me far too long to trace it back to Bitmagnet. Reducing the DHT_CRAWLER_SCALING_FACTOR does little to nothing to fix it.

I also could swear this only started about a week ago (around the time this issue was opened) - at least I didn't notice it earlier. But, as far as I can tell, there hasn't been a new docker release in over two months?

Is there another trigger or threshold that could have exacerbated this bug?

I'm running the docker container as well.

[rezad1393]

This issue brought my home network to its knees, and it took me far too long to trace it back to Bitmagnet. Reducing the DHT_CRAWLER_SCALING_FACTOR does little to nothing to fix it.

I also could swear this only started about a week ago (around the time this issue was opened) - at least I didn't notice it earlier. But, as far as I can tell, there hasn't been a new docker release in over two months?

Is there another trigger or threshold that could have exacerbated this bug?

I'm running the docker container as well.

maybe I cursed it?

by the way, a similar issue was present with magnetico (the other dht crawler) but that one was managed by something like that DHT_CRAWLER_SCALING_FACTOR.

this issue is present at the start and it seems to go away after a while.
not a small amount of time but I didn't check to reproduce the time it takes to go away cause it makes my dns server give empty answer for whole network

[mgdigital]

Are you by any chance using an OpenWRT router? This sounds like it might be a duplicate of #299

Routing Bitmagnet through a VPN might help in this case.

The Bitmagnet code is not making any DNS queries directly (with the exception of the bootstrap nodes), it's just using the standard networking libraries.

[rezad1393]

Are you by any chance using an OpenWRT router? This sounds like it might be a duplicate of #299

Routing Bitmagnet through a VPN might help in this case.

The Bitmagnet code is not making any DNS queries directly (with the exception of the bootstrap nodes), it's just using the standard networking libraries.

I am using openwrt but my issue is not the same as that one.

mine is exactly because of dns requests that make both dnscypt and dnsmasq go:

daemon.warn dnsmasq[1]: Maximum number of concurrent DNS queries reached (max: 150)
daemon.err dnscrypt-proxy[ [WARNING] Too many incoming connections

if I have a download running before running bitmagnet , that still has its own bandwidth because it already has the dns-ip it needed.

so to repeat, my issue is not network coming to a standstill because of weak cpu in router.
network works.
my issue is that this app floods the dns server with ip request that are actually IPs instead of domains.

I have put the dns request at the top as you can see.
it is not asking for IPs of bootstraps.
it is doing this:
query[PTR] 166.248.102.183.in-addr.arpa from 192.168.1.101

so it is asking the dns server what is IP of domain 166.248.102.183.in-addr.arpa

asking for IP for an IP is incorrect but that is one issue.
flooding dns server causes this bug.

[mgdigital]

my issue is that this app floods the dns server with ip request that are actually IPs instead of domains.

There simply isn't any code in Bitmagnet that does this. I suspect it's a software (not hardware) issue with OpenWRT routers. Many OpenWRT users have already raised issues both here and on Discord. The best workaround that's been found is running Bitmagnet through a VPN. I don't have an OpenWRT router to test with myself but you might be able to get help from other users on Discord: https://discord.gg/6mFNszX8qM

[rezad1393]

my issue is that this app floods the dns server with ip request that are actually IPs instead of domains.

There simply isn't any code in Bitmagnet that does this. I suspect it's a software (not hardware) issue with OpenWRT routers. Many OpenWRT users have already raised issues both here and on Discord. The best workaround that's been found is running Bitmagnet through a VPN. I don't have an OpenWRT router to test with myself but you might be able to get help from other users on Discord: https://discord.gg/6mFNszX8qM

I think I found out some more info.
the chaining of dnscrypt and dnsmasq causes this.
maybe it somehow creates a loop.
I make dnsmasq the only server in dns chain and it fixed this issue.

so I will close this and see what causes it.

but I didn't see this loop before with any other apps.

[rezad1393]

weird I reverted my "fix" and the issue is no longer there.
so my fixing didnt fix it.
it was fixed before somehow.
so it seems the issue was not the openwrt issue.

[rezad1393]

update:
I again got this bug.
running the app floods my dns server.

I even disabled dnscrypt.

[Rapiere]

Please note I have similar network degradation while using Synology routers, I could pinpoint the issue back to Bitmagnet but still unclear what's producing the network overload. It's happening with v0.9.5, however I could eventually managed to make it work with latest v0.10.0-beta5 through gluetun, will keep posted.

[victornavorskie]

i have same issue while using Fritz box router tried DHT_CRAWLER_SCALING_FACTOR 5 not helping