ASUSWRT-Merlin and NextDNS issue

[RejZoR]

In that case, see if they have a basic RESTful API that could be invoked through a simple curl command in a ddns-start script.

You're speaking Chinese to me now...

It also seems NextDNS works fine with regular DNS iirc, but with DoT, I always have problems with it over time.

 

[dave14305]

You're speaking Chinese to me now...

It also seems NextDNS works fine with regular DNS iirc, but with DoT, I always have problems with it over time.

It’s the URL in the last box under Linked IP on the NextDNS setup page.

You can also programmatically update your linked IP by calling:
https://link-ip.nextdns.io/..../.............

 

[XIII]

I also want to give NextDNS (DNS-over-TLS) a try, but their setup page keeps complaining that I'm not using a config, despite a correct stubby.yml (I believe):

round_robin_upstreams: 0
upstream_recursive_servers:
  - address_data: 45.90.28.0
    tls_auth_name: "<ID>.dns1.nextdns.io"
  - address_data: 45.90.30.0
    tls_auth_name: "<ID>.dns2.nextdns.io"

(relevant parts)

I also linked my IP at their site and use the asuscomm.com DDNS to update that automatically (though that should only be needed for unencrypted DNS).

What am I doing wrong?

PS1: The PC App (which I tried as a fallback) does not even install on my PC
PS2: The iOS App does install; (thus) only on iOS I get "This device is using NextDNS with this configuration"

 

[SomeWhereOverTheRainBow]

I also want to give NextDNS (DNS-over-TLS) a try, but their setup page keeps complaining that I'm not using a config, despite a correct stubby.yml (I believe):

round_robin_upstreams: 0
upstream_recursive_servers:
  - address_data: 45.90.28.0
    tls_auth_name: "<ID>.dns1.nextdns.io"
  - address_data: 45.90.30.0
    tls_auth_name: "<ID>.dns2.nextdns.io"

(relevant parts)

I also linked my IP at their site and use the asuscomm.com DDNS to update that automatically (though that should only be needed for unencrypted DNS).

What am I doing wrong?

PS1: The PC App (which I tried as a fallback) does not even install on my PC
PS2: The iOS App does install; (thus) only on iOS I get "This device is using NextDNS with this configuration"

I have tested them with DoT on the router. As long as you are appending round_robin_upstream to 0 with a stubby.postconf script and you have your addresses setup right on the Wan DoT settings page of the router, you should be fine. I recommend forcing DoT using lan-DNS filter option on the router set to Global -"router" mode.


The easier and probably better option is to install Dnscrypt proxy and use their DoH server on the list. It will auto link to your account based on your IP address registered on their site. (there servers favor DoH over DoT).

 

[XIII]

I have tested them with DoT on the router. As long as you are appending round_robin_upstream to 0 with a stubby.postconf script and you have your addresses setup right on the Wan DoT settings page of the router, you should be fine. I recommend forcing DoT using lan-DNS filter option on the router set to Global -"router" mode.

Already did that, but still get this:

This device is using NextDNS with no configuration.
Make sure you use the DNS-over-TLS endpoint listed below.

If I set up DNS over HTTPS in Firefox instead of DNS over TLS in Asuswrt-Merlin it's fine, but I want DoT in the router...

 

[gattaca]

IPv4 (with linked IP)
All devices connected to the router.
...

Followed your setup instructions today and so far, things seem to be holding. Before today, I had been using QUAD9 and CLoudflare to spread things around for months. THANKS!

 

[Puremin0rez]

Should DNSSEC be enabled on the router side when using NextDNS?

 

[SomeWhereOverTheRainBow]

Highly recommend it

 

[gattaca]

Highly recommend it

IDK for sure but earlier this post said DNSSEC was not required b/c they already use "UNBOUND"... beyond my linux-grade. It's shown unchecked in his example.

ASUSWRT-Merlin and NextDNS issue

 

[SomeWhereOverTheRainBow]

IDK for sure but earlier this post said DNSSEC was not required b/c they already use "UNBOUND"... beyond my linux-grade. It's shown unchecked in his example.

ASUSWRT-Merlin and NextDNS issue

Yes that is if you decide to trust their validations as valid in which case you must still add "proxy-dnssec" with a dnsmasq.conf.add script in jffs/configs so it can accept the validations. Using the routers dnssec option is more of a strict validation method in which you are asking the router to do additional validation since you don't necessarily trust theirs to be accurate.

 

