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.
It would be great to have an "Intro to DOT" setup guide....

Set DNS Privacy to DNS over TLS.
Add at least one server from the list.
Apply.

You're done.

Not sure what more people are expecting here... All the other DNS settings have been in the firmware for years, and are not related to the DoT implementation. All the DoT implementation does is replace the upstream DNS servers with those configured in DNS over TLS. Everything else works as before:

DNSFilter will still override or force the use of the upstream DNS (or in this case, the DoT DNS)
VPN clients will still force the use of the VPN server provided DNS when in Exclusive mode.

So, nothing changed there.

Some people in this thread are overthinking it IMHO. It's nowhere as complicated as some people believe.
 
Set DNS Privacy to DNS over TLS.
Add at least one server from the list.
Apply.

You're done.

Not sure what more people are expecting here... All the other DNS settings have been in the firmware for years, and are not related to the DoT implementation. All the DoT implementation does is replace the upstream DNS servers with those configured in DNS over TLS. Everything else works as before:

DNSFilter will still override or force the use of the upstream DNS (or in this case, the DoT DNS)
VPN clients will still force the use of the VPN server provided DNS when in Exclusive mode.

So, nothing changed there.

Some people in this thread are overthinking it IMHO. It's nowhere as complicated as some people believe.

Marin, skeal, and
RMerlin, Thank you!

This couldn't be any simpler. I need sleep, overthinking is not the word that comes to my mind right now. :)
 
Anyone having an issue where you make changes and the webpage seems to stay on applying settings forever? Reloading the screen manually shows the changes were accepted though.
 
Don't want to sound snarky in my post, but nothing I hate more than people making a 15 mins Youtube video on how to click on three checkboxes when 5-7 lines of text that can be read in under 15 seconds would do the job :)
 
Anyone having an issue where you make changes and the webpage seems to stay on applying settings forever? Reloading the screen manually shows the changes were accepted though.

Yes, just saw this earlier this afternoon. As you said, a refresh showed the setting applied. But when I undid the setting (ICMP setting), I left it for over 15 minutes and the page did not come back to life on its own. But a simple 'F5' showed it back to where it was before I started playing with it.

I hope that the full reset that I do when 384.11 goes live will fix that. ;)
 
I think this is a hint as to why that Cloudflare web test fails when enabling DNSSEC:

Code:
Apr 24 23:50:26 dnsmasq[1091]: Insecure DS reply received for is-cf.cloudflareresolve.com.cdn.cloudflare.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Apr 24 23:50:26 dnsmasq[1091]: Insecure DS reply received for is-dot.cloudflareresolve.com.cdn.cloudflare.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

