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.

RMerlin

Asuswrt-Merlin dev
Howdy folks,

First, since an image is worth a thousand words, here are two screenshots:

DOT-preview1.png

DOT-preview2.png


With 384.11 (still in early development at this time), Asuswrt-Merlin will gain built-in DNS over TLS support. Almost entirely developed by @theMIROn (I only worked on portions of the webui implementation), the original design goal was to make it integrate as cleanly as possible to the rest of the firmware, with hopes to see it eventually make it into stock firmware. With that in mind, we tried to make the webui as intuitive to use as possible for anyone already familiar with Asuswrt, and also to keep the number of options to a minimum.

A list of pre-defined servers can be used, or you can manually enter your own parameters if you wish to use a server not listed in the preset list. I decided to keep that preset list at a reasonable length rather than add every single servers listed in Stubby's sample config file.

The implementation also supports DNSSEC (there are still some webui changes for me to make regarding this, such as moving the DNSSEC setting from the DHCP page into the WAN page).

The current plan is for me to finalize a few last details around the webui, and provide public alpha builds for testing sometime this weekend. Once I do, please keep the feedback in this thread strictly on the DoT portion of the changes (discussions about other changes such as the move from ntpclient to an ntp daemon should be kept in the separate Alpha thread).

This feature has been in development for quite some time (I was waiting for it to reach a mature enough state before announcing it), but we both feel that it's now ready for proper public testing.

Keep an eye on this thread for the release of test builds (as mentioned above should hopefully occur sometime this weekend).

Test builds are now available for download: https://asuswrt.lostrealm.ca/test-builds
 
Last edited:
Known issues:
  • Group labels are rendered in the wrong colour in Firefox (Firefox fails to inherit the select CSS, fixed)
  • Selecting the default entry after selecting a preset will fill the fields with "undefined" strings (Fixed)
  • Cloudflare website test sometimes fails to handle DNSSEC (Seems to be an issue with the test site, not with Asuswrt-Merlin)
 
Last edited:
How does it work, ASUS look at it and thinks it's a good idea and ask you if they can add your code?

We point them at the code, make our case for it, and hope they a) like it, b) feel it fits within their plans, and c) decide to go for it.

I did it in the past with the IPv6 firewall implementation, I pitched a case about them integrating it upstream after I implemented it in my firmware, and they decided to go with it. They also sometime pick up parts of my code on their own - the initial OpenVPN support in Asuswrt came from my firmware. They rewrote most of it with 382_xxxx, but a lot of the server webui code is still from that original design.
 
Howdy folks,

First, since an image is worth a thousand words, here are two screenshots:

View attachment 17044
View attachment 17045

With 384.11 (still in early development at this time), Asuswrt-Merlin will gain built-in DNS over TLS support. Almost entirely developed by @theMIROn (I only worked on portions of the webui implementation), the original design goal was to make it integrate as cleanly as possible to the rest of the firmware, with hopes to see it eventually make it into stock firmware. With that in mind, we tried to make the webui as intuitive to use as possible for anyone already familiar with Asuswrt, and also to keep the number of options to a minimum.

A list of pre-defined servers can be used, or you can manually enter your own parameters if you wish to use a server not listed in the preset list. I decided to keep that preset list at a reasonable length rather than add every single servers listed in Stubby's sample config file.

The implementation also supports DNSSEC (there are still some webui changes for me to make regarding this, such as moving the DNSSEC setting from the DHCP page into the WAN page).

The current plan is for me to finalize a few last details around the webui, and provide public alpha builds for testing sometime this weekend. Once I do, please keep the feedback in this thread strictly on the DoT portion of the changes (discussions about other changes such as the move from ntpclient to an ntp daemon should be kept in the separate Alpha thread).

This feature has been in development for quite some time (I was waiting for it to reach a mature enough state before announcing it), but we both feel that it's now ready for proper public testing.

Keep an eye on this thread for the release of test builds (as mentioned above should hopefully occur sometime this weekend).

This is great development! Thank you @RMerlin!!!


Sent from my iPhone using Tapatalk
 
All my code is under a GPL licence, so technically anyone can reuse my code, provided they respect the GPL licensing terms.
 
Anxiously waiting, thanks for this!
 
Interesting differences in how Stubby will listen on a second loopback IP but still on port 53. And so far, no mention of proxy-dnssec for dnsmasq, which has always been a source of debate in Stubby circles when enabling Stubby DNSSEC. Looking forward to v1.0. A lot of combined Stubby experience on this forum from @john9527, @Xentrk, and the rest of us learning and helping along the way.

Would also be fun to learn more about @theMIROn who has been making notable, behind-the-scenes contributions to Merlin for some time.
 
And so far, no mention of proxy-dnssec for dnsmasq, which has always been a source of debate in Stubby circles when enabling Stubby DNSSEC.

DNSSEC support was only added today, and we're still in development stages, so things may still change over the coming weeks.

Would also be fun to learn more about @theMIROn who has been making notable, behind-the-scenes contributions to Merlin for some time.

He has been involved in many open-sourced projects over the years, including the WL500G custom firmware.
 
RMerlin,

What version of yours will be based on Asus latest GPL code once you have it?

Can you rephrase that question?
 
If I understood correctly, I think he means, when do you plan to merge the next gpl release? in 384.11 or 12 or later etc.

Original post:

please keep the feedback in this thread strictly on the DoT portion of the changes (discussions about other changes such as the move from ntpclient to an ntp daemon should be kept in the separate Alpha thread).
 
@RMerlin

Happy to see DNS over TLS incorporated into the menu.

If an OpenVPN Client would like to use DNS over TLS, would they select the Accept DNS Configuration= Disabled option?

I think I could have handled this differently in the stubby installer. Right now, I am overriding all Accept DNS Configuration settings and forcing the OpenVPN Clients to use Stubby. Based on a recent conversation, I think I can remove the override and force the OpenVPN Client to use Stubby if the user selects Accept DNS Configuration = Disabled. I will test later today to see if this is true. Some people may prefer to use the DNS of their VPN provider when connected to the VPN tunnel and DNS over TLS when connected thru the WAN iface.
 
Some people may prefer to use the DNS of their VPN provider when connected to the VPN tunnel and DNS over TLS when connected thru the WAN iface.

The DNS pushed by the VPN server should not be automatically overriden. If connecting to a corporate network, you need to be able to use it to resolve the remote domain. And if using a commercial VPN provider, they might block port 53 access to prevent accidental leaks.

I haven't evaluated yet how the current DoT implementation itneracts with all of this (especially with Exclusive mode which creates an iptables rule to redirect client traffic). Been too busy polishing the webui stuff this weekend to look into the rest.
 
Remember to include round_robin option 1 or 0
Also feel DoT should turn off ISP DNS by default.

Sent from my SM-T380 using Tapatalk
 
Would also be fun to learn more about @theMIROn who has been making notable, behind-the-scenes contributions to Merlin for some time.
That is what I also noticed. I learned yesterday that he's part of the Entware team.
 
Will it be possible to point a client direct to Stubby/DoT and bypass dnsmasq? I do this now with dnscrypt to exclude some devices from Diversion, while retaining DNS encryption.
From the source, it looks like Stubby will listen on 127.0.1.1?
 
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