ASUSWRT-Merlin and NextDNS issue

[RejZoR]

So, I'm using ASUS RT-AC87U with latest Merlin 384.13_1 and configured NextDNS (nextdns.io) for filtering with DoT enabled. The thing is, if I only use their DNS without configuration prefix, it'll work like any other DNS without a single issue. But as soon as I'm using configured DNS with a prefix on DoT address, things would just stop resolving randomly and webpages won't load and I even had connection failure during Quake Champions.

What seems to be weird here is that no one else seems to be experiencing this but me and I have no clue how to figure it out as I've tried bunch of stuff already. I seem to be the only one using it on router level though so now I'm wondering if it's maybe something borked on the router side...

This is how I have it configured in the router. I've also tried with Forward local domain to upstream with no difference. Logs in NextDNS also don't seem to reveal anything blocked, yet webpages behave like they were either blocked or not resolving at all.

The PREFIX is your configuration ID so NextDNS knows what block lists you're using as webpages try to resolve using these DNS addresses.

I generally only use the following lists:
EasyList
EasyPrivacy
Energizer Spark
WindowsAntiSpy

Anyone with RT-AC87U willing to try it out and see if this happens to you too so I can exclude the router? I really like the NextDNS because of filtering, but this webpage resolving issue that just randomly happens is so annoying I can't use it at all times.

And I'm not into networking enough to even know how to approach thing to figure it out. Help would be greatly appreciated.

 

[SomeWhereOverTheRainBow]

You will have to contact nextdns about the issue unfortunately their Dot configuration does not work well with round robin setup that merlin default stubby uses you can adjust this if you know how to use postconf scripts there are a lot of people here who can advise you how to do that, but the next issue is with nextdns secondary servers and their timeouts. I have tested them with both stubby and unbound, they work great with unbound, and semi okay with stubby with round robin disabled.

this is their recommended settings for stubby.yml you would replace the prefix with yours

round_robin_upstreams: 0
upstream_recursive_servers:
  - address_data: 45.90.28.0
    tls_auth_name: "prefix.dns1.nextdns.io"
  - address_data: 2a07:a8c0::0
    tls_auth_name: "prefix.dns1.nextdns.io"
  - address_data: 45.90.30.0
    tls_auth_name: "prefix.dns2.nextdns.io"
  - address_data: 2a07:a8c1::0
    tls_auth_name: "prefix.dns2.nextdns.io"

 

[bbunge]

Create a stubby.postconf in /jffs/scripts with the following content:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_replace "round_robin_upstreams: 1" "round_robin_upstreams: 0" $CONFIG

chmod 755 /jffs/scripts/stubby.postconf

Restart stubby: service restart_stubby

 

[RejZoR]

I don't understand anything you two said lol. Networking is my Achilles's heel XD. I will forward this info to NextDNS guys, maybe they'll have an idea why this is happening from their end with this configuration used by the router.

 

[RejZoR]

Oh for fracks sake, tried doing this after I got tired of other DNS's and I can't even frigging connect to the damn router. Tried WinSCP, enabled SSH and all that stuff, tried all sorts of protocols, entered usernames and root and the router password and nothing. Jesus, why can't there just be simple "Upload" insider router web interface and it would toss scripts into the folder and that would be it. If you wanted them gone you'd just erase it and start over.

 

[rgnldo]

round_robin_upstreams: 0

There is a problem with this option. Stubby will not alternate search if the upstream name server fails authentication. The option "1" will find the best in case of timeout.

 

[SomeWhereOverTheRainBow]

There is a problem with this option. Stubby will not alternate search if the upstream name server fails authentication. The option "1" will find the best in case of timeout.

I agree but the makers of nextdns service intentionally design their dns service to only respond to one reply at a time. If you use round robin it will cause multiple connection shuts because it attempts each server simultaneously, eventually locking you out of the service for long periods of time. This causes pages not to load properly and interruption in service

 

[rgnldo]

makers of nextdns service intentionally

I had noticed this procedure in their service. It turns out that this runs counter to Stubby's purpose, which is focused on privacy and security. Ideally, keep the default file offered by Stubby, promoting the randomization of queries to multiple upstreams servers. By doing so, Stubby will prevent any query logs from remaining on a single name server. In addition to favoring connectivity. There is not always DoT altentication occurs.

 

[SomeWhereOverTheRainBow]

I had noticed this procedure in their service. It turns out that this runs counter to Stubby's purpose, which is focused on privacy and security. Ideally, keep the default file offered by Stubby, promoting the randomization of queries to multiple upstreams servers. By doing so, Stubby will prevent any query logs from remaining on a single name server. In addition to favoring connectivity. There is not always DoT altentication occurs.

