What's new

[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

  • 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!

Status
Not open for further replies.
However, every time i reboot the router the DOT protocol stops working (though it remains enabled in web ui) but instead of the cloudflare's DNS my ISP's DNS shows on https://www.dnsleaktest.com/

Can't reproduce that here, works for me right away on a reboot. Make sure your NTP server is properly configured, and that you don't have any custom iptables/dnsmasq configuration that conflicts with DoT. You also might want to set DNS Privacy mode to Strict if it wasn't.

That transparent proxy probably just intercepts traffic on port 53. DNS over TLS avoids that by using port 853 instead. Until your ISP decides to block/redirect that port as well...

If possible, I would consider looking for another ISP who doesn't try so hard to monitor ALL of your traffic.
 
https://cmdns.dev.dns-oarc.net/

is a pretty cool test site as well
This is what I get with the URL Chrome on Linux will not go on.
-----------------
Your connection is not private
Attackers might be trying to steal your information from cmdns.dev.dns-oarc.net (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERT_DATE_INVALID

Help improve Safe Browsing by sending some system information and page content to Google. Privacy policy
cmdns.dev.dns-oarc.net normally uses encryption to protect your information. When Google Chrome tried to connect to cmdns.dev.dns-oarc.net this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be cmdns.dev.dns-oarc.net, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit cmdns.dev.dns-oarc.net right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
 
Can't reproduce that here, works for me right away on a reboot. Make sure your NTP server is properly configured, and that you don't have any custom iptables/dnsmasq configuration that conflicts with DoT. You also might want to set DNS Privacy mode to Strict if it wasn't.

That transparent proxy probably just intercepts traffic on port 53. DNS over TLS avoids that by using port 853 instead. Until your ISP decides to block/redirect that port as well...

If possible, I would consider looking for another ISP who doesn't try so hard to monitor ALL of your traffic.

They fixed the.issue by turning on dns filter and putting global in router mode.
 
This is what I get with the URL Chrome on Linux will not go on.
-----------------
Your connection is not private
Attackers might be trying to steal your information from cmdns.dev.dns-oarc.net (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERT_DATE_INVALID

Help improve Safe Browsing by sending some system information and page content to Google. Privacy policy
cmdns.dev.dns-oarc.net normally uses encryption to protect your information. When Google Chrome tried to connect to cmdns.dev.dns-oarc.net this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be cmdns.dev.dns-oarc.net, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit cmdns.dev.dns-oarc.net right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
Yea I just checked and notice the host for the test allowed their cert to become invalid.
 
Has anyone observed if DoT over port 853 is classified by QoS as Net control packets, like regular dns would be?
 
RT-AC66U_B1, removed dnsmasq.conf.add then flashed alpha 3. Using Q9 resolvers with DNSSEC - no apparent issues after flash and a deliberate reboot. Download speed seems a bit slow tonight but that could be a neighborhood CenturyLink DSL issue. Not using IPV6. Pleased enough with this to consider moving from John's fork on my RT-AC68U`s.

Sent from my SM-T380 using Tapatalk
 
loaded 284.11 alpha3 seems to be working well , hsave not touched the dns settingd]d , could someone point me to page with info on these settings , no idea which dns serve to choose or any advantage disadvantage of sny of the choices . will it interfere with the vpn client on my computer /

thanks .
 
loaded 284.11 alpha3 seems to be working well , hsave not touched the dns settingd]d , could someone point me to page with info on these settings , no idea which dns serve to choose or any advantage disadvantage of sny of the choices . will it interfere with the vpn client on my computer /

thanks .

See the first post and you may want to ask in the other 384.11 Alpha thread to not derail this one's focus on DoT working or not. ;)
 
loaded 284.11 alpha3 seems to be working well , hsave not touched the dns settingd]d , could someone point me to page with info on these settings , no idea which dns serve to choose or any advantage disadvantage of sny of the choices . will it interfere with the vpn client on my computer /

thanks .
Most people use cloudflare or quad 9. I have not seen anyone go super off the grid and use the development DOT servers.
 
Agreed, using the two Cloudflare servers is probably the safest bet right now.

Consider Quad9 only if you wish to benefit from their filtering capabilities (they block malicious domains).
 
alpha3 loaded on AC3200 using both Cloudflare servers and DNSSEC, working fine.
 
Forward local domain queries to upstream DNS option on WAN page defaults back to off when applied.
 
Forward local domain queries to upstream DNS option on WAN page defaults back to off when applied.
But it works if you set it on the LAN DHCP server page, so I’m guessing it needs some cleanup so it’s not confusing in two different places in the GUI.
 
fyi, as tured out earlier CF performs DNSSEC on its own, no need to enable it on router.
but might be useful with other DoT servers w/o "builtin" DNSSEC
Ah, no. If you used one of the web DNSSEC tests they just prove that your chosen upstream resolvers can do DNSSEC. You must enable DNSSEC in your router!

Sent from my SM-T380 using Tapatalk
 
With alpha 3 my iOS Dig test did not return the "ad" flag. Created dnsmasq.conf.add with proxy-dnssec and restarted dnsmasq. Now Dig gets the "ad" flag.

Request proxy-dnssec be included in the next build.
Thanks

Sent from my SM-T380 using Tapatalk
 
Agreed, using the two Cloudflare servers is probably the safest bet right now.

Consider Quad9 only if you wish to benefit from their filtering capabilities (they block malicious domains).
Cleanbrowsing also works well and has three filtering options. Supports DNSSEC. Can be added manually to Merlin build.

Sent from my SM-T380 using Tapatalk
 
  • Like
Reactions: Gar
It would be nice to include options to use getdns features as well in stead of built in dnssec
 
Cleanbrowsing also works well and has three filtering options. Supports DNSSEC. Can be added manually to Merlin build.

Sent from my SM-T380 using Tapatalk
Cleanbrowsing is good when it doesnt act buggy
 
Status
Not open for further replies.

Similar threads

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