[Release] Asuswrt-Merlin 384.6 is now available

[Puremin0rez]

Hi telUK,

These are my settings under Wireless and Professional.

5GHz

Control channel: 44 (manually set)
Channel bandwidth: 20/40/80 mhz

Under Professional settings:

Airtime fairness: disabled (disabled by default in Merlin)
Universal beamforming: disabled (leave 802.11ac Beamforming enabled)

2.4GHz

Control channel: 6 (manually set)
Channel bandwidth: 20mhz (manually set)

Under Professional settings:

Turbo QAM: disabled
Airtime fairness: disabled (disabled by default in Merlin)
Beamforming settings: disabled (both)

Great Settings! Improved the stability of my network.

 

[ColinTaylor]

Is the newly added Enable DNS Rebind protection feature giving the same level of protection as the DNS rebind protection that OpenDNS provides?? If it's identical then great! It'd be good to no longer need OpenDNS and just rely on the router to do the job.

Is it newly added? That blog post was from 10 years ago. I don't use OpenDNS but it sounds likes it's the same thing provided you have an OpenDNS account with that option selected. The only difference being that your router (dnsmasq) is returning the "can't resolve" error instead of OpenDNS.

I have enabled "Global Filter Mode: Router" and also in the client list set a few devices to use some Custom (user-defined) DNS.

Any "custom" devices are bypassing your router's DNS server and therefore its rebind protection.

 

[Zonkd]

Is it newly added? That blog post was from 10 years ago. I don't use OpenDNS but it sounds likes it's the same thing provided you have an OpenDNS account with that option selected. The only difference being that your router (dnsmasq) is returning the "can't resolve" error instead of OpenDNS.

Correct OpenDNS long ago made it a free feature to account holders. I'm hoping that this Rebind Protection feature in 384.6 does it just as well.

Any "custom" devices are bypassing your router's DNS server and therefore its rebind protection.

That makes sense to me.

 

[ColinTaylor]

I'm hoping that this Rebind Protection feature in 384.6 does it just as well.

It would seem fairly straight forward. If the upstream DNS server replies with a private IP address don't send that to the client. Given that this is essentially breaking DNS I guess different implementations might give different responses.

You can test it by going to this URL: http://rebind.network/

Aug 13 14:12:34 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.233.forever.eb4462cb-45ff-408e-884c-7affa30a3907.rebind.network
Aug 13 14:12:54 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Aug 13 14:13:49 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.167.forever.43a6ff4a-bd57-4b70-97cc-a00eeda24ec4.rebind.network
Aug 13 14:13:56 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Aug 13 14:14:40 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Aug 13 14:18:04 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network

# nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 192.168.1.1
Server:    192.168.1.1
Address 1: 192.168.1.1 router.asus.com
nslookup: can't resolve 'a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network'

# nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 8.8.8.8
Server:    8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com

Name:      a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Address 1: 192.168.1.27

 

[scjr]

Great Settings! Improved the stability of my network.

You’re welcome, but the credit goes to these forums. I’ve found these settings here. Glad it’s worked out for you and others.

 

[RMerlin]

@RMerlin please add this option "Strict DNSSEC" that Fork has to stop/disable using Strict mode, in DNS server as cloudflare or any other, does not work when you enable DNSSEC.
Only DNS.WATCH or Quad9 support the new DNSSEC version or DNSSEC is broken in this version 384.6

Already planned. However be aware that disabling strict will nullify a good portion of the added security provided by DNSSEC, as someone hijacking a domain usually secured by dnssec would then bypass it simply by using a non-signed zone...

If strict mode generates issues, then those issues should be resolved in the domain themselves, as pointed out by John. And it's actually a good thing if these issues are now visible, so people are aware about them, and can actually take steps toward fixing them.

In my fork beta, I patched the useless dnsmasq 'Insecure DS....' syslog to include the failing domain

Dunno if Simon decided not to do so for privacy reasons, but to me it looks like a no-brainer - without that critical information, it's impossible to tell what is going on, and that log message is mostly useless. That's something I will most likely port, and might see if Simon would be open in also merging that upstream.

Net, I'm no longer sure which is right....is Cloudflare just being 'strict' about dnssec and the other servers are making some assumptions about misconfigured sites.

DNSSEC is a rather complicated beast. Not all TLDs support every "official" ciphers for instance, so sometimes an issue might simply be a domain using a cipher type not supported by its TLD (or even its registrar).

I've always been using my ISP's DNS here, and never got a single complain in my system log.

 

[ZekeMidasWoll]

Hello.

I've experienced severe stability issues after upgrading from 384.5 to 384.6
I dont know if the upgrade was the cause, but the issues came right after/a day or so after the upgrade, and are gone after downgrading to 384.5.

