External DNS Server customization (DNSSEC, DoT, etc) clarification question

[Username00]

On the WAN DNS setup section, if the DoT section is configured with servers that support both DoT and DNSSEC - do the following settings have any affect?
Assigning a DNS Server pair (like Quad9, Clean Browsing, etc.) and/or enabling DNSSEC?

My thinking is that if the DoT servers are working, then there are no requests being sent to the DNS Server pairs and/or checking DNSSEC since the device on the LAN would already have the destination IP. Or am I missing something? Thanks!

 

[ColinTaylor]

The router needs to have the "normal" DNS servers configured so that it can boot up properly and perform some housekeeping tasks. After the bootup is complete the DoT service is enabled for the clients.

 

[Username00]

OK - so then enabling the DNSSEC would only affect that boot-up process and nothing else (provided the DoT servers are responding during normal operation)?

 

[ColinTaylor]

The DNSSEC setting affects both regular DNS and DoT.

 

[EmeraldDeer]

I don't know how all of the DNS options work under the covers, but here is my take:

• The Enable DNSSEC support option is whether your router is handling DNSSEC directly whether or not you are using DoT
• I prefer Quad9 (or Comcast at bootup) to handle DNSSEC rather than my router
• I set Enable DNSSEC support to No
• Not sure if it is the default or not, but I have "proxy-dnssec" set in /tmp/etc/dnsmasq.conf via /jffs/scripts/dnsmasq.postconf
• This way, Quad9 does the DNSSEC work and the result is in a bit set in the DNS reply
• Obviously this requires trust in your DNS provider, but if you did not, then why would they be your choice to begin with?
• The DNSSEC resolver tests at http://dnssec.vs.uni-due.de/ and https://en.internet.nl/connection/ are successful

 

[bbunge]

OK - so then enabling the DNSSEC would only affect that boot-up process and nothing else (provided the DoT servers are responding during normal operation)?

No, DoT and DNSSEC only become active near the end of the boot process. The entries in WAN DNS Setting/DNS Server use conventional DNS protocol and are not used once DoT becomes active.

 

[Username00]

No, DoT and DNSSEC only become active near the end of the boot process. The entries in WAN DNS Setting/DNS Server use conventional DNS protocol and are not used once DoT becomes active.

OK - so then, if my DoT listed servers (currently, NextDNS) also support DNSSEC and perform that action on any lookups - then it shouldn't matter if DNSSEC is enabled on the router or not, right?

From what I can tell - enabling/disabling does not affect the browser's connection and there is no gain/loss in performance, but without knowing for certain - figured I would ask.

 

[bbunge]

OK - so then, if my DoT listed servers (currently, NextDNS) also support DNSSEC and perform that action on any lookups - then it shouldn't matter if DNSSEC is enabled on the router or not, right?

From what I can tell - enabling/disabling does not affect the browser's connection and there is no gain/loss in performance, but without knowing for certain - figured I would ask.

No, DNSSEC only works if it is enabled in the GUI.
In the Merlin firmware, DNSSEC and DoT are managed by separate programs. DNSSEC is handled by DNSMASQ and DoT is handled by Stubby. Therefore it is possible to have one or the other or both enabled. If you do not enable DNSSEC it is not used.
And you could find a better DNS resolver than NextDNS....

 

[dave14305]

No, DNSSEC only works if it is enabled in the GUI.

The OP seems to be talking about relying on the DNS service to perform the DNSSEC validation upstream. For example, Quad9 will do its own validation on 9.9.9.9, but not with 9.9.9.10.

Using the test domain sigfail.verteiltesysteme.net, you can see how server selection matters. 9.9.9.10 allows the BOGUS response, but 9.9.9.9 rejects it with SERVFAIL.

rtradmin@router:/tmp/home/root# dig sigfail.verteiltesysteme.net @9.9.9.10

; <<>> DiG 9.18.4 <<>> sigfail.verteiltesysteme.net @9.9.9.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48027
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; ANSWER SECTION:
sigfail.verteiltesysteme.net. 60 IN     A       134.91.78.139

;; Query time: 670 msec
;; SERVER: 9.9.9.10#53(9.9.9.10) (UDP)
;; WHEN: Sun Sep 11 20:45:47 EDT 2022
;; MSG SIZE  rcvd: 73