[SomeWhereOverTheRainBow]

IDK for sure but earlier this post said DNSSEC was not required b/c they already use "UNBOUND"... beyond my linux-grade. It's shown unchecked in his example.

ASUSWRT-Merlin and NextDNS issue

Here is my recommendation for dnsmasq options
dnsmasq.conf.add (with gui dnssec turned off)

proxy-dnssec
strict-order

dnsmasq.conf.add (with gui dnssec turned on for additional validation)

strict-order

stubby.yml (should have appended with a stubby.postconf script)

round_robin_upstreams: 0

and your servers should be listed inside stubby properly by using the router gui to fill them in.

 

[SomeWhereOverTheRainBow]

if you decide you want to take advantage of their servers using DNSCRYPT- PROXY 2 on their DoH platform

your lines in dnscrypt-proxy.toml

server_names = ['NextDNS-Custom']

for the server line

and for the static line at the very bottom

[static.'NextDNS-Custom']
stamp = 'sdns://the-stamp-listed-on-your-custom-nextdns.io-page.'

Note it is still recommended to use proxy-dnssec via dnsmasq.conf.add or Gui dnssec for additional router validation.

 

[Olivier Poitrey]

FYI, the last revision of the Merlin firmware seems to have a regression. The stubby responsible for doing DoT seems to be linked against OpenSSL 1.0.2 instead of 1.1.1, which prevents it from sending the SNI extension we use to gather the configuration id. I reported the issue to the author.

I'd like to make an announcement as well. We long promised native support for Merlin, and I'm happy to say that the first beta should be available around next week. It will basically integrate our client (https://github.com/nextdns/nextdns), which should be a lot more stable than Stubby and provide addition feature specific to our service. If you are interested in helping use beta test it, please send us an email at team@nextdns.io.

 

[SomeWhereOverTheRainBow]

FYI, the last revision of the Merlin firmware seems to have a regression. The stubby responsible for doing DoT seems to be linked against OpenSSL 1.0.2 instead of 1.1.1, which prevents it from sending the SNI extension we use to gather the configuration id. I reported the issue to the author.

I'd like to make an announcement as well. We long promised native support for Merlin, and I'm happy to say that the first beta should be available around next week. It will basically integrate our client (https://github.com/nextdns/nextdns), which should be a lot more stable than Stubby and provide addition feature specific to our service. If you are interested in helping use beta test it, please send us an email at team@nextdns.io.

@themiron @RMerlin is this true about stubby on the router?

 

[dave14305]

@themiron @RMerlin is this true about stubby on the router?

What do you see for libssl if you run:

ldd /usr/sbin/stubby

384.13:

# ldd /usr/sbin/stubby
        libpthread.so.0 => /lib/libpthread.so.0 (0x40105000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x401cd000)
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x4011f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4018e000)
        libc.so.0 => /lib/libc.so.0 (0x403ad000)
        libdl.so.0 => /lib/libdl.so.0 (0x401a0000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x400be000)

 

[SomeWhereOverTheRainBow]

What do you see for libssl if you run:

ldd /usr/sbin/stubby

384.13:

# ldd /usr/sbin/stubby
        libpthread.so.0 => /lib/libpthread.so.0 (0x40105000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x401cd000)
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x4011f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4018e000)
        libc.so.0 => /lib/libc.so.0 (0x403ad000)
        libdl.so.0 => /lib/libdl.so.0 (0x401a0000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x400be000)

It appears he is correct I am doing this from 384.14 that would explain why there is partial breaking of stubby functionality.

**EDIT**

        libpthread.so.0 => /lib/libpthread.so.0 (0x2abf6000)
        libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x2ac10000)
        libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x2aafd000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2abb2000)
        libc.so.0 => /lib/libc.so.0 (0x2ad61000)
        libdl.so.0 => /lib/libdl.so.0 (0x2abd4000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aad8000)

issue still persist on new alpha version.

 

[SomeWhereOverTheRainBow]

it is a good thing @Xentrk stubby installer is still an option
https://github.com/Xentrk/Stubby-Installer-Asuswrt-Merlin

 

[Smokey613]

I reverted back to 384.13, edited stubby config per NextDNS and all is working fine using DoT.

 

[XIII]

Is it possible to use stubby from Entware to replace the stubby embedded in the firmware, without all the other changes from Xentrk's script?

 

[Smokey613]

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.