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!

Thanks everyone.

Last question (not sure if it has laready been answered), how can I check if Stubby is really working?

Checking https://www.expressvpn.com/dns-leak-test says that the DNS request is still being exposed.
That test is meant to make you think their service is better. Think of it as false advertising. It does say your DNS may be logged but it does not say if it is being logged. Just that you are not using their service.
One sure way to test is to switch to cloudflare and go to their help page. But the stubby -l will show connections to your DNS

Sent from my SM-T380 using Tapatalk
 
Trying to make one for Arm7. Never compile stuff before.

Inside getdns’s Makefile, there is already
Code:
CONFIGURE_VARS += LIBBSD_LIBS=-lc
Do we need to remove it or just add on the bottom?
Code:
CONFIGURE_VARS += \
    LIBS="-Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -lpthread -lc -lgcc_eh"

Do we need to add anything to stubby’s Makefile?
Code:
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#

include $(TOPDIR)/rules.mk

PKG_NAME:=getdns
PKG_VERSION:=1.5.0
PKG_RELEASE:=tls1.3

PKG_LICENSE:=BSD-3-Clause
PKG_LICENSE_FILES:=LICENSE
PKG_MAINTAINER:=David Mora <iamperson347+public@gmail.com>

PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://getdnsapi.net/dist/
PKG_HASH:=577182c3ace919ee70cee5629505581a10dc530bd53fe5c241603ea91c84fa84

PKG_FIXUP:=autoreconf

PKG_INSTALL:=1

PKG_CONFIG_DEPENDS:= \
	CONFIG_GETDNS_ENABLE_STUB_ONLY \
	CONFIG_GETDNS_ENABLE_IDN_LIBIDN2 
	
include $(INCLUDE_DIR)/package.mk

define Package/getdns/Default
	TITLE:=getdns
	URL:=https://getdnsapi.net/
endef

define Package/getdns
	$(call Package/getdns/Default)
	SECTION:=libs
	CATEGORY:=Libraries
	TITLE+= (library)
	DEPENDS+= +libopenssl +!GETDNS_ENABLE_STUB_ONLY:libunbound +GETDNS_ENABLE_IDN_LIBIDN2:libidn2
	MENU:=1
endef

define Package/getdns/description
	This package contains the getdns library (libgetdns). 
	This package also contains the "getdns_query" command line wrapper for getdns exposing the features of this implementation (both in the official API and the additional API functions).
endef

define Package/getdns/config
	source "$(SOURCE)/Config.in"
endef

CONFIGURE_VARS += \
	LIBS="-Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -lpthread -lc -lgcc_eh"

CONFIGURE_ARGS += \
		$(if $(CONFIG_GETDNS_ENABLE_STUB_ONLY), --enable-stub-only, ) \
		--without-libidn \
		$(if $(CONFIG_GETDNS_ENABLE_IDN_LIBIDN2), , --without-libidn2 ) \
		--with-ssl="$(STAGING_DIR)/opt" \

# This will make 'configure' think that our libbsd.so is missing the
# functions inet_pton, inet_ntop, strlcpy and use the builtin. This 
# removes the libbsd dependency
CONFIGURE_VARS += LIBBSD_LIBS=-lc

define Build/InstallDev
	$(INSTALL_DIR) $(1)/opt/include/getdns/
	$(CP) $(PKG_INSTALL_DIR)/opt/include/getdns/getdns*.h $(1)/opt/include/getdns/
	$(INSTALL_DIR) $(1)/opt/lib
	$(CP) $(PKG_INSTALL_DIR)/opt/lib/libgetdns*.{a,so*} $(1)/opt/lib/
	$(INSTALL_DIR) $(1)/opt/lib/pkgconfig
	$(CP) $(PKG_INSTALL_DIR)/opt/lib/pkgconfig/getdns*.pc $(1)/opt/lib/pkgconfig/
endef
	
	
define Package/getdns/install
	$(INSTALL_DIR) $(1)/opt/lib
	$(INSTALL_DATA) $(PKG_INSTALL_DIR)/opt/lib/libgetdns.so.* $(1)/opt/lib/
	$(INSTALL_DIR) $(1)/opt/sbin	
	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/opt/bin/getdns_query $(1)/opt/sbin/getdns_query
endef

$(eval $(call BuildPackage,getdns))
 
Hey guys thanks a lot again.

I just saw that since I am using a VPN Client I also need to set “Accept DNS Configuration” for the DNS Client to “Disabled” and also remove the “dhcp-option DNS 80.241.218.68” line in the Custom Config for VPN Client.

Is there anything else I need to change in order to make Stubby work flawless?
 
Hey guys thanks a lot again.

