ASUSWRT-Merlin and NextDNS issue

[SomeWhereOverTheRainBow]

I did the Stubby install via Entware while still running 384.14 and still got the same result with Stubby still using the older OpenSSL 1.0.2 Once I reverted back to 384.13, leaving the new Entware Stubby installed, with the edited the stubby config to point to NextDNS, it all started working correctly.

Yea the problem with the "entware" route the environment has to be setup to use correct binaries or else routers get used. That is why I mentioned the xentrk script as alternative as it should already do that.

 

[RMerlin]

This would probably be specific to the mainline branch, because my RT-AX88U is properly linked against 1.1 here.

 

[SomeWhereOverTheRainBow]

This would probably be specific to the mainline branch, because my RT-AX88U is properly linked against 1.1 here.

yea I have checked against RT-AC5300 and RT-AC68U and both are reporting the wrong link on both the published 384.14 and 384.15_alpha.

 

[RMerlin]

The getdns build recipes were modified by Asus's 384_81044 GPL, they no longer provided the path to the OpenSSL instance to link against, so it picked whatever was available to it - namely 1.0.2.

That's why the issue only affected the mainline model - RT-AX88U, RT-AC87U and RT-AC3200 were built from different branches, without the 81044 GPL changes.

 

[XIII]

The getdns build recipes were modified by Asus's 384_81044 GPL, they no longer provided the path to the OpenSSL instance to link against, so it picked whatever was available to it - namely 1.0.2.

Nice that you found the root cause!

Does this mean you can fix this for a future build, or do you need a fix from ASUS?

 

[SomeWhereOverTheRainBow]

Nice that you found the root cause!

Does this mean you can fix this for a future build, or do you need a fix from ASUS?

he is already working on fixing it. there is a commit for it on his mainline.

https://github.com/RMerl/asuswrt-merlin.ng/commit/9b531763c9efcb344ed64214cd34dd6f24158fe0

 

[RMerlin]

Nice that you found the root cause!

Does this mean you can fix this for a future build, or do you need a fix from ASUS?

Entirely under my control. Asus on their own end won't have any issue the day they enable stubby because they do not have to deal with a dual-OpenSSL architecture like I do. So in their case, it will always use whichever OpenSSL version they decide to use at build time.

 

[dave14305]

So I'm experimenting with NextDNS and the large dbl.oisd.nl list (known as the Large list in Diversion). NextDNS is configured to return UNSPECIFIED ADDRESS (i.e. 0.0.0.0) for blocked domains. This prevents my continued use of Pixelserv-tls locally with 192.168.1.2 as my blocking IP. Not awful, but can I have the best of both worlds?

I'm experimenting with adding this line to dnsmasq.conf to map upstream responses of 0.0.0.0 to 192.168.1.2:

alias=0.0.0.0,192.168.1.2

Added via dnsmasq.postconf:

#!/bin/sh
CONFIG="$1"
. /usr/sbin/helper.sh

if [ "$(nvram get dnspriv_enable)" = "1" ] && [ -n "$(nvram get dnspriv_rulelist | grep nextdns)" ]; then
        pc_append "alias=0.0.0.0,192.168.1.2" "$CONFIG"
        pc_delete "stop-dns-rebind" "$CONFIG"
fi

Of course, I need to disable DNS Rebind protection, but this is just an experiment to benefit from the dbl.oisd.nl list without the high memory usage on my AC68U.

 

[SomeWhereOverTheRainBow]

So I'm experimenting with NextDNS and the large dbl.oisd.nl list (known as the Large list in Diversion). NextDNS is configured to return UNSPECIFIED ADDRESS (i.e. 0.0.0.0) for blocked domains. This prevents my continued use of Pixelserv-tls locally with 192.168.1.2 as my blocking IP. Not awful, but can I have the best of both worlds?

I'm experimenting with adding this line to dnsmasq.conf to map upstream responses of 0.0.0.0 to 192.168.1.2:

alias=0.0.0.0,192.168.1.2

Added via dnsmasq.postconf:

#!/bin/sh
CONFIG="$1"
. /usr/sbin/helper.sh

if [ "$(nvram get dnspriv_enable)" = "1" ] && [ -n "$(nvram get dnspriv_rulelist | grep nextdns)" ]; then
        pc_append "alias=0.0.0.0,192.168.1.2" "$CONFIG"
        pc_delete "stop-dns-rebind" "$CONFIG"
fi