rtradmin@router:/tmp/home/root# dig sigfail.verteiltesysteme.net @9.9.9.9

; <<>> DiG 9.18.4 <<>> sigfail.verteiltesysteme.net @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44111
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 6 (DNSSEC Bogus)
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 350 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Sun Sep 11 20:45:58 EDT 2022
;; MSG SIZE  rcvd: 63

 

[Username00]

The OP seems to be talking about relying on the DNS service to perform the DNSSEC validation upstream. For example, Quad9 will do its own validation on 9.9.9.9, but not with 9.9.9.10.

Exactly. Client just points to DNS Server - if DNS Server is configured to perform DNSSEC - then it does that and responds with the IP back to the client requesting it.

So unless I have the client pointing to the Merlin router for DNS and the requests are forwarded from that point - then I can see DNSSEC being used. That's the logic I think is happening, but it's just not clearly stated in the documentation.

With DoT configured the requests are still leaving the router out the WAN encrypted - so the ISP has no visibility - other than the destination IP to route the traffic.

 

[Username00]

And you could find a better DNS resolver than NextDNS....

Such as?

 

[bbunge]

Exactly. Client just points to DNS Server - if DNS Server is configured to perform DNSSEC - then it does that and responds with the IP back to the client requesting it.

So unless I have the client pointing to the Merlin router for DNS and the requests are forwarded from that point - then I can see DNSSEC being used. That's the logic I think is happening, but it's just not clearly stated in the documentation.

With DoT configured the requests are still leaving the router out the WAN encrypted - so the ISP has no visibility - other than the destination IP to route the traffic.

Ah. Think I see what you want to know.
Clients on the LAN use the router as a DNS Server. The router then sends the DNS query to an upstream resolver and that resolver sends the query back via the reverse route. If DNSSEC is enabled on the router the query is validated between the upstream resolver and router ;UT there is no validation between the router and LAN client

 

[Username00]

Ah. Think I see what you want to know.
Clients on the LAN use the router as a DNS Server. The router then sends the DNS query to an upstream resolver and that resolver sends the query back via the reverse route. If DNSSEC is enabled on the router the query is validated between the upstream resolver and router ;UT there is no validation between the router and LAN client

Close. I understand if the clients on the LAN are pointing to the router, use the DNS servers there, then the DNSSEC settings are in play. What's not clear - is if clients on the LAN use the DoT DNS Server (external) - does the DNSSEC setting do anything at that point?

(Thanks, btw, for helping me sort through this.)

 

[ColinTaylor]

What's not clear - is if clients on the LAN use the DoT DNS Server (external) - does the DNSSEC setting do anything at that point?

What do you mean by "external"? Are you still referring to the DoT servers setup on the router by setting "DNS Privacy Protocol = DNS-over-TLS (DoT)"?

If so, the router's DNSSEC setting still affects the router's DoT server. In this case dnsmasq acts as a proxy (proxy-dnssec) and the Stubby option dnssec_return_status: GETDNS_EXTENSION_TRUE is set. Link.

If however you're talking about clients that don't use the router for DNS at all but go directly to a different server then obviously the router's DNSSEC setting has no effect on them.

 

[Username00]

What do you mean by "external"? Are you still referring to the DoT servers setup on the router by setting "DNS Privacy Protocol = DNS-over-TLS (DoT)"?

Yes.

If so, the router's DNSSEC setting still affects the router's DoT server. In this case dnsmasq acts as a proxy (proxy-dnssec) and the Stubby option dnssec_return_status: GETDNS_EXTENSION_TRUE is set. Link.

Got it. I've seen mention of Stubby, but I don't see any configuration options in the GUI - and it appears to be working just fine - so I think I'm good.

If however you're talking about clients that don't use the router for DNS at all but go directly to a different server then obviously the router's DNSSEC setting has no effect on them.

OK - that's what I thought - I read a post somewhere that if it was enabled along with the DoT servers - then double lookups were occurring which would lead to longer DNS resolution times. That didn't make sense, didn't see anything really definitive in any instructions or online guides - so figured I would ask here.

Thanks for the explanation and your time.