Stubby-Installer-Asuswrt-Merlin

[bbunge]

stubby.yml values for Google DoT. Should work with DNSSEC enabled, too.

# Google
  - address_data: 8.8.8.8
    tls_auth_name: "dns.google"

  - address_data: 8.8.4.4
    tls_auth_name: "dns.google"

  - address_data: 2001:4860:4860::8888
    tls_auth_name: "dns.google"

  - address_data: 2001:4860:4860::8844
    tls_auth_name: "dns.google"

 

[Xentrk]

I have completed incorporating the changes @Adamm made, which also included support for the RT-AC86U in the forked installer from @Jack Yaz. You should no longer need to use his Fork. The Stubby installer script now provides support for HND router models:

• RT-AC86U
• RT-AX88U
• GT-AC5300

The installer now adds the server=/pool.ntp.org/1.1.1.1 entry to eliminate the NTP not being available at boot issue. Performance improvement suggestions made by @Odkrys are also included: TLS 1.3, Cipher List and haveged entware package.

I'll review the README.md on GitHub again tomorrow with a fresh pair of eyes. I did find an issue with one of the validation commands on the README.md and updated it as appropriate. I'll also create a Change Log file to begin documenting the updates made in this revision and any future updates.

I am very Grateful for the collaboration and contributions from @Odkrys, @Jack Yaz and @Adamm to provide support for the HND routers and improve the script. And a big thank you to everyone else who helps on the thread.

In my testing, I first selected the update option. I also did an uninstall and reinstall. Everything appears to be working per the validation tests. Enjoy!

 

[Marin]

I have completed incorporating the changes @Adamm made, which also included support for the RT-AC86U in the forked installer from @Jack Yaz. You should no longer need to use his Fork. The Stubby installer script now provides support for HND router models:

• RT-AC86U
• RT-AX88U
• GT-AC5300

The installer now adds the server=/pool.ntp.org/1.1.1.1 entry to eliminate the NTP not being available at boot issue. Performance improvement suggestions made by @Odkrys are also included: TLS 1.3, Cipher List and haveged entware package.

I'll review the README.md on GitHub again tomorrow with a fresh pair of eyes. I did find an issue with one of the validation commands and updated it as appropriate. I'll also create a Change Log file to begin documenting the updates made in this revision and any future updates.

I am very Grateful for the collaboration and contributions from @Odkrys, @Jack Yaz and @Adamm to provide support for the HND routers and improve the script. And a big thank you to everyone else who helps on the thread.

In my testing, I first selected the update option. I also did an uninstall and reinstall. Everything appears to be working per the validation tests. Enjoy!

This is great news! Thank you very much sir!

Does this now assume that any future manual Entware upgrades (via AMTM) will not cause any issues for this script?


Sent from my iPhone using Tapatalk

 

[Xentrk]

This is great news! Thank you very much sir!

Does this now assume that any future manual Entware upgrades (via AMTM) will not cause any issues for this script?

Correct. The script does a check on the uname and will install the appropriate stubby executable based on the results.

        if [ "$(uname -m)" = "aarch64" ]; then
            download_file /tmp getdns-hnd-latest.ipk
            download_file /tmp stubby-hnd-latest.ipk
<snip>

I'm on an AC88U, so it returns the value armv7l and will install the entware version. The HND routers will pull the stubby and getdns executable from the GitHub repository.

 

[preacher65]

From the amtm thread:

I think we are close. I would like to see if we can get a few people to test the updates over the next several days first to validate there are no issues. Then, @thelonelycoder can include it in AMTM.

I have some time over the next few days so I can try updating my AC86U from the fork to the main version, are there any specific upgrade or installation scenarios you'd like tested?
I guess upgrade, then maybe uninstall/reinstall?

 

[shark]

The install script defaults to Cloudflare (1.1.1.1) DNS-over-TLS on port 853.

Is this the case with ipv6 as well? I mean defaults to cloudflare as well? Sry if this question has been asked, but there are a lot of pages to look and even using search, there is a lot of results...

 

[Marin]

Correct. The script does a check on the uname and will install the appropriate stubby executable based on the results.

        if [ "$(uname -m)" = "aarch64" ]; then
            download_file /tmp getdns-hnd-latest.ipk
            download_file /tmp stubby-hnd-latest.ipk
<snip>

I'm on an AC88U, so it returns the value armv7l and will install the entware version. The HND routers will pull the stubby and getdns executable from the GitHub repository.

I am in heaven! Many thanks to you, @Jack Yaz, @Adamm, @Odkrys and others I may be forgetting for all your efforts on this!


Sent from my iPhone using Tapatalk

 

[bbunge]

Is this the case with ipv6 as well? I mean defaults to cloudflare as well? Sry if this question has been asked, but there are a lot of pages to look and even using search, there is a lot of results...

