What's new

Wyze cams and Quad9 DNS-over-TLS issue

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

OzarkEdge

Part of the Furniture
I have three Wyze cams, one v2 and two v3... (The Wyze IoT ecosystem has gone off the rails, imo, and I'm not surprised.)

It appears that these cams cannot be setup/added when using the ASUS preset servers 1,2 settings for Quad9 DNS-over-TLS/DoT (9.9.9.9, 149.112.112.112, dns.quad9.net, strict/opportunistic) and with AiProtection disabled. The cams respond, 'connection timed out, try again'.

If you leave the DNS servers 1,2 settings for Quad9 and disable DoT, the cams setup/add normally with/without AiProtection enabled. After cam setup, you can enable DoT and continue to use the cams normally (as far as I know... the Wyze app has become full of crap I don't use).

This cam issue first presented at both nodes of my 2xRT-AC86U wireless AiMesh, and continued with my current network which seems to be working fine.

Feel free to comment on what might be happening on all fronts... the ASUS implementation of DoT and presets for Quad9 (?); Quad9's role, if any; and whatever Wyze is trying to do.

I would also like to better know how AiProtection and DNS filtering such as Quad9 interoperate/coexist, but this is not directly related to the cam/DoT issue.

OE
 
Interesting problem.
With the cams using the router DHCP they should be assigned the router IP address as the only DNS resolver. That means the cams are going through Dnsmasq to resolve URL's. With DoT enabled, Dnsmasq goes to Stubby/GetDNS instead of using the DNS resolvers in WAN/DNS Server 1 & 2.
With DoT enabled, Dnsmasq uses file /tmp/resolv.dnsmasq to communicate internally on loop back address 127.0.1.1 port 53 and Stubby is set to listen on the same address and port. The question, therefore, is Stubby having issues communicating with Quad9? To see what Stubby is doing SSH into the router and run "stubby -l"
You should see:
Code:
[16:25:03.790770] STUBBY: Stubby version: Stubby 0.3.0
[16:25:03.793779] STUBBY: Read config from file /etc/stubby/stubby.yml
[16:25:03.794402] STUBBY: DNSSEC Validation is OFF
[16:25:03.794444] STUBBY: Transport list is:
[16:25:03.794480] STUBBY:   - TLS
[16:25:03.794517] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[16:25:03.794555] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[16:25:03.794591] STUBBY: Starting DAEMON....
[16:25:06.514984] STUBBY: --- SETUP(TLS): : Verify locations loaded
[16:25:06.515481] STUBBY: 9.9.9.9                                  : Upstream   : Could not setup TLS capable TFO connect
[16:25:06.515929] STUBBY: 9.9.9.9                                  : Conn opened: TLS - Strict Profile
[16:25:06.590545] STUBBY: 9.9.9.9                                  : Verify passed : TLS
[16:25:09.482685] STUBBY: 149.112.112.112                          : Conn opened: TLS - Strict Profile
[16:25:09.555957] STUBBY: 149.112.112.112                          : Verify passed : TLS
[16:25:11.986599] STUBBY: 149.112.112.112                          : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=
 
The question, therefore, is Stubby having issues communicating with Quad9? To see what Stubby is doing SSH into the router and run "stubby -l"

Do I have to first revert to 'connection timed out, try again' conditions... I'm still celebrating getting past that! :)

OE
 
Do I have to first revert to 'connection timed out, try again' conditions... I'm still celebrating getting past that! :)

OE
Do not think so. From time to time I have had issues connecting to the Quad9 resolvers. My ISP routes the Quad9 anycast address to a Miami, Fl data canter and by-passes centers that are physically closer to me. Comcast customers in my locality use the Quad9 data center in Reston, Va. Who knows why that happens but I have attributed the sometimes flaky DoT service to distance.

I would guess you are using a cloud service to store events from your cams? I have micro SD cards in my cams and I use a local server running an open source NVR program called Zoneminder. Do not want my events in the cloud and when I am away I can still access the cams over OpenVPN. Have also turned offf UPnP and disabled those functions on the cams.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top