[Beta] Asuswrt-Merlin 384.11 Beta is now available

[skeal]

I have two questions:

First, when we enable DoT in wan, can or should we also enable "Enable DNSSEC support" ? I am asking this because before with stubby installed by ourselves, stubby would automatically set that option to no.

Second, is DoT in 384.11 also supporting IPv6?

Yes and Yes.

 

[EmeraldDeer]

I have two questions:

First, when we enable DoT in wan, can or should we also enable "Enable DNSSEC support" ? I am asking this because before with stubby installed by ourselves, stubby would automatically set that option to no.

You should not enable DNSSEC

Second, is DoT in 384.11 also supporting IPv6?

IPv6 is supported even though stubby is not configured to listen IPv6

 

[Reinvented]

Interesting info about DNS Dot, and DNS provider performances:

"Besides its lack of protective and security measures, another con of Cloudflare is quite ironic—they’re dedicated to the privacy of users, but the DNS query data is shared with APNIC Labs in exchange for using its 1.1.1.1. And while Cloudflare claims that APNIC will not have access to IP addresses of users that make the DNS query data, we can’t seem to forget about Cloudbleed."
Quad9 is apparently a bit more "secure" about leaking info, but slower.
View attachment 17277
I presume most here know all this, but decided to share for those that do not...

I was trying to find a DoT provider that had pretty good filtering. AFAIK, OpenDNS doesn't have DoT at all, and Cloudflare and Google doesn't filter like Quad9.

 

[shark]

You should not enable DNSSEC

IPv6 is supported even though stubby is not configured to listen IPv6

But @skeal on the post above yours said that i should enable it, so i am still confused about this...

Now about IPv6... So for the native DoT in 384.11 to work with ipv6 i should change something in some config file for it to listen the IPv6? if yes, can you point me to the right file?

 

[dave14305]

First, when we enable DoT in wan, can or should we also enable "Enable DNSSEC support" ? I am asking this because before with stubby installed by ourselves, stubby would automatically set that option to no.

I'll be the tie-breaker and say yes, you can (and probably should) enable DNSSEC in the GUI if your chosen resolver supports it. In the old stubby script method, Stubby did the DNSSEC itself, so it was necessary to disable dnsmasq DNSSEC. Now in Merlin's implementation, dnsmasq still does the DNSSEC validation, and Stubby does not do any.

EDIT: I was mis-remembering. There was no DNSSEC in the Stubby script method at all, because it broke the Cloudflare test page.

 

[EmeraldDeer]

But @skeal on the post above yours said that i should enable it, so i am still confused about this...

Do what @skeal says. Then ask him why the Cloudflare test fails in the first column. Post about this again when upcoming firmwares default to dnsmasq proxy-dnssec.

Now about IPv6... So for the native DoT in 384.11 to work with ipv6 i should change something in some config file for it to listen the IPv6? if yes, can you point me to the right file?

IPv6 lookups work without changing anything, so don't.

 

[dave14305]

Post about this again when upcoming firmwares default to dnsmasq proxy-dnssec.

Who said this was a thing? They removed proxy-dnssec, why would they add it back later?

 

[shark]

Do what @skeal says. Then ask him why the Cloudflare test fails in the first column. Post about this again when upcoming firmwares default to dnsmasq proxy-dnssec.

I am not saying that he was\is right or that you are\were wrong in anyway... what i meant is that i was still confused because one person told me to enable it and the other one said to not.

IPv6 lookups work without changing anything, so don't.

So, i don't need to change anything and the native DoT in 384.11 is already working for my ipv6.

 

[EmeraldDeer]

Who said this was a thing? They removed proxy-dnssec, why would they add it back later?