I just saw that since I am using a VPN Client I also need to set “Accept DNS Configuration” for the DNS Client to “Disabled” and also remove the “dhcp-option DNS 80.241.218.68” line in the Custom Config for VPN Client.

Is there anything else I need to change in order to make Stubby work flawless?
Nope that should do it.
 
Stubby's working fine, no noticeable problems so far. Thanks again to @Xentrk and all contributors here.

In the meantime I did a test round with netalyzr. --> http://netalyzr.icsi.berkeley.edu/
As soon as I deactivate Stubby this message no longer appears. So it is reproducible for me.

Everything looks good so far, are on a recurring message:
"Your DNS resolver is unable to receive a large (>1500 byte) DNS response successfully, even though it advertises itself as EDNS-enabled."

Explanation:
"EDNS and DNSSEC: Extended DNS (EDNS) is an optional mechanism in DNS, commonly used for DNS Security (DNSSEC). This test records whether the resolver will request DNSSEC records and use EDNS to accept larger results."

Your opinion?

(If you want to test netalyzr yourself: it works either with InternetExplorer 11 or with Firefox 52.1.2 (32bit) with installed Java. Alternatively via netalyzr's Command-Line Client.)

:)
 
Last edited:
Stubby for me depends on the connection realization provided by my ISP. Make an evaluation of the connection and adapt the stubby.yml.
My file stubby.yml:
Code:
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
idle_timeout: 60000
round_robin_upstreams: 0
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453

upstream_recursive_servers:
# IPv4 addresses
# Cloudflare
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
# IPv6 addresses
# Cloudflare
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"
 
Should I also change now round_robin_upstreams: 1 to round_robin_upstreams: 0?
Yes. with only one DNS Upstream Resolver it make no sense to use roundrobin. You do have two entries but they are for the same DNS server. One IPV4 and one IPV6 address.

The idea of using roundrobin is to have some load sharing between two or more DNS servers. With the prior release of GetDNS and Stubby there was a bug that some times would not switch to the next upstream resolver and enabling roundrobin seemed to avert problems. I have been using Stubby with roundrobin disabled since the new release came out with no issues. I do have two IPV4 resolvers configured (Quad9).
 
Hallo,

I am a "noob" user and managed successfully to install stubby via amtm.
What do i need on the client side (Windows 10 PC) to properly use DNS over TLS please ?
Do i just need to set my LAN Adapters to DHCP ?

Thanks in advance,
Ingo
 
Hallo,

I am a "noob" user and managed successfully to install stubby via amtm.
What do i need on the client side (Windows 10 PC) to properly use DNS over TLS please ?
Do i just need to set my LAN Adapters to DHCP ?

Thanks in advance,
Ingo

nothing. make sure your pc gets its ip and dns from the asus router.


Sent from my iPod touch using Tapatalk
 
nothing. make sure your pc gets its ip and dns from the asus router.
Sent from my iPod touch using Tapatalk

Thanks. so basically i just set my 1st DNS Server in the ipv4 settings in windows to 192.168..1.1 ?
with "stubby -I" i see the following so i assume it is working:

[13:56:28.533820] STUBBY: 2606:4700:4700::1111 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = None, Keepalive(ms)= 0
[13:56:28.533877] STUBBY: 2606:4700:4700::1111 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = None
[13:56:28.533898] STUBBY: 2606:4700:4700::1111 : Upstream : TLS - Conns= 0, Conn_fails= 2, Conn_shuts= 0, Backoffs = 5
[13:56:28.533954] STUBBY: 2606:4700:4700::1001 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = None, Keepalive(ms)= 0
[13:56:28.533980] STUBBY: 2606:4700:4700::1001 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = None
[13:56:28.533999] STUBBY: 2606:4700:4700::1001 : Upstream : TLS - Conns= 0, Conn_fails= 2, Conn_shuts= 0, Backoffs = 5
[13:56:28.534196] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[13:56:30.655806] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 1, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 2000
[13:56:30.655866] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 76, Timeouts = 0, Best_auth =Success
[13:56:30.655886] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 23, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[13:56:39.514313] STUBBY: 1.0.0.1 : Conn opened: TLS - Strict Profile
[13:56:41.628379] STUBBY: 1.0.0.1 : Conn closed: TLS - Resps= 1, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 2000
[13:56:41.628439] STUBBY: 1.0.0.1 : Upstream : TLS - Resps= 44, Timeouts = 0, Best_auth =Success
[13:56:41.628461] STUBBY: 1.0.0.1 : Upstream : TLS - Conns= 22, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[13:57:09.650819] STUBBY: 2606:4700:4700::1111 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = None, Keepalive(ms)= 0
[13:57:09.650881] STUBBY: 2606:4700:4700::1111 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = None
[13:57:09.650903] STUBBY: 2606:4700:4700::1111 : Upstream : TLS - Conns= 0, Conn_fails= 3, Conn_shuts= 0, Backoffs = 5
[13:57:09.650960] STUBBY: 2606:4700:4700::1001 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = None, Keepalive(ms)= 0
[13:57:09.650988] STUBBY: 2606:4700:4700::1001 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = None
[13:57:09.651007] STUBBY: 2606:4700:4700::1001 : Upstream : TLS - Conns= 0, Conn_fails= 3, Conn_shuts= 0, Backoffs = 5
[13:57:09.651215] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[13:57:11.766888] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 1, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 2000
[13:57:11.766947] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 77, Timeouts = 0, Best_auth =Success
[13:57:11.766968] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 24, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
 
