What's new

Stubby-Installer-Asuswrt-Merlin

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

As soon as I remove the # from the two lines following "Quad 9 Secure Primary" and restart stubby, it dies. What am I doing wrong?

Code:
upstream_recursive_servers:
# Quad 9 Secure Primary
#   - address_data: 9.9.9.9
#     tls_auth_name: "dns.quad9.net"
# Quad 9 Secure Primary
#   - address_data: 2620:fe::fe
#     tls_auth_name: "dns.quad9.net"
# Cloudflare Primary IPv4
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Primary IPv6
#  - address_data: 2606:4700:4700::1111
#    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv6
#  - address_data: 2606:4700:4700::1001
#    tls_auth_name: "cloudflare-dns.com"
Make sure the space count is the same before the dashes. It matters in YML.
 
As soon as I remove the # from the two lines following "Quad 9 Secure Primary" and restart stubby, it dies. What am I doing wrong?

Code:
upstream_recursive_servers:
# Quad 9 Secure Primary
#   - address_data: 9.9.9.9
#     tls_auth_name: "dns.quad9.net"
# Quad 9 Secure Primary
#   - address_data: 2620:fe::fe
#     tls_auth_name: "dns.quad9.net"
# Cloudflare Primary IPv4
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Primary IPv6
#  - address_data: 2606:4700:4700::1111
#    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv6
#  - address_data: 2606:4700:4700::1001
#    tls_auth_name: "cloudflare-dns.com"
Use "stubby -i" to validate your config file.
The following config file worked for me when I was testing.
Code:
appdata_dir: "/opt/var/cache/stubby"
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
idle_timeout: 1900
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_ca_file: "/rom/etc/ssl/certs/ca-certificates.crt"
#
upstream_recursive_servers:
# Quad9 Primary IPv4
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
# Quad9 Secondary IPv4
  - address_data: 149.112.112.112
    tls_auth_name: "dns.quad9.net"
# Quad9 Primary IPv6
  - address_data: 2620:fe::fe
    tls_auth_name: "dns.quad9.net"
# Quad9 Secondary IPv6
  - address_data: 2620:fe::9
    tls_auth_name: "dns.quad9.net"
#
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453
#
 
Hi guys! Now I have a little bit different problem :D

I just updated entware packages, and there was also an update for the libssl..
Code:
Upgrading libopenssl on root from 1.0.2p-1a to 1.1.1a-2...
Downloading http://bin.entware.net/armv7sf-k2.6/libopenssl_1.1.1a-2_armv7-2.6.ipk

Removing obsolete file /opt/lib/libssl.so.1.0.0.
Removing obsolete file /opt/lib/libcrypto.so.1.0.0.

Sadly this seems to crash the stubby installation:

Code:
/tmp/home/root# stubby
stubby: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

Reinstallation attempt:
Code:
Shutting down stubby...              done.
 Starting stubby...              done.
Warning! Unsuccesful installation of Stubby detected
Rerun install_stubby.sh and select the Remove option to backout changes

Using latest beta2 asuswrt. Anything I can do? :D
 
Hi guys! Now I have a little bit different problem :D

I just updated entware packages, and there was also an update for the libssl..
Code:
Upgrading libopenssl on root from 1.0.2p-1a to 1.1.1a-2...
Downloading http://bin.entware.net/armv7sf-k2.6/libopenssl_1.1.1a-2_armv7-2.6.ipk

Removing obsolete file /opt/lib/libssl.so.1.0.0.
Removing obsolete file /opt/lib/libcrypto.so.1.0.0.

Sadly this seems to crash the stubby installation:

Code:
/tmp/home/root# stubby
stubby: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

Reinstallation attempt:
Code:
Shutting down stubby...              done.
 Starting stubby...              done.
Warning! Unsuccesful installation of Stubby detected
Rerun install_stubby.sh and select the Remove option to backout changes

Using latest beta2 asuswrt. Anything I can do? :D

Go to Stubby menu and update the installer first (I think Option 3) then update your configuration (Option 1) and see what happens.


Sent from my iPhone using Tapatalk
 
Go to Stubby menu and update the installer first (I think Option 3) then update your configuration (Option 1) and see what happens.


