[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

[Swistheater]

You use the same one as the one for 9.9.9.9

 

[Swistheater]

Since the secondary Cloudflare server is listed in the drop-down, I was expecting the secondary quad9 to be in there as well. I added it manually. One question is what value to use for the TLS hostname for this server. When I do a reverse lookup on dns.quad9.net, I get 9.9.9.9 and 149.112.112.112, but when I do a lookup on 149.112.112.112, I get rpz-public-resolver1.rrdns.pch.net. I imagine that either is ok to use, but I'm not sure.

9.9.9.9, 149.112.112.112
2620:fe::fe, 2620:fe::9
In addition we support DNS-over-TLS on the standard port of 853 using the auth name of dns.quad9.net. For more information on the configuration of DNS-over-TLS see the DNS Privacy Project.^^^^from their website

 

[maxbraketorque]

9.9.9.9, 149.112.112.112
2620:fe::fe, 2620:fe::9
In addition we support DNS-over-TLS on the standard port of 853 using the auth name of dns.quad9.net. For more information on the configuration of DNS-over-TLS see the DNS Privacy Project.^^^^from their website

Thanks.

 

[RMerlin]

Since the secondary Cloudflare server is listed in the drop-down, I was expecting the secondary quad9 to be in there as well. I added it manually.

I built the presets based on the content of the example Stubby config file.

 

[RMerlin]

I don't like the idea of dumping too much unrelated information in that frame, which is meant to only report the information specific to the WAN connection, as configured between you and your ISP. It's not meant to reflect every other configuration that might have been done and might impact how the connection is working (i.e. DNSFilter, DNS Privacy, VPN Clients with traffic redirection, and so on).

I can see if there's a clean way to mention that DNS Privacy is enabled, but at this time I'm not too fond of the idea of flooding this section with additional information, especially as the majority of users don't even realize this frame exists at all (I frequently get people asking me for a way to display that info, not knowing it's already there).

I see Asus are already showing info about YandexDNS there when it's enabled (it's a feature available for certain models/SKUs), so that means it would make sense to also report the presence of DNS Privacy there. I'll experiment with a few potential designs.

 

[truglodite]

Confirmed, dirty flash is working smoothly for me. I'm running DoT with cloudflare on my ac86u no problems. I did have to disable DNSSEC in the webui, otherwise it breaks cloudflares DoT test page. Note that even with DNSSEC disabled, all DNSSEC test pages (including cloudflare) all test out OK. Incidentally, I'm also running the new ntpd from the webui, and that appears to be working fine as well (this replaced my manual script ntpd setup I used before). Also as a sidenote, AMTM, Diversion+pixelserv, Yazfi, and Skynet are also happily strumming along. I'll be sure to post if any issues crop up, but otherwise you've got my +1 for release.

 

[maxbraketorque]

I've got a4 installed. All seems fine so far with DNSSEC and DoT both enabled and DNS set to quad9 primary and secondary. One unanticipated aspect is that DNSSEC and DoT won't work for DNS servers set for specific devices on the DNS Filter page, correct?

 

[RMerlin]

One unanticipated aspect is that DNSSEC and DoT won't work for DNS servers set for specific devices on the DNS Filter page, correct?

Not unanticipated, working as intended. DNSFilter's goal is to bypass any existing client configuration. So if you force a client to use OpenDNS, then it's impossible for that client to use DoT, as OpenDNS servers don't support it.

 

[bbunge]

Confirmed, dirty flash is working smoothly for me. I'm running DoT with cloudflare on my ac86u no problems. I did have to disable DNSSEC in the webui, otherwise it breaks cloudflares DoT test page. Note that even with DNSSEC disabled, all DNSSEC test pages (including cloudflare) all test out OK. Incidentally, I'm also running the new ntpd from the webui, and that appears to be working fine as well (this replaced my manual script ntpd setup I used before). Also as a sidenote, AMTM, Diversion+pixelserv, Yazfi, and Skynet are also happily strumming along. I'll be sure to post if any issues crop up, but otherwise you've got my +1 for release.

All of the web DNSSEC test pages only test that the upstream resolvers, your DNS servers, can do DNSSEC. Does not test your end.

Sent from my SM-T380 using Tapatalk

 

[maxbraketorque]

Not unanticipated, working as intended. DNSFilter's goal is to bypass any existing client configuration. So if you force a client to use OpenDNS, then it's impossible for that client to use DoT, as OpenDNS servers don't support it.