@Xentrk and @Adamm please also uninstall Entware package haveged when Stubby is uninstalled. Thanks.
 
When I run
Code:
stubby -l
it sometimes takes a long time to get a response. The latest try took almost 3 minutes as you can see from the time stamp:

Code:
[14:28:55.032699] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[14:28:55.038198] STUBBY: DNSSEC Validation is ON
[14:28:55.038276] STUBBY: Transport list is:
[14:28:55.038295] STUBBY:   - TLS
[14:28:55.038315] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[14:28:55.038330] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[14:28:55.038345] STUBBY: Starting DAEMON....
[14:31:41.385119] STUBBY: --- SETUP(TLS): : Verify locations loaded
[14:31:41.385947] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[14:31:41.486871] STUBBY: 1.0.0.1                                  : Verify passed : TLS
[14:31:41.552754] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[14:31:41.647247] STUBBY: 1.1.1.1                                  : Verify passed : TLS
[14:31:43.706699] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=    10, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  2000
[14:31:43.706774] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=    10, Timeouts  =     0, Best_auth =Success
[14:31:43.706795] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[14:31:43.707252] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     6, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  2000
[14:31:43.707311] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     6, Timeouts  =     0, Best_auth =Success
[14:31:43.707332] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[14:31:48.050205] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[14:31:48.172310] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[14:31:50.877423] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     7, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  2000
[14:31:50.877497] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=    13, Timeouts  =     0, Best_auth =Success
[14:31:50.877518] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     2, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[14:31:50.877859] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=     6, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  2000
[14:31:50.877912] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=    16, Timeouts  =     0, Best_auth =Success
[14:31:50.877931] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=     2, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0

Other times there is little or no delay. Is this delay normal or do I need to tweak my settings in any way?

Code:
# stubby.yml configuration file created by Xentrk
# version 1.0.0
tls_ca_file: "/rom/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
  - 127.0.0.1@5453
#  - 0::1@5453

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::1001
#    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv6
#  - address_data: 2606:4700:4700::1111
#    tls_auth_name: "cloudflare-dns.com"
 
round_robin_upstream in your case should be "0"
 
Installed Stubby via amtm after uninstalling DNSCrypt & rebooting Asus RT-AC86U router. If I turn ON my OpenVPN client (IPVanish) on DNS leak test it's showing my IPVanish DNS. With OpenVPN client OFF it will resolved to Cloudflare (my DNS of choice). Netflix-VPN-Bypass also won't work if OpenVPN client is ON no matter what setting I put in Accept DNS Config or remove the (dhcp-option DNS 1.1.1.1) on Custom Config. No changes made yet on stubby.yml. Any help?
You should be using Accept DNS config=disabled and remove your extra dhcp-option.
 
I did that. Also changed the DNS server address (router IP) on PC. Now my DNS resolved to Cloudflare on DNS Leak Test. Neflix-VPN-Bypass also works. Passed the DNSSEC Resolver Test. On Cloudflare SNI Checker, Encrypted SNI failed. Used Firefox Nightly with Encrypted SNI enabled. Is there a way to forced other gadgets on network to use Cloudflare DNS without manually changing it on each device?

xW5JwGV.png
Let your devices get their IP address and DNS from the router. If you want a consistent IP address on a LAN device use the Manual Assignment in the Asus router. That way all your devices will pass the DNS queries to dnsmasq which passes them off to stubby/getdns which send them to whatever you have configured in stubby.yml. Of course you know that..
I suspect that using a VPN client on a network device could change the device DNS setting. I have tested one of the free VPN services on an iMac and when I successfully connect to the service in another country the Mac system properties shows the DNS servers set to Google. I do not use a VPN client on the router so I can't say what that does but it likely could change the DNS for the VPN connection and your DNS queries could go to ????
As a reminder... the DNSSEC testers on the web just test if your resolvers are capable of DNSSEC. Not that your DNSSEC works. My recommendation to most folks is to not enable DNSSEC in Stubby or Merlin as there is a good chance you could get a failure to connect to the resolvers from time to time.
 

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