Yes, the config file, stubby.yml, has an IPV4 and an IPV6 entry for Cloudflare. It also has commented out entries for the other Cloudflare DNS both IPV4 and IPV6 as well as Quad9 DNS. It is a pretty simple process to change, add or remove resolvers (DNS servers).

Keep in mind that DNSSEC is disabled in Merlin when Stubby is installed and not all resolvers play well, yet, with DNSSEC (my experience).

 

[cmkelley]

The installer now adds the server=/pool.ntp.org/1.1.1.1 entry to eliminate the NTP not being available at boot issue. Performance improvement suggestions made by @Odkrys are also included: TLS 1.3, Cipher List and haveged entware package.

My Administration/System/NTP Server entry in the WebGUI points to the IP address of a Raspberry Pi on my local network running an NTP server (synced from GPS data so it actually doesn't need the outside internet). Am I correct in saying then that the server=/pool.ntp.org/1.1.1.1 entry in dnsmasq.conf.add is then actually doing nothing for me since nothing ever looks at pool.ntp.org?

I'm working out a script spawn from init-start that tries once a second to reach my local ntp server to get NTP time as absolutely soon as possible. I think I have it figured out now, but every time I think that it finds a new way to prove me wrong.

 

[Martin_D]

I have now been running this for just over 9 days not one problem. Rssponse time is higher but that is to be suspected I have also moved over to the main version last night

DNS Response Time <ms

 

[cmkelley]

Hrm. Install with latest installer from Xentrk and it all works perfect. 1.1.1.1/help says I'm using DoT, Cloudfare says I'm using DoT and DNSSEC. Didn't change anything (left the server=/pool.ntp.org/1.1.1.1 entry in dnsmasq.conf.add). Reboot the router and 1.1.1.1/help says I'm not using DoT, same with Cloudfare. Re-run the installer and all is well again.

I noticed the installer doesn't touch the IPv6 DNS settings in the webGUI, is IPv6 not going over DoT? Shouldn't those point to the local system like the IPv4 WAN DNS setting?

EDIT: IPv6 not working issue removed, seems to have been a fluke of one reboot.

 

[DonnyJohnny]

I have completed incorporating the changes @Adamm made, which also included support for the RT-AC86U in the forked installer from @Jack Yaz. You should no longer need to use his Fork. The Stubby installer script now provides support for HND router models:

• RT-AC86U
• RT-AX88U
• GT-AC5300

The installer now adds the server=/pool.ntp.org/1.1.1.1 entry to eliminate the NTP not being available at boot issue. Performance improvement suggestions made by @Odkrys are also included: TLS 1.3, Cipher List and haveged entware package.

I'll review the README.md on GitHub again tomorrow with a fresh pair of eyes. I did find an issue with one of the validation commands on the README.md and updated it as appropriate. I'll also create a Change Log file to begin documenting the updates made in this revision and any future updates.

I am very Grateful for the collaboration and contributions from @Odkrys, @Jack Yaz and @Adamm to provide support for the HND routers and improve the script. And a big thank you to everyone else who helps on the thread.

In my testing, I first selected the update option. I also did an uninstall and reinstall. Everything appears to be working per the validation tests. Enjoy!

Can anyone get the new getdns and stubby to work for non-HND model like ac68 etc. And also compile with statically linked OpenSSL 1.1.1a for tls 1.3?

 

[bbunge]

Hrm. Install with latest installer from Xentrk and it all works perfect. 1.1.1.1/help says I'm using DoT, Cloudfare says I'm using DoT and DNSSEC. Didn't change anything (left the server=/pool.ntp.org/1.1.1.1 entry in dnsmasq.conf.add). Reboot the router and 1.1.1.1/help says I'm not using DoT, same with Cloudfare. Re-run the installer and all is well again.

I noticed the installer doesn't touch the IPv6 DNS settings in the webGUI, is IPv6 not going over DoT? Shouldn't those point to the local system like the IPv4 WAN DNS setting?

EDIT: IPv6 not working issue removed, seems to have been a fluke of one reboot.

Keep in mind that when DNSSEC is enabled the Cloudflare Help will fail. Disable DNSSEC and it works. Also, most all the testers on the web for DNSSEC only check the remote DNS resolver. You need to use Dig to test if your DNSSEC is working.

 

[cmkelley]

Keep in mind that when DNSSEC is enabled the Cloudflare Help will fail. Disable DNSSEC and it works. Also, most all the testers on the web for DNSSEC only check the remote DNS resolver. You need to use Dig to test if your DNSSEC is working.

I beg to differ. When I reboot, 1.1.1.1/help says I'm not using D0T. If I touch nothing except to run the stubby installer and re-install, 1.1.1.1/help says DoT is working again. So it can't be a disabling of DNSSEC to fix it, unless the router DNSSEC is getting turned back on somehow magically and not showing up as such in the webGUI. Something isn't getting saved in the reboot.

 

[dave14305]

Something isn't getting saved in the reboot.

Do you have the file /jffs/configs/dnsmasq.conf.add?

Anything in the syslog to show that Stubby and entware started, or the USB drive didn’t mount right away?

 

[shark]

I beg to differ. When I reboot, 1.1.1.1/help says I'm not using D0T. If I touch nothing except to run the stubby installer and re-install, 1.1.1.1/help says DoT is working again. So it can't be a disabling of DNSSEC to fix it, unless the router DNSSEC is getting turned back on somehow magically and not showing up as such in the webGUI. Something isn't getting saved in the reboot.

I have the same issue, here!

After i install or reinstall stubby, i get this:

If i restart stubby or the router(RT-AC86U):

Once, when i've restarted the router, all dns resolution stopped, i went to check stubby with /opt/etc/init.d/S61stubby check and it was alive, i had to restart stubby for the name resolution to come back.

 

[shark]

Do you have the file /jffs/configs/dnsmasq.conf.add?

Anything in the syslog to show that Stubby and entware started, or the USB drive didn’t mount right away?

A i have the same issue as @cmkelley, here is a restart of my router that i just did:

May  5 02:05:22 custom_script: Running /jffs/scripts/pre-mount (args: /dev/sda1 ) - max timeout = 120s
May  5 02:05:22 amtm: Disk check: Unknown filesystem type  on /dev/sda1 - skipping check.
May  5 02:05:23 kernel: EXT4-fs (sda1): recovery complete
May  5 02:05:23 hotplug: USB ext4 fs at /dev/sda1 mounted on /tmp/mnt/usbrouter
May  5 02:05:23 usb: USB ext4 fs at /dev/sda1 mounted on /tmp/mnt/usbrouter.
May  5 02:05:23 kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: user_xattr
May  5 02:05:23 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/usbrouter ) - max timeout = 120s
May  5 02:05:23 haveged: haveged starting up
May  5 02:05:23 administrador: Started haveged from /jffs/scripts/post-mount.
May  5 02:05:23 S61stubby: Starting Stubby DNS over TLS /opt/etc/init.d/S61stubby
May  5 02:05:23 haveged: haveged: ver: 1.9.4; arch: generic; vend: ; build: (gcc 7.3.0 CV); collect: 128K
May  5 02:05:23 haveged: haveged: cpu: (); data: 32K (P); inst: 32K (P); idx: 18/40; sz: 30888/71320
May  5 02:05:23 haveged: haveged: fills: 0, generated: 0
May  5 02:05:24 administrador: Started stubby from /jffs/scripts/post-mount.
May  5 02:05:24 avahi-daemon[827]: Registering new address record for 192.168.50.2 on br0.IPv4.
May  5 02:05:24 Diversion: created br0:pixelserv-tls 192.168.50.2, from /opt/etc/init.d/S80pixelserv-tls
May  5 02:05:24 Entware (aarch64-k3.10): Started pixelserv-tls (Diversion) from /jffs/scripts/post-mount
May  5 02:05:24 Diversion: started Entware services, from /jffs/scripts/post-mount
May  5 02:05:24 rc_service: service 1327:notify_rc restart_dnsmasq
May  5 02:05:24 pixelserv-tls[1332]: pixelserv-tls 2.2.1 (compiled: Dec 29 2018 15:01:05 flags: tfo no_tls1_3) options: 192.168.50.2
May  5 02:05:24 pixelserv-tls[1332]: Listening on :192.168.50.2:443
May  5 02:05:24 pixelserv-tls[1332]: Listening on :192.168.50.2:80
May  5 02:05:25 rc_service: hotplug 1227:notify_rc restart_nasapps
May  5 02:05:25 rc_service: waitting "restart_dnsmasq" via  ...
May  5 02:05:25 kernel: Adding 2097148k swap on /tmp/mnt/usbrouter/myswap.swp.  Priority:-1 extents:74 across:2396156k
May  5 02:05:25 custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
May  5 02:05:25 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf ) - max timeout = 120s
May  5 02:05:25 Diversion: restarted Dnsmasq to apply settings, from /jffs/scripts/dnsmasq.postconf

Anyway to fix these time problems when the router is restarting lol.

 

[dave14305]

After a reboot, what it the output of the command:

grep -E "^no-resolv|^server=" /tmp/etc/dnsmasq.conf

Oh, the syslog shows that Stubby is being started before the router's clock is synced with NTP. Could be a timing problem.

 

[shark]

After a reboot, what it the output of the command:

grep -E "^no-resolv|^server=" /tmp/etc/dnsmasq.conf

Oh, the syslog shows that Stubby is being started before the router's clock is synced with NTP. Could be a timing problem.

Anyway to make the router sync ntp before anything else ?

 

[Zastoff]

Maybe it is possible to add a delay for stubby(as in DNSCrypt-proxy)
## Maximum time (in seconds) to wait for network connectivity before
## initializing the proxy.
## Useful if the proxy is automatically started at boot, and network
## connectivity is not guaranteed to be immediately available.
## Use 0 to disable.
netprobe_timeout = 60