Nest Protect cannot connect with DoT enabled - RT-AX88U 384.18

[john9527]

Well that's no fun. Then it seems DNS truncation is a poorly supported standard. Curious, what's your test domain, and what's the DNS response directly from say 8.8.8.8? Is it >512 bytes and not truncated?

test with
us-west.privateinternetaccess.com

I currently have my fork on without the problem patch, but with the compression update. Here's the dig output....

/tmp/home/root# dig us-west.privateinternetaccess.com

; <<>> DiG 9.16.3 <<>> us-west.privateinternetaccess.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18751
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 23, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;us-west.privateinternetaccess.com. IN    A

;; ANSWER SECTION:
us-west.privateinternetaccess.com. 300 IN CNAME    us-west.regions.cluster.piaservers.net.
us-west.privateinternetaccess.com. 300 IN RRSIG    CNAME 13 3 300 20200811213122 20200809193122 34505 privateinternetaccess.com. jAD1+zaqni8LDD7M+ssx9uxsogZw8zOEngf3XoWJ32jlRMnTz92UhWOG 9PJdCpESfmcu+768SDnHzIyqaJ/Hzg==
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.7
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.10
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.20
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.25
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.29
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.36
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.38
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.40
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.42
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.43
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.46
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.47
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.48
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.54
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.58
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.76
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.79
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.84
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.85
us-west.regions.cluster.piaservers.net.    120 IN A 104.200.151.88
us-west.regions.cluster.piaservers.net.    120 IN RRSIG A 13 5 120 20200811213122 20200809193122 34505 piaservers.net. br+dQSfIKYcgMLFOpB2gNpWStYQro2Fwj4X5EaPRp0nYl2opvXOjasBo RGT7G+ewxtEr3C9epAo0p0WnAsbMZw==

;; Query time: 490 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 10 13:31:22 GMT 2020
;; MSG SIZE  rcvd: 698

It's close to 1300 bytes without the compression update.

 

[wraithdu]

Looks like you have DNSSEC enabled. Without it my answer is 467 bytes. Might be an option for you, I don't think DNSSEC gains much on top of DoT with a trusted upstream server. IMO DNSSEC makes more sense if you're running your own resolver like Unbound, or if you don't trust the upstream. Just a thought.

 

[john9527]

Looks like you have DNSSEC enabled. Without it my answer is 467 bytes. Might be an option for you, I don't think DNSSEC gains much on top of DoT with a trusted upstream server. IMO DNSSEC makes more sense if you're running your own resolver like Unbound, or if you don't trust the upstream. Just a thought.

I'm OK....I actually do run my own fork ...and I just don't include the getdns patch that causes the problem
Just pointing out that the compression change isn't all encompassing, and that you may still encounter problems if running the Merlin builds.

 

[aletaziar]

I updated to 384.19 beta 1 on my router and two nodes and it still wasn't working yesterday. Today I decided to toggle off/on the DNS Filters for the Protects and the DoT for the whole router. Did that a couple of times, no rebooting, and now the Protects connect.

For anyone else testing this, you should keep in mind that even when everything is working correctly the Protects seem to occasionally fail their network check (long press of Nest button). My Protects successfully check their network connection perhaps every 3 out of 4 times.

Update after a week. Both Protects are offline again. When forcing them to check the network (pressing and holding the Nest button), I can see them appear in the client list and the ASUS app shows that they are sending and receiving data, but they continue to say there's a problem with the network. According to the Nest app both my Protects have been offline for a week.

I've run "cat /tmp/nat_rules" and it seems to match "iptables-save -t nat", with all entries accounted for. Ran "iptables -t nat -v -L DNSFILTER" and it says the Nest I used has only sent out 1 packet and 64 bytes.

My settings:
WAN > WAN DNS Setting
Connect to DNS Server automatically: No
DNS Server1: 1.1.1.1
DNS Server2: 1.0.0.1
Forward local domain queries to upstream DNS: No
Enable DNS Rebind protection: Yes
Enable DNSSEC support: Yes
Validate unsigned DNSSEC replies: Yes
Prevent client auto DoH: Auto
DNS Privacy Protocol: DoT
DNS-over-TLS Profile: Strict
DNS-over-TLS Server List (Max Limit : 8):
1.1.1.1 cloudflare-dns.com
1.0.0.1 cloudflare-dns.com

LAN > DHCP Server > DNS and WINS Server Setting
DNS Server 1: empty
DNS Server 2: empty
Advertise router's IP in addition to user-specified DNS: Yes

LAN > DNSFilter
Enable DNS-based Filtering: On
Global Filter Mode: No Filtering
Custom (user-defined) DNS 1: 192.168.1.31
Custom (user-defined) DNS 2: 1.1.1.2
Custom (user-defined) DNS 3: 8.8.8.8
Client List (Max Limit : 64):

Client	Filter Mode
NestProtect-Entryway	Custom 3
NestProtect-Basement	Custom 3

Going to update to 384.19 final tonight and see if that helps.

UPDATE 2020-08-21:
The firmware update to 384.19 did not help. I ran it for a week but the Protects were still not properly connecting. Last night I finally decided to rearrange the network and make the AX3000/AX68U the router and make the two AC88Us the nodes for AiMesh. Previously one of the AC88Us was the router and the other AC88U and AX3000/AX68U were the nodes.

Having the AX68U as the parent node has been very promising. Both Protects are connected in the Nest app now, and other problems I was having with DNSFilter not working properly appear to be resolved as well.