Sorry, I meant unanticipated on my behalf. If I were to assign a DNSSEC+DoT capable DNS server to a specific client in the DNS Filter page, would DNSSEC and DoT be used for that server?

 

[RMerlin]

Sorry, I meant unanticipated on my behalf. If I were to assign a DNSSEC+DoT capable DNS server to a specific client in the DNS Filter page, would DNSSEC and DoT be used for that server?

Set that client to use "Router" instead on the DNSFilter rules.

 

[Swistheater]

Set that client to use "Router" instead on the DNSFilter rules.

Merlin is correct 100 percent. Router forces the dot to be used on that device. You can globally specify router for all devices and make rules to specifically require certain devices to use other servers if you do not want them on DoT server. ---this would be devices that may be required to be on isp servers or maybe they require certain filtering like open dns provides.

 

[dave14305]

Sorry, I meant unanticipated on my behalf. If I were to assign a DNSSEC+DoT capable DNS server to a specific client in the DNS Filter page, would DNSSEC and DoT be used for that server?

If you assign Quad9 in DNSFilter, even though it supports DoT, DNSFilter is still only passing old fashioned DNS over 53/udp.

 

[truglodite]

All of the web DNSSEC test pages only test that the upstream resolvers, your DNS servers, can do DNSSEC. Does not test your end.

Sent from my SM-T380 using Tapatalk

Thanks for the fast, and insightful reply. So I guess those sites are kinda pointless then. FWIW, when I turn on dnssec in my router,

dig +dnssec +multi asuswrt.lostrealm.ca @127.0.0.1

...returns the 'ad' flag. If I turn off dnssec, no 'ad' flag. So I'm guessing it has to be on in the gui for it to work on my end.

OTOH, the only way I know to test DoT is with cloudflare's page, but it fails the test when DNSSEC is enabled. Is there a reliable way to verify both dnssec and dot on my end from terminal? I read some info elsewhere about using kdig for this, but I don't have that on my router (yet)... plus rather get advice from the ground up on this.

TIA,
Kevin

 

[skeal]

OTOH, the only way I know to test DoT is with cloudflare's page, but it fails the test when DNSSEC is enabled. Is there a reliable way to verify both dnssec and dot on my end from terminal? I read some info elsewhere about using kdig for this, but I don't have that on my router (yet)... plus rather get advice from the ground up on this.

KDIG will only work reliably from a Ubuntu desktop or equivalent. It does in fact succeed. The command is (and can be modified):

kdig -d @1.1.1.1 +tls-ca +dnssec +tls-host=cloudflare-dns.com  example.com

make sure to exception the test rig from the DNSFilter.

 

[dave14305]

KDIG will only work reliably from a Ubuntu desktop or equivalent. It does in fact succeed. The command is (and can be modified):

kdig -d @1.1.1.1 +tls-ca +dnssec +tls-host=cloudflare-dns.com  example.com

make sure to exception the test rig from the DNSFilter.

I think we’ve discussed this in the “old” Stubby thread, but this command is only testing your Linux client’s ability to use DoT directly with Cloudflare, bypassing your router and Stubby completely. Just don’t want to confuse anyone wanting to test the router’s ability to do DoT.

 

[truglodite]

Roger that skeal... just read that after googling it and you verified for me. Fortunately at least dig works for me... gotta fire up my ancient laptop that I rarely use to try the kdig thing. From what I understand based on this discussion:

https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/

Is that the cf help page is a valid way to test dot, but first dnssec has to be disabled to test dot this way (because that page has a bug). Then, dnssec must be verified separately with the dig command (ad flag present). If I'm not correct, please slap me up. I wish there was a way to test both at the same time from the router terminal or windows.

Kevin

 

[Swistheater]

https://www.snbforums.com/threads/p...1-with-dns-over-tls.56095/page-25#post-484597

gives detailed instructions on how to download tcpdump and using that you can tell all traffic related to DOT is being passed through the right point. any traffic not related to that would be passed through the other option listed to check.

 

[Swistheater]

opkg install tcpdump
tcpdump -i eth0 port 53<------- this would show you any traffic that was being passed that was not connected via DoT "lets say for example you used DNSFILTER to use a different server for a specific device"
this would show the traffic of that one device.

tcpdump -i eth0 port 853<-------- This shows all traffic concerned with the DoT connected devices.

 

[skeal]

TCPDump and the mere fact that DNS works means that the technology is alive and working well. The requirements can lead a person to conclude this. No need to analyze this over and over.