I had thought this post was saying it but reading again it could be proxy or direct
[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

 

[owine]

Here is the technical reason the Cloudflare test fails when DNSSEC is enabled.

https://community.cloudflare.com/t/is-cf-cloudflareresolve-com-is-not-a-valid-dnssec-zone/64805/3

 

[fearz]

Hello,

Which GPL used for AC-5300? There is only source code available 3.0.0.4.384.45149 while you mention for all other models is 384_45713.

Asuswrt-Merlin 384.11 Beta is now available for all supported models. This release features a number of significant changes.

EDIT: RT-AC87U and RT-AC3100 beta 1 builds were pulled, as the images seem to suffer from the same corruption issues that recently affected Asus's own RT-AC68U 384_45708 release.

EDIT 2: All potentially affected models have been rebuilt. Please upgrade to the beta1b builds. AC86U/AX88U don't need it.

The highlights:

• New DNS Privacy feature, with DNS-over-TLS support. Configurable under WAN -> Internet Connection, this feature lets you connect with DNS servers that support DNS-over-TLS (DoT). DoT allows your DNS queries to be encrypted, preventing snooping from your ISP or anyone else in transit. Please visit https://dnsprivacy.org/wiki/ for more info on this protocol.
• Replaced the custom ntpclient with an ntp daemon. This daemon acts as a client (to sync your router's clock with the NTP servers configured on the router's System -> Administration page), but it can also be used as an ntp server for your LAN devices. Server functionality can be enabled on the System Administration page. Afterward, you can configure your LAN clients to use your router's IP as their NTP server.
• GPL merges: 384_5951 (RT-AX88U), 384_45713 (all other models). Note that the RT-AC87U and RT-AC3200 are still using the 384_45149 binary blobs for their closed source components.
• Component updates: nano (4.0), curl (7.64.1), dropbear (2019.78).
• Reworked the Firmware Upgrade page. The option to enable/disable automated checks are now on that page, and support for the Beta channel has been removed. Also, the popup reporting a new firmware release will now display that new firmware's version.
• Cleanups to the DDNS page (removed the annoying alert() popups, and moved the notification within the page itself)
• Moved some DNS settings (like DNSSEC) from the DHCP to the Internet Connection page
• Moved LED control to the System -> Administration page
• Editing devices on the Network Map will no longer restart your entire network, only dnsmasq itself. It means that blocking Internet access through it might not immediately come into effect, however the previous behaviour made it impossible to edit multiple clients.
• Custom config/script changes: added service-event-end (run at the end of an rc service event, same parameter as service-event), stubby.postconf/add support (for customizing the DNS Privacy configuration). pre-mount will now receive the filesystem as a second argument.
• Reboot Scheduler should be more reliable and less likely to corrupt plugged USB disks now
• Security issue CVE-2019-1543 resolved in OpenSSL 1.1.x

Please see the Changelog for the complete list of changes.

DNS Privacy:
To configure, simply go to the WAN -> Internet Connection page. Set DNS Privacy protocol to "DNS-over-TLS". Then select at least one server from the Preset drop-down to populate the fields below it, then click on the + button to add the server to the list. You can add multiple servers if needed, but two servers is generally sufficient. There are help popups available on most settings, by clicking on the label.

You can also manually add any desired server if it's not listed in the Presets (only some of the most popular ones are listed, as to keep the list to a manageable length).

DNS Privacy acts by replacing your WAN DNS servers on the router with those configured in the DNS-over-TLS server list. If you have OpenVPN Client set to enforce the use of the VPN server's DNS (Exclusive DNS mode on the VPN config page), or if you have LAN devices set to use a specific DNS server through DNSFilter, these will still go through their enforced server just like before. If you want to force client devices to use the DoT servers, then use DNSFilter in "Router" mode (either globally, or on a per client basis).

DNSSEC is fully supported as before, however note that due to a problem with Cloudflare's test method, their test sites will report failure when DNSSEC is enabled. This is because their test URLs refer to subdomains that are not properly DNSSEC signed, and the router's DNSSEC validation rejects them as invalid, which causes the test to fail. The only real way (known at this time) to fully test things is to use packet monitoring using something like tcpdump on your router (installable through Entware).


Things to test:

• DNS-over-TLS in general. Make sure you read the notes above first!
• NTP, NTPD, and the clock behaviour in general

Please keep discussions in this thread on this specific beta release.

Downloads are here.
Changelog is here.

 

[MarkRH]

Now about IPv6... So for the native DoT in 384.11 to work with ipv6 i should change something in some config file for it to listen the IPv6? if yes, can you point me to the right file?

When enabling DoT and clicking the drop-down to add DNS resolvers, you would for example add two IPV4 and two IPV6 resolvers from the preset server list.

 

[Ydnaroo]

Anyone else here running this beta have a static IP from their Internet Service Provider?

Yep, have a static IP here. As far as I can tell, all seems fine. Andy

 

[skeal]

Do what @skeal says. Then ask him why the Cloudflare test fails in the first column. Post about this again when upcoming firmwares default to dnsmasq proxy-dnssec.

Who really cares about a site that cannot accurately show your connection to them, @RMerlin has said a few times that it is a limitation of that site not your router.

 

[skeal]

Yep, have a static IP here. As far as I can tell, all seems fine. Andy

Are you running a OVPN Server and/or Client set to start at boot up?

 

[Ydnaroo]

Are you running a OVPN Server and/or Client set to start at boot up?

Yes. I have a OVPN server set up on my AC-RT68U. Andy

 

[skeal]

Yes. I have a OVPN server set up on my AC-RT68U. Andy

So needless to say you are not having issues rebooting with the OVPN Server running?

 

[truglodite]

Here is the technical reason the Cloudflare test fails when DNSSEC is enabled.

https://community.cloudflare.com/t/is-cf-cloudflareresolve-com-is-not-a-valid-dnssec-zone/64805/3

Awesome, thanks for sharing owine! That is the first real confirmation I've seen that it is an actual bug and cloudflare is aware of it.

For those seeking to verify dns security, note merlin's OP where he mentions using tcpdump. Also be aware, with the built in webui secure dns, if you disable dnssec you will only be giving up some additional security/privacy. I see no reason to give up dnssec just so a silly webpage test works, especially when there are more direct ways to test already.

 

[Ydnaroo]

So needless to say you are not having issues rebooting with the OVPN Server running?

No problems as far as I'm aware.

 

[skeal]

No problems as far as I'm aware.

You are running this beta right?