Sent from my iPhone using Tapatalk
I am already on the latest 1.1.0 version of the installer script.. :(
 
I am already on the latest 1.1.0 version of the installer script.. :(

Yes but try to rerun those steps again in the order I mentioned to see if that resolves your issue (update installer first then configuration).


Sent from my iPhone using Tapatalk
 
Can't you just run "opkg remove libopenssl_1.1.1a-2" and then rerun stubby installer.
 
i read this article, and had a question for stubby users - just out of curiosity :p
https://www.businessinsider.com/paul-vixie-blasts-google-chromecast-2019-2
if a device specifically hard codes 8.8.8.8 will stubby encrypt it and it will simply
access 8.8.8.8 beyond your wan, or will it leak and your isp will be able to see it.
If you chose to route all dns through stubby then the device contacts the router for dns as its first resolver. It will then try 8.8.8.8 but that to would be thwarted by the instruction to route all dns through stubby.
 
If you chose to route all dns through stubby then the device contacts the router for dns as its first resolver. It will then try 8.8.8.8 but that to would be thwarted by the instruction to route all dns through stubby.
My understanding is:
  • If you are using DNSFilter Global Filter Mode Router, then the DNS lookup will use your dnsmasq and stubby. The lookup will be done by the provider configured in stubby.yml.
  • If you are not using DNSFilter, then the query will go directly from the Chromecast device to google's DNS server at 8.8.8.8
 
@Adamm @Xentrk There is something wrong with stubby since we started using DNSFilter. The best way to describe the problem ius to show you two different test results. One taken before disabling DNSFilter and one after.
This is a kdig query on an Ubuntu desktop.
Code:
Ubuntu test before disabling dnsfilter setting


steve@LinuxUbuntu:~$ kdig -d @1.1.1.1 +tls-ca +dnssec +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 133 system certificates
;; WARNING: can't connect to 1.1.1.1@853(TCP)
;; WARNING: failed to query server 1.1.1.1@853(TCP)
steve@LinuxUbuntu:~$
Code:
Ubuntu test after disabling the dnsfilter


steve@LinuxUbuntu:~$ kdig -d @1.1.1.1 +tls-ca +dnssec +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 133 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: V6zes8hHBVwUECsHf7uV5xGM7dj3uMXIS9//7qC8+jU=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GC
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 47411
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1452 B; ext-rcode: NOERROR
;; PADDING: 25 B

;; QUESTION SECTION:
;; example.com.                IN    A

;; ANSWER SECTION:
example.com.            425    IN    A    93.184.216.34
example.com.            425    IN    RRSIG    A 8 2 86400 20190407212028 20190317211731 63195 example.com. YsnnzLA57y7ewUwLWMiWDmFpDJqVASZVlo4YT50bBz1Yk9RHnT1zNLH7Rv6io0T9wri9IsXP8YDXpBKVewO6pGipA6hzL9LTkc4xXF4PIfH7rOTAR1kAuCsz4O2wfe2iMqxCID/hkK3Va6F824Onne0tQvJEocciD9i9rLlbx8E=

;; Received 256 B
;; Time 2019-03-23 16:36:04 CST
;; From 1.1.1.1@853(TCP) in 80.6 ms
steve@LinuxUbuntu:~$
Clearly the first test shows a failure and the second a success. Any ideas what is going on here? Thanks for your help!
 
Last edited:
Clearly the first test shows a failure and the second a success. Any ideas what is going on here? Thanks for your help!
Merlin 384.9 implemented a DoT forwarding filter in DNSFilter, depending on your chosen DNSFILTER mode. So in theory, the worst case is Stubby should still work on your router but DoT from a client will be blocked.

Check your DNSFILTER settings and iptables filter rules.
 
Merlin 384.9 implemented a DoT forwarding filter in DNSFilter, depending on your chosen DNSFILTER mode. So in theory, the worst case is Stubby should still work on your router but DoT from a client will be blocked.

Check your DNSFILTER settings and iptables filter rules.
DoT Forwarding Filter??? Just looked through the change log for 384.9 and saw nothing about a DoT Forwarding Filter. Merlin will do DNSSEC but no DoT (without Stubby)
 
@Xentrk

Entware has been moved to openssl 1.1.1.
No need static binary anymore.
Thanks.
I had done a fresh install of Entware and Stubby about 2 hours ago. Noticed the Openssl loaded up version 1.1.1a. Stubby is running like a champ!

Edit: Stubby now works with the valuse for TLS 1.3. I added this and restarted Stubby (using Cloudflare IPV4 resolvers):
Code:
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"

Here are the stubby.yml values for TLS:
Code:
# Set the acceptable ciphers for DNS over TLS.  With OpenSSL 1.1.1 this list is
# for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the
# tls_ciphersuites option. This option can also be given per upstream.
# tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"

# Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required
# for this option. This option can also be given per upstream.
# tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"

# Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
# tls_min_version: GETDNS_TLS1_2

# Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
# tls_max_version: GETDNS_TLS1_3
 
Last edited:
So you are saying it all works you just can't test with a client. If that is the case how the heck does a person know this is working?
Well, the Cloudflare help still works. Same with the Cloudflare ENSI checker for browser support of TLS 1.3
 
Well, the Cloudflare help still works. Same with the Cloudflare ENSI checker for browser support of TLS 1.3
The ENSI page is a browser test. Cloudflare help doesn't work with strict DNSSEC anyway.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top