I see where you are coming from, if you use their same DoT servers as advocated within unbound, you experience no issues in connection what-so-ever. I believe their main design is the favor the least attractive DoH and not DoT, because of how their design with DoT is. Their servers probably do not allow for reuse of TLS connections as well. I believe their setup is not a viable candidate for use with stubby though unless you set round robin to 0.

 

[bbunge]

There is a problem with this option. Stubby will not alternate search if the upstream name server fails authentication. The option "1" will find the best in case of timeout.

Sorry, but this is not true. round_robin_upstreams: 0 will go to the next resolver if the first fails. I have been using Stubby this way for about a year. When I was on DSL it helped with connections to Quad9 resolvers which were 10 times further away than Cloudflare. Would be great to have this as an option in the gui.

 

[SomeWhereOverTheRainBow]

Sorry, but this is not true. round_robin_upstreams: 0 will go to the next resolver if the first fails. I have been using Stubby this way for about a year. When I was on DSL it helped with connections to Quad9 resolvers which were 10 times further away than Cloudflare. Would be great to have this as an option in the gui.

i concur, the use of round robin should only be advocated if the servers being used support it. you and I both know this can easily be checked with stubby -l option. if it does not support simultaneous connections, I think it would be less secure with round robin due to all the failed attempted closed connections, than if round robin was set to 0. in some configurations setting round robin to zero may be optimal if a timeout cannot be properly deduced as well.

 

[rgnldo]

Sorry, but this is not true. round_robin_upstreams: 0

Manpage

round_robin_upstreams 0 or 1
If 1, round robin queries across all the configured upstream servers. Without this
option stubby will use each upstream server sequentially until it becomes
unavailable and then move on to use the next.

With option "1" there will be randomization of queries. More secure and private. With "0" there will be sequential query, depending on the stability and connectivity of the server. It goes from user need. Particularly, I prefer the default file recommended by Stubby. I do not change anything.

 

[bbunge]

Manpage

With option "1" there will be randomization of queries. More secure and private. With "0" there will be sequential query, depending on the stability and connectivity of the server. It goes from user need. Particularly, I prefer the default file recommended by Stubby. I do not change anything.

Wrong again. With option 1 in round_robin_upstreams Stubby will query each resolver in turn. Think sequential not random. I know what the MAN page says but watch stubby with stubby -l and see what happens.

Edit:
From the Stubby config guide: round_robin_upstreams: Round robin queries across all the configured upstream servers. Without this option Stubby will use each upstream server sequentially until it becomes unavailable and then move on to use the next.
round_robin_upstream: 0 is the same as leaving the entry out. "sequentially until it becomes unavailable"
round_robin_upstream: 1 "Round robin queries across all the configured upstream servers"

 

[rgnldo]

Between maintaining recursion or not, I prefer recursion.
round_robin_upstreams: 1

Wrong again. With option 1 in round_robin_upstreams Stubby will query each resolver in turn

Ok. Let's get this reasoning.

 

[rgnldo]

From the Stubby config guide: round_robin_upstreams: Round robin queries across all the configured upstream servers. Without this option Stubby will use each upstream server sequentially until it becomes unavailable and then move on to use the next.
round_robin_upstream: 0 is the same as leaving the entry out. "sequentially until it becomes unavailable"
round_robin_upstream: 1 "Round robin queries across all the configured upstream servers

That's what I'm trying to explain.

In any case, for the NextDNS solution, if you want to choose specific ones (DoT with Adblock etc), the ideal is to opt "round_robin_upstreams: 0"

 

[RejZoR]

Then again I'm having hard time using ANY kind of DNS with DoT using Merlin's firmware that are not listed in Merlin firmware itself. It's giving me the impression it's something wrong with the Merlin firmware, not DNS servers...

 

[RMerlin]

It's giving me the impression it's something wrong with the Merlin firmware, not DNS servers...

Stubby is stubby. My firmware doesn't do anything special there, stubby handles everything related to DoT.

 

[rgnldo]

ANY kind of DNS with DoT using Merlin's firmware

Try disabling DNSSEC on Wan (some DoT servers already have DNSSEC, such as Quad9), manually add DNS 185.222.222.222 / 185.184.222.222. Choose some DoT preset.

 

[RejZoR]

Try disabling DNSSEC on Wan (some DoT servers already have DNSSEC, such as Quad9), manually add DNS 185.222.222.222 / 185.184.222.222. Choose some DoT preset.

And NextDNS ? I don't really want to use Quad9...

 

[rgnldo]

And NextDNS ? I don't really want to use Quad9...

First you blame FW Merlin when the problem is a particular DoT service. In any case, the minimum of knowledge is required. Follows an appropriate post.
https://www.augusteo.com/blog/how-to-use-nextdns-with-asuswrt-merlin-tutorial/