Of course, I need to disable DNS Rebind protection, but this is just an experiment to benefit from the dbl.oisd.nl list without the high memory usage on my AC68U.

So is this telling any upstream response from 0.0.0.0 to behave as 192.168.1.2? Or vice versa?

 

[dave14305]

So is this telling any upstream response from 0.0.0.0 to behave as 192.168.1.2? Or vice versa?

Any response the upstream DNS server sends back to dnsmasq that is 0.0.0.0, it is modified to return to the client as 192.168.1.2.
Here's an example dig against NextDNS directly, and again through dnsmasq.

# dig metrics.icloud.com @45.90.28.170

; <<>> DiG 9.14.4 <<>> metrics.icloud.com @45.90.28.170
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24212
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;metrics.icloud.com.            IN      A

;; ANSWER SECTION:
metrics.icloud.com.     300     IN      A       0.0.0.0

;; Query time: 72 msec
;; SERVER: 45.90.28.170#53(45.90.28.170)
;; WHEN: Sun Dec 29 20:36:39 UTC 2019
;; MSG SIZE  rcvd: 70

# dig metrics.icloud.com @127.0.0.1

; <<>> DiG 9.14.4 <<>> metrics.icloud.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64588
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;metrics.icloud.com.            IN      A

;; ANSWER SECTION:
metrics.icloud.com.     54      IN      A       192.168.1.2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 29 20:36:50 UTC 2019
;; MSG SIZE  rcvd: 63

 

[SomeWhereOverTheRainBow]

Will this only work with their 0.0.0.0 option? When I tested them I chose the nodata route.

 

[dave14305]

Will this only work with their 0.0.0.0 option? When I tested them I chose the nodata route.

Yes, because it still needs to see the 0.0.0.0 response and you don't get that with NODATA.

 

[XIII]

RMerlin posted a fix for the OpenSSL linking (384.14_1).

Unfortunately I don’t have time to test the fix this year (=today).

Anyone else able to check whether NextDNS over TLS now works OK?

 

[tito]

Hi everyone. New to the forum but was having this issue. Noticed that 384.14_2 was released a few hours ago and it now works! Just wanted to express my gratitude to all of those posting useful information here to help get this set up

 

[XIII]

Upgraded to 384.14_2 a few minutes ago and NextDNS (over TLS) is now working for me as well.

Thank you RMerlin!

 

[Puremin0rez]

NextDNS has begun testing their client on Merlin devices!

You can find the repository with code here:
https://github.com/nextdns/nextdns

It's as simple as running the following command from terminal on your router:

sh -c 'sh -c "$(curl -sL https://nextdns.io/install)"'

Keep in mind it's being advertised as a TEST so do not expect absolutely flawless functionality on all configurations.

This probably deserves its own thread instead of piggybacking off this thread, but I figure someone else can do that (such as the actual NextDNS dev who has an account here).

 

[XIII]

This test is for DNS over HTTPS rather than TLS, right?

 

[Puremin0rez]

This test is for DNS over HTTPS rather than TLS, right?

Correct, it's DoH using their native client and using dnsmasq to forward requests to it. Stubby not involved.

 

[Swistheater]

Correct, it's DoH using their native client and using dnsmasq to forward requests to it. Stubby not involved.

have you tested it yet? also is there an uninstall command?

 

[Swistheater]

So I'm experimenting with NextDNS and the large dbl.oisd.nl list (known as the Large list in Diversion). NextDNS is configured to return UNSPECIFIED ADDRESS (i.e. 0.0.0.0) for blocked domains. This prevents my continued use of Pixelserv-tls locally with 192.168.1.2 as my blocking IP. Not awful, but can I have the best of both worlds?

I'm experimenting with adding this line to dnsmasq.conf to map upstream responses of 0.0.0.0 to 192.168.1.2:

alias=0.0.0.0,192.168.1.2

Added via dnsmasq.postconf:

#!/bin/sh
CONFIG="$1"
. /usr/sbin/helper.sh

if [ "$(nvram get dnspriv_enable)" = "1" ] && [ -n "$(nvram get dnspriv_rulelist | grep nextdns)" ]; then
        pc_append "alias=0.0.0.0,192.168.1.2" "$CONFIG"
        pc_delete "stop-dns-rebind" "$CONFIG"
fi

Of course, I need to disable DNS Rebind protection, but this is just an experiment to benefit from the dbl.oisd.nl list without the high memory usage on my AC68U.

how well did this test work for you?