384.17: DNSSEC issue on guest network

[Jake]

I have "Enable DNSSEC support" and "Validate unsigned DNSSEC replies" enabled on my RT-AC68U. I have verified that for any device on the guest network, DNSSEC queries to DNSSEC enabled domains are failing that otherwise do not on the main network. This problem did not exist on the previous stable release. I'm using DoT (Cloudflare) and DNSFilter is set to "Router." Can anyone else confirm this issue?

 

[bbunge]

I have "Enable DNSSEC support" and "Validate unsigned DNSSEC replies" enabled on my RT-AC68U. I have verified that for any device on the guest network, DNSSEC queries to DNSSEC enabled domains are failing that otherwise do not on the main network. This problem did not exist on the previous stable release. I'm using DoT (Cloudflare) and DNSFilter is set to "Router." Can anyone else confirm this issue?

Not really an issue but the way things work. Has been discussed many times before. DNSSEC works. Don't stress about it.

 

[Kanji-San]

I see no issues on the guest network with 384.16 and DNSSEC enabled but DNSFilter off.

 

[Jake]

Not really an issue but the way things work. Has been discussed many times before. DNSSEC works. Don't stress about it.

OK. I did search for the issue in the forums without luck. FWIW, I came across this because the Debian PC that runs my video surveillance system on the guest network wouldn't update (debian.org uses DNSSEC). So I guess I'll to disable DNSSEC to do the updates, or maybe move it to the main network with AP isolation enabled (I need WAN access to the surveillance system, so it must be isolated from my main LAN). Thanks.

 

[Jake]

I see no issues on the guest network with 384.16 and DNSSEC enabled but DNSFilter off.

It wasn't an issue with 384.16 for me either, so go figure!

 

[Chuckles67]

With router on 384.17, and DNSSEC enabled to Cloudflare with DOT, DNSFilter is set to Router, I think DNSSEC is working okay on the guest wifi. I tested this using command line on a MacBook connected to guest wifi:

dig  +dnssec 1.1.1.1

and see

flags: ad

EDNS flags: do

and in the authority section

RRSIG

How are you verifying DNSSEC ?

 

[Jake]

With router on 384.17, and DNSSEC enabled to Cloudflare with DOT, DNSFilter is set to Router, I think DNSSEC is working okay on the guest wifi. I tested this using command line on a MacBook connected to guest wifi:

dig  +dnssec 1.1.1.1

and see

flags: ad

EDNS flags: do

and in the authority section

RRSIG

How are you verifying DNSSEC ?

DNSSEC enabled:

dig debian.org +dnssec
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.1.1#53(192.168.1.1) for debian.org failed: timed out.
;; Connection to 192.168.1.1#53(192.168.1.1) for debian.org failed: timed out.

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> debian.org +dnssec
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to 192.168.1.1#53(192.168.1.1) for debian.org failed: timed out.

DNSSEC disabled:

dig debian.org +dnssec

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> debian.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54472
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280
;; QUESTION SECTION:
;debian.org. IN A

;; ANSWER SECTION:
debian.org. 145 IN A 128.31.0.62
debian.org. 145 IN RRSIG A 8 2 300 20200713082926 20200603073441 63864 debian.org. PLqUuWCTzbxH80ewEu7p6u14q5CCtbcLXMsdlrGWU/T9EF1HrzeasyW4 JeK6+Yz+grQ/dJnY2uU2POLk4VFBeQPdxSx9Tdx3bt8o0PXHaJeLhS/W ia+udiCI5HnKoewD0Mo3RFH9YfFE9MUNagMCnlD+1qMpejLAXnGJT4GK ZtOhdNih7pqD/Noy2gNndsggMzmxIYEiQBUFmkhN/1j2raZMf8vtyLE7 3NvdFabff846SpkFz4jLANFNlZIVNh3Z
debian.org. 145 IN A 130.89.148.77
debian.org. 145 IN A 149.20.4.15

;; Query time: 111 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jun 10 11:44:50 PDT 2020
;; MSG SIZE rcvd: 361

 

[dave14305]

DNSSEC enabled:

dig debian.org +dnssec
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.1.1#53(192.168.1.1) for debian.org failed: timed out.
;; Connection to 192.168.1.1#53(192.168.1.1) for debian.org failed: timed out.

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> debian.org +dnssec
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to 192.168.1.1#53(192.168.1.1) for debian.org failed: timed out.

DNSSEC disabled:

dig debian.org +dnssec

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> debian.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54472
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280
;; QUESTION SECTION:
;debian.org. IN A

;; ANSWER SECTION:
debian.org. 145 IN A 128.31.0.62
debian.org. 145 IN RRSIG A 8 2 300 20200713082926 20200603073441 63864 debian.org. PLqUuWCTzbxH80ewEu7p6u14q5CCtbcLXMsdlrGWU/T9EF1HrzeasyW4 JeK6+Yz+grQ/dJnY2uU2POLk4VFBeQPdxSx9Tdx3bt8o0PXHaJeLhS/W ia+udiCI5HnKoewD0Mo3RFH9YfFE9MUNagMCnlD+1qMpejLAXnGJT4GK ZtOhdNih7pqD/Noy2gNndsggMzmxIYEiQBUFmkhN/1j2raZMf8vtyLE7 3NvdFabff846SpkFz4jLANFNlZIVNh3Z
debian.org. 145 IN A 130.89.148.77
debian.org. 145 IN A 149.20.4.15

;; Query time: 111 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jun 10 11:44:50 PDT 2020
;; MSG SIZE rcvd: 361

It reads like port 53/udp is allowed, but not 53/tcp when the packets are larger.

 

[Chuckles67]

dig debian.org +dnssec

Using your example I can't duplicate what you see. Using 384.17 on an RT-AC66U-B1: I get the same response whether on guest wifi or main wifi.

 

[Jake]

Using your example I can't duplicate what you see. Using 384.17 on an RT-AC66U-B1: I get the same response whether on guest wifi or main wifi.

Thanks. I’ve confirmed it multiple times over with multiple devices on my router. No idea why your router differs.