Router : RT-AC68U, 4 years old, original psu.
Wireless clients, only 2.4 gHz enabled : Chromecasts, a laptop, IOS devices.
Wired clients : IP cameras, Windows PC, Synology diskstation, TV, BD player, Chromecast Ultra
Wired clients are connected through 2 switches.

After upgrading to 384.6 i started experiencing stability issues/dropped connections with the wired clients. No problems with wireless clients.
First i suspected one of the switches. An old and cheap one. Replaced it with a new D-link.
The problems persisted, the wired clients were only able to connect after the router was cold booted.
Problems increased, so that the router was not able to get internet connection from the fiber modem (was possible with pc connected directly to the fiber modem).
At first it could be solved by a cold boot of the router.
Then at last it was not possible for the router to connect to the internet at all.
wireless connections with the router did not show any instability. (they were of course not able to have internet access).
Finally i downgraded to 384.5
At first it did not solve the problem
Disconnected AC68U from power and the network.
(Fought to get my old router up running, but gave up)
After half an hour : connected the AC68U again.
It has been working fine since. That was yesterday

I suspected it was the power supply, so ordered a new power supply, noname 19V 3.42 A delivered.
That seems to work fine also.
I will test the original psu again when i get the time, but so far the problems seems to have been caused by upgrade to 384.6

 

[RMerlin]

But, add dnscrypt, using Cloudflare DoH, & I get a lot of dnssec errors. Can’t access a number of sites, Wikipedia being one!

Just a thought: could the issue be with the packet size? DNSSEC signed zones can get a bit large, and adding encryption on top of that would make them even larger.

I bought an "RT-AC68U" off Ebay...it came in some white box. But the factory printing on the front upper right says "AC1900" . (

Could be an RT-AC1900 or RT-AC1900P. What's on the label at the back of the router? Look for any FCC ID for instance, in addition to actual model number.

I've experienced severe stability issues after upgrading from 384.5 to 384.6

Try using the latest 384.7 test build:

https://asuswrt.lostrealm.ca/test-builds

A few RT-AC68U users have experienced issues with their wifi with some of Asus' recent releases. Some reported that the latest release from Asus (which is used by 384.7) resolved the issues for them.

 

[HowIFix]

Already planned. However be aware that disabling strict will nullify a good portion of the added security provided by DNSSEC, as someone hijacking a domain usually secured by dnssec would then bypass it simply by using a non-signed zone...

If strict mode generates issues, then those issues should be resolved in the domain themselves, as pointed out by John. And it's actually a good thing if these issues are now visible, so people are aware about them, and can actually take steps toward fixing them.

Thanks and please add this information in that new option so that I or anybody understand what happens if you deactivate the Strict mode:

• Disabling Strict will nullify a good portion of the added security provided by DNSSEC

 

[HowIFix]

You can test it by going to this URL: http://rebind.network/

Aug 13 14:12:34 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.233.forever.eb4462cb-45ff-408e-884c-7affa30a3907.rebind.network
Aug 13 14:12:54 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Aug 13 14:13:49 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.167.forever.43a6ff4a-bd57-4b70-97cc-a00eeda24ec4.rebind.network
Aug 13 14:13:56 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Aug 13 14:14:40 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Aug 13 14:18:04 dnsmasq[22010]: possible DNS-rebind attack detected: a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network

I did the test and that message does not appear in log, is it good or bad?

 

[ColinTaylor]

I did the test and that message does not appear in log, is it good or bad?

I couldn't say as I know nothing about your setup.

 

[HowIFix]

I couldn't say as I know nothing about your setup.

I use cloudflare dns in wan, disable DNS Rebind protection and that message does not appear in log, after i test with DNS Rebind protection Enable and that message does not appear in log.

Note: For test DNS Rebind I uninstall DNSCrypt and delete my client VPN and restart the router.

 

[RMerlin]

Thanks and please add this information in that new option so that I or anybody understand what happens if you deactivate the Strict mode:

• Disabling Strict will nullify a good portion of the added security provided by DNSSEC

I don't want to overburden the UI with a user manual... Especially as people never read these anyway.

 

[HowIFix]

I don't want to overburden the UI with a user manual... Especially as people never read these anyway.

I read

 

[ColinTaylor]

@HowIFix Try pasting the following into the command prompt of the PC you're doing the test from.

nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network

If it returns an address of 192.168.1.27 then rebind protection isn't working.

 

[HowIFix]

my router ip is 192.168.2.1

 

[ColinTaylor]

my router ip is 192.168.2.1

That doesn't matter.

 

[HowIFix]

That doesn't matter.

I have enable DNS Rebind protection.

 

[john9527]

I don't want to overburden the UI with a user manual... Especially as people never read these anyway.

I added it to the popup help for dnssec...

 

[HowIFix]

I added it to the popup help for dnssec...

When I say add, I mean this same thing that says @john9527, I do not know what @RMerlin was thinking.