(there's another reason to stick to dnsmasq for DNSSEC duties - it can provide useful error messages).
 
I think this is a hint as to why that Cloudflare web test fails when enabling DNSSEC:

Code:
Apr 24 23:50:26 dnsmasq[1091]: Insecure DS reply received for is-cf.cloudflareresolve.com.cdn.cloudflare.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Apr 24 23:50:26 dnsmasq[1091]: Insecure DS reply received for is-dot.cloudflareresolve.com.cdn.cloudflare.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

(there's another reason to stick to dnsmasq for DNSSEC duties - it can provide useful error messages).

a more detailed log for this issue
Code:
14:11:30 dnsmasq[28162]: query[A] 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com from 10.8.0.2
14:11:30 dnsmasq[28162]: forwarded 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com to ::1
14:11:30 dnsmasq[28162]: dnssec-query[DS] is-cf.cloudflareresolve.com to ::1
14:11:30 dnsmasq[28162]: Insecure DS reply received for is-cf.cloudflareresolve.com.cdn.cloudflare.net, could be bad domain configuration or lack of DNSSEC support from upstream DN
S servers
14:11:30 dnsmasq[28162]: reply is-cf.cloudflareresolve.com is BOGUS DS
14:11:30 dnsmasq[28162]: validation 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com is BOGUS
it seems that a unique identifier is appended as a subdomain during the test i.e. 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com and doing a dig +dnssec returns a negative result

dig +dnssec on is-cf.cloudflareresolve.com.cdn.cloudflare.net returns a positive result
 
Don't want to sound snarky in my post, but nothing I hate more than people making a 15 mins Youtube video on how to click on three checkboxes when 5-7 lines of text that can be read in under 15 seconds would do the job :)

I'm a donor, and let me tell you, yes, you sound snarky. The big question is whether to fill anything into the dual boxes for WAN DNS Server, or LAN DNS Server. Yes, they've been there for years and I've never understood the reason for having WAN and LAN DNS blocks - seems extremely redundant. Also, is the DNSSEC button redundant once DOT is selected? Sorry to sound snarky. Just trying to make sense of a good idea punched out by good programmers that have a holier than thou attitude.
 
Set DNS Privacy to DNS over TLS.
Add at least one server from the list.
Apply.

You're done.

Not sure what more people are expecting here... All the other DNS settings have been in the firmware for years, and are not related to the DoT implementation. All the DoT implementation does is replace the upstream DNS servers with those configured in DNS over TLS. Everything else works as before:

DNSFilter will still override or force the use of the upstream DNS (or in this case, the DoT DNS)
VPN clients will still force the use of the VPN server provided DNS when in Exclusive mode.

So, nothing changed there.

Some people in this thread are overthinking it IMHO. It's nowhere as complicated as some people believe.

@RMerlin dumb question, I do alot online gaming thru PS4/Xbox via WiFi (yes not the best setup). Wld messing with any of these settings i.e. DNS over TLS mess with lag while playing say CoD4? Just curious as I tend to keep my settings defaulted while running your FW. I am running FreshJr script which has completely minimized any lag while playing on WiFi. Also currently I don't use the stubby script. But I use diversion, skynet and pixelserv-tls.
 
Last edited:
A bus error usually indicates either a corrupted firmware image, or failing hardware. I wanted to be sure it wasn't the first one, since it seems to have happened a few times lately (first with Asus's own RT-AC68U release a few weeks ago, and also to an AC88U test build I did for myself a few days ago).
Any other AC3100 owner with the same issue? I don't have one so I can't test it.
I am remote from my network to troubleshoot in detail. I was able to get the network up by bypassing stubby via dnsmasq. Webui is not functioning but I can seemingly SSH into the router fine. Routing functions seem to be performing just fine. I will try a rollback to alpha3.
 
@RMerlin dumb question, I do alot online gaming thru PS4/Xbox via WiFi (yes not the best setup). Wld messing with any of these settings i.e. DNS over TLS mess with lag while playing say CoD4? Just curious as I tend to keep my settings defaulted while running your FW. I am running FreshJr script which has completely minimized any lag while playing on WiFi. Also currently I don't use the stubby script. But I use diversion, skynet and pixelserv-tls.
I am not a gamer and with my slow DSL do not experience any appreciable lag when browsing. As I understand, your initial DNS request to a DoT site may be a tad slower but that response is cached in dnsmasq. So, subsequent DNS requests to the same site will only go as far as your router and therefore should not cause "lag." I'll have to discuss this next week when I help my gamer grandson set up his new PC. Other gamers feel free to chime in...
 
The individual router features themselves are rather straightforward independently. It's what happens when people start experimenting that gets them in trouble and "breaks their internet". An ambitious wiki page would aim to explain the interplay among:
  • WAN DNS Servers 1 and 2
  • DoT servers
  • Wan: use local resolver...
  • DNSFilter
  • LAN DHCP DNS Server 1 and 2
  • Network Monitoring (ping and/or dns)
  • OpenVPN
  • IPv6 (if enabled)
I think everyone should consider resetting to factory defaults when 384.11 final is released, and not repeat any old habits or unnecessary configurations from the former Stubby implementation.
 
I'm a donor, and let me tell you, yes, you sound snarky. The big question is whether to fill anything into the dual boxes for WAN DNS Server, or LAN DNS Server.

Leave them just as they were before.

Yes, they've been there for years and I've never understood the reason for having WAN and LAN DNS blocks - seems extremely redundant.

They've been explained a few times on the forums.

WAN DNS is what your network connection on the router is configured to use.
LAN DNS on the DHCP page is what the DHCP server provides to the clients when providing them with a DHCP lease. Leaving it empty = use the router as the DNS server.

Clients using the router = they ask the router to resolve hostnames. The router then uses the WAN DNS (or the DoT DNS if you have it enabled) to resolve hostnames, then send the response back to the client.

The only time the LAN DNS should be changed is if you run your own DNS server on your network (for instance a Windows Server), and want to use it for handling DNS. It should never be used for a public DNS server.

Also, is the DNSSEC button redundant once DOT is selected?

No, still working as before, as written in my post. If you want to enable DNSSEC validation, regardless of whether it will be done by dnsmasq or stubby, you have to enable it here. Its role hasn't changed.


I really meant it when I wrote "You're done". Meaning all the other settings just need to be left as they were before - they will still work as originally intended. If you want your clients to NOT use the router for DNS lookups, change it on the LAN page. If you want to enable DNSSEC validation, enable it on the WAN page. What they do is 100% unchanged from before DNS Privacy got implemented.
 
@RMerlin dumb question, I do alot online gaming thru PS4/Xbox via WiFi (yes not the best setup). Wld messing with any of these settings i.e. DNS over TLS mess with lag while playing say CoD4?

DNS resolution is unrelated to lag. Lag is the delay between the time your computer sends a packet, and the moment it reaches the remote server.
 
Anyone having an issue where you make changes and the webpage seems to stay on applying settings forever? Reloading the screen manually shows the changes were accepted though.

Could be because the router has to restart various network components when making changes on that particular page (in addition to the WAN connection itself), which can interfere with the page reload. I suspect this is particularly the case if accessing the router through an IP instead of a hostname, tho I never experienced that issue myself in either scenarios.
 
a more detailed log for this issue
Code:
14:11:30 dnsmasq[28162]: query[A] 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com from 10.8.0.2
14:11:30 dnsmasq[28162]: forwarded 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com to ::1
14:11:30 dnsmasq[28162]: dnssec-query[DS] is-cf.cloudflareresolve.com to ::1
14:11:30 dnsmasq[28162]: Insecure DS reply received for is-cf.cloudflareresolve.com.cdn.cloudflare.net, could be bad domain configuration or lack of DNSSEC support from upstream DN
S servers
14:11:30 dnsmasq[28162]: reply is-cf.cloudflareresolve.com is BOGUS DS
14:11:30 dnsmasq[28162]: validation 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com is BOGUS
it seems that a unique identifier is appended as a subdomain during the test i.e. 06712e80-445c-4b61-a2a2-551631593427.is-cf.cloudflareresolve.com and doing a dig +dnssec returns a negative result

dig +dnssec on is-cf.cloudflareresolve.com.cdn.cloudflare.net returns a positive result

And disabling Strict Validation allows both Cloudflare test pages to now properly report the use of DoT.

So it's now confirmed to be a problem on their end. That test entry they create fails DNSSEC validation.
 
And disabling Strict Validation allows both Cloudflare test pages to now properly report the use of DoT.

So it's now confirmed to be a problem on their end. That test entry they create fails DNSSEC validation.

Yes, I’ve even noticed something funky using their app on my phone since the last update.



Sent from my iPhone using Tapatalk
 
Status
Not open for further replies.

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top