As well as a number of other users who have reported this in this forum, I as well have been hit by the infamous ‘Excessive DNS requests’ bug.
I have summarized my findings and mitigation here, to help other owners of the cam.
Description of the bug
When the WyzeCam 3 (newest firmware 4.36.9.139 as of today, 29 June 2022) is running for some time (from a few hours to a few days, the trigger is unknown) it at one point suddenly starts to send out MASSIVE amounts of UDP DNS requests to Google DNS servers 8.8.8.8 and 8.8.4.4, as well as to the internal DNS server (assigned by DHCP), with burst in the hundreds per second. Once the camera is in this ‘DNS spamming-mode’, it will not stop, the only way to temporarily return to normal operation is to power-cycle the camera. Switching the camera off and on from the Wyze app does not get it out of this mode.
The router connection log contains thousands of entries like this :
Network Protocol Source Destination Transfer
IPV4 UDP 192.168.88.51:53361 8.8.8.8:53 136 B (2 Pkts.)
IPV4 UDP 192.168.88.51:57484 8.8.4.4:53 136 B (2 Pkts.)
IPV4 UDP 192.168.88.51:49172 8.8.8.8:53 136 B (2 Pkts.)
IPV4 UDP 192.168.88.51:32963 8.8.8.8:53 136 B (2 Pkts.)
IPV4 UDP 192.168.88.51:36869 8.8.8.8:53 136 B (2 Pkts.)
IPV4 UDP 192.168.88.51:60514 8.8.4.4:53 136 B (2 Pkts.)
IPV4 UDP 192.168.88.51:48472 8.8.4.4:53 136 B (2 Pkts.)
IPV4 UDP 192.168.88.51:35756 8.8.8.8:53 136 B (2 Pkts.)
…
Interestingly, despite the heavy DNS traffic, the camera continues to function, so from outside things look quite normal.
I have seen some bug-apologist arguing in another thread that this additional traffic does not matter, because the volume is small – And he is right, the data volume of the DNS requests itself is not an issue, a few MB per day. But the actual problem with this bug is the high frequency of the requests : Apart from spamming Google with DNS queries, it stresses the router as the requests are coming faster than they can be answered, to the point of slowing everything down, dropping packets, and even router crashes and reboots. In fact, this is how I noticed the issue in the first place, my OpenWrt router logged ‘nf_conntrack: table full, dropping packet’ messages due to reaching the default max of 16384 open network connections ! Trying to view the open connections list then crashed the web-interface of OpenWrt due to the size of the log. As a comparison, even with dozens of other devices connected to the router and heavy PC usage the open connections normally hardly exceed a total of 1000.
Imagine what this bug does to the underpowered ISP-provided home router that most people use… And as only nerds like me look at router logs, most owners will never know what hit them !
It seems that this bug has existed for quite some time. It has been reported to Wyze support and in the forums multiple times, and at one point in 2021 had been fixed in a firmware update, only to re-surface again later. Wyze support seems to be unwilling or unable to finally fix the issue.
Mitigation
Someone in another post suggested that if you insert an SD card into the camera, the bug may disappear. I actually tried that, and you guessed it, it doesn’t.
But if you are using a router with a sophisticated firewall, you can mitigate the issue.
The first obvious firewall idea to just block the outgoing Google DNS requests does not work. If this is done, then the cam cannot be switched on from the Wyze app anymore, the app errors when trying to connect to the camera.
What actually DOES work is creating firewall rules that limit packets per time interval of the external and internal DNS requests from the camera, i.e. only allow up to 1 external Google DNS request every 3 seconds, and up to 5 internal DNS request per second (The limit for the internal DNS requests can be higher, because queries are answered from the cache. A limit is still necessary, without limit the cam is at times hammering the internal DNS server faster than it can answer).
With these rules in place everything on the camara, i.e live view, motion detection, sound, recording, etc. works fine. The only minor issue is that switching the camera on using the Wyze app does not always work on the first try, it may require 2 or 3 retries.
The firewall rules are targeting a specific camera by IP address, so the first thing to do is to assign a static IP lease for the camera in the DHCP configuration of the router.
Also make sure your camera(s) are located in a different IP subnet than the router’s DNS server, so that the packets go through the firewall. In OpenWRT this can be done by creating a new bridge network device with its own IP subnet, then creating a new firewall zone for this bridge, and assigning the bridge to its own WiFi network and SSID.
For OpenWRT, the 4 firewall rules are :
( My camera’s IP address is 192.168.88.51, located in the firewall source zone inetzone, you would need to adapt these parameters )
Traffic rule 1 allows only up to 40 DNS packets (i.e. 20 DNS queries, one query de facto has 2 packets) per minute :
Name : WyzeCam limited Google DNS
Protocol : TCP, UDP
Source Zone : inetzone
Source Address : 192.168.88.51
Source Port : any
Destination Zone : wan
Destination Address : 8.8.8.8, 8.8.4.4
Destination Port : 53
Action : accept
Limit Matching : 40/minute
Rule 2 blocks traffic in excess of the first rule :
Name : WyzeCam block Google DNS
Protocol : TCP, UDP
Source Zone : inetzone
Source Address : 192.168.88.51
Source Port : any
Destination Zone : wan
Destination Address : 8.8.8.8, 8.8.4.4
Destination Port : 53
Action : reject
Rule 3 allows only 10 DNS packets per second to the internal DNS server :
Name : WyzeCam limited internal DNS
Protocol : TCP, UDP
Source Zone : inetzone
Source Address : 192.168.88.51
Source Port : any
Destination Zone : Device (input)
Destination Address : blank
Destination Port : 53
Action : accept
Limit Matching : 10/second
Rule 4 blocks traffic in excess of rule 3 :
Name : WyzeCam block internal DNS
Protocol : TCP, UDP
Source Zone : inetzone
Source Address : 192.168.88.51
Source Port : any
Destination Zone : Device (input)
Destination Address : blank
Destination Port : 53
Action : reject
These 4 rules need to be placed before any other rules, which allow DNS for all devices in the zone.
If you have more than one camera, then it would be best to duplicate rule 1 and 3 for each camera, so that each camera gets their fair share of accepted DNS requests. You may also then need to reduce the allowed frequency per camera.
Rule 2 and 4 can be extended by just adding the IP address(es) of the additional cameras to the existing rules.
I have tested over a few weeks, with these rules in place everything is stable, without the WyzeCam 3 making my router sick anymore…
Now I may wish for too much here, but if Wyze could just tweak their bug a little a bit, to send DNS requests less frequently, then users could fully enjoy using their cameras without having to fiddle around with router firewall rules !