[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

[RMerlin]

Howdy folks,

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

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

 

[RMerlin]

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)

 

[Rhialto]

with hopes to see it eventually make it into stock firmware.

How does it work, ASUS look at it and thinks it's a good idea and ask you if they can add your code?

 

[RMerlin]

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.

 

[Marin]

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

 

[RMerlin]

All my code is under a GPL licence, so technically anyone can reuse my code, provided they respect the GPL licensing terms.

 

[Gar]

Anxiously waiting, thanks for this!

 

[Ditch]

This is great! Any plans to have WireGuard implemented?

 

[dave14305]

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.

 

[RMerlin]

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.

 

[Jugnu]

RMerlin,

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

 

[RMerlin]

RMerlin,

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

Can you rephrase that question?

 

[dead_screem]

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.

 

[RMerlin]

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).

 

[Xentrk]

@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.

 

[RMerlin]

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.

 

[bbunge]

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

 

[thelonelycoder]

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.

 

[XIII]

How does this cooperate/interfere with using (advanced features of) unbound or Stubby?

For example: validating the upstream certificate against a home name.

Can one still use those tools when setting DoT to None in the new firmware?

 

[Jack Yaz]

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?