Info: Stubby 0.2.3 (latest) is on entware.

[DonnyJohnny]

just for people who are interested in Dns over TLS but not on John’s fork. You may want to explore it.
Pkg name is stubby

Source
https://github.com/getdnsapi/stubby

How to use found here.
https://getdnsapi.net/blog/dns-privacy-daemon-stubby/

 

[skeal]

just for people who are interested in Dns over TLS but not on John’s fork. You may want to explore it.
Pkg name is stubby

Source
https://github.com/getdnsapi/stubby

How to use found here.
https://getdnsapi.net/blog/dns-privacy-daemon-stubby/

This is great news!! We are closer and closer to a version for our routers!!

 

[Xentrk]

I have given stubby a try. It appears to be running. However, it fails the https://1.1.1.1/help test.

/opt/etc/stubby/stubby.yml

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions
resolution_type: GETDNS_RESOLUTION_STUB
dnssec_return_status: GETDNS_EXTENSION_TRUE
appdata_dir: "/opt/var/cache/stubby"
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000
tls_backoff_time: 900
listen_addresses:
  - 127.0.0.1@5453

upstream_recursive_servers:
# IPv4 addresses
# # Cloudflare servers
  - address_data: 1.1.1.1
    tls_port: 853
    tls_auth_name: "cloudflare-dns.com"
                 
# # Cloudflare servers
  - address_data: 1.0.0.1    
    tls_port: 853            
    tls_auth_name: "cloudflare-dns.com"

/jffs/configs/dnsmasq.conf.add

# Need these for stubby.  Commented out values means the parms are already in /etc/dnsmasq.conf
#no-resolv
#dnssec
 server=127.0.0.1#5453
listen-address=127.0.0.1

Start stubby and validate

# stubby -g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log

# netstat -lnptu | grep stubby
tcp        0      0 127.0.0.1:5453          0.0.0.0:*               LISTEN      7899/stubby
udp        0      0 127.0.0.1:5453          0.0.0.0:*                           7899/stubby

 # ps | grep stubby | grep -v grep
 7899 wizard    4892 S    stubby -g -v 5 -C /opt/etc/stubby/stubby.yml

 

[john9527]

It appears to be running. However, it fails the https://1.1.1.1/help test.

Turn off dnssec.....their test site is not configured correctly for dnssec.

 

[Xentrk]

Turn off dnssec.....their test site is not configured correctly for dnssec.

I remember reading about that in this tutorial.

Spoiler: TL;DR

Specimen
21d
I think I can confirm that there's an issue with cf's https://1.1.1.1/help 5 website, I've setup a stubby on a Windows 10 VM to test that site with DNSSEC on and off, so a setup that is completely different in terms of operating system, except for stubby.

In the default setup of stubby I only changed the upstream servers to be only cloudflare, turned off round robin, and tried with DNSSEC on and off and the results are the same, when DNSSEC is on the site fails to recognize the connection to 1.1.1.1 and DoT, when it's off it consistently recognizes, even thou in both cases it displays AS name as Cloudflare.

I did comment out the DNSSEC line in dnsmasq.conf.add. But I forgot to uncheck the DNSSEC radio button in the firmware.

/jffs/scripts/dnsmasq.conf.add

# Need these for stubby. If comment out, already in /etc/dnsmasq.conf
no-resolv
#dnssec
 
server=127.0.0.1#5453
listen-address=127.0.0.1

I have it working now with some hacks! All of my testing was done on the WAN iface. I'll test using the OpenVPN client tomorrow.

View attachment 14442

The issue appears to be with the firmware DNS setting overriding stubby. The firmware will not allow me to put 127.0.0.1 as a DNS server IP. So, I specified 1.1.1.1 as DNS server 1 and nothing for DNS server 2.

The firmware then populates /tmp/resolv.dnsmasq as:

server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server=1.1.1.1

The 10.9.01 and 10.8.0.1 are the VPN DNS servers. I then changed the 1.1.1.1 to be the loop back IP address followed by a service restart_dnsmasq.

/tmp/resolv.dnsmasq after change

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1

Thinking of using the mount hack inside of init-start to allow my overrides to take priority over the firmware overriding changes to resolv.dnsmasq.

 mount -o bind /jffs/scripts/resolv.dnsmasq /tmp/resolv.dnsmasq

It works using either one of the three configuration files pasted in the spoilers below. The key was to change
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
to
tls_authentication: GETDNS_AUTHENTICATION_NONE
Source: http://www.linksysinfo.org/index.php?threads/fork-tomato-arm-by-kille72.73397/page-18

I am using opportunistic mode because i could not get strict mode working after a reboot. Probably due to wrong router date/time.

I'll look more into that setting tomorrow.

Spoiler: stubby.yml example 1

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
- GETDNS_TRANSPORT_TLS

#tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_authentication: GETDNS_AUTHENTICATION_NONE

tls_query_padding_blocksize: 128

edns_client_subnet_private : 0

round_robin_upstreams: 0

idle_timeout: 10000

listen_addresses:
- 127.0.0.1@5453
- 0::1@5453

upstream_recursive_servers:
# IPv6 addresses
# # Cloudflare IPv6
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"

# # Quad 9 IPv6
# - address_data: 2620:fe::10
# tls_auth_name: "dns.quad9.net"

# IPv4 addresses
# # Cloudflare servers
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"

# Quad 9 service
# - address_data: 9.9.9.10
# tls_auth_name: "dns.quad9.net"

Spoiler: stubby.yml example 2

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
- GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_NONE

tls_query_padding_blocksize: 256

edns_client_subnet_private : 1

idle_timeout: 10000

listen_addresses:
- 127.0.0.1@5453
# - 0::1@5453

round_robin_upstreams: 0

upstream_recursive_servers:
# Quad 9 IPv6
# - address_data: 2620:fe::fe
# tls_auth_name: "dns.quad9.net"
# IPv4 addresses
# The 1.1.1.1 Cloudflare Servers
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

Spoiler: stubby.yml config example 3

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions

resolution_type: GETDNS_RESOLUTION_STUB

dnssec_return_status: GETDNS_EXTENSION_TRUE

appdata_dir: "/opt/var/cache/stubby"

tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"

dns_transport_list:
- GETDNS_TRANSPORT_TLS

#tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_authentication: GETDNS_AUTHENTICATION_NONE

tls_query_padding_blocksize: 128

edns_client_subnet_private : 1

round_robin_upstreams: 1

idle_timeout: 10000

tls_backoff_time: 900

listen_addresses:
- 127.0.0.1@5453

upstream_recursive_servers:
# IPv4 addresses
# # Cloudflare servers
- address_data: 1.1.1.1
tls_port: 853
tls_auth_name: "cloudflare-dns.com"

# # Cloudflare servers
- address_data: 1.0.0.1
tls_port: 853
tls_auth_name: "cloudflare-dns.com"

I almost gave up on getting this to work. The post on the tomato form was the key. This topic has been of interest to me for the past year. Glad to have it working! Your recent stubby enhancement on the fork inspired me.

Hoping some others will now jump on this so we can collaborate on how to best implement stubby on Asuswrt-Merlin!

@thelonelycoder - Diversion is still blocking ads with dnsmasq+stubby!

 

[Xentrk]

Created /opt/etc/init.d/S61stubby so stubby starts at boot:

#!/bin/sh

ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

Advantage is you can use one of the options below:

start|stop|restart|check|kill|reconfigure

Example Usage

wizard@RT-AC88U-8248:/tmp/home/root# /opt/etc/init.d/S61stubby check
 Checking stubby...              alive.
wizard@RT-AC88U-8248:/tmp/home/root# /opt/etc/init.d/S61stubby restart
 Shutting down stubby...              done.
 Starting stubby...              done.

Created /jffs/scripts/resolv.dnsmasq to override firmware handling of DNS on the Webgui. See post #5

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1

Still working on how to override firmware handling of /tmp/resolv.dnsmasq contents. Something like this?

if [ "$(df | grep -c "/tmp/resolv.dnsmasq")" -eq "0" ]; then
 mount -o bind /jffs/scripts/resolv.dnsmasq /tmp/resolv.dnsmasq
 service restart_dnsmasq > /dev/null 2>&1
fi

After a reboot, the contents of /jffs/scripts/resolv.dnsmasq is 1.1.1.1

 

[Xentrk]

stubby is now working using Strict mode:

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

Not sure why it did not work before.

This is the TL;DR on tls_authentication settings:

# Selects Strict or Opportunistic Usage profile as described in
# https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/
# Strict mode requires that authentication information for the upstreams is
# specified below. Opportunistic may fallback to clear text DNS if UDP or TCP is
# included in the transport list above.
# For Strict use GETDNS_AUTHENTICATION_REQUIRED
# For Opportunistic use GETDNS_AUTHENTICATION_NONE
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

Stubby was not running again this morning. Something is killing the process. Requires some more analysis.

Still looking into how best to hack a fix for /tmp/resolv.dnsmasq.

 

[Xentrk]

I solved the /tmp/resolv.dnsmasq update issue by creating a user script in /jffs/scripts/dnsmasq.postconf:

#!/bin/sh
cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq
service restart_dnsmasq

/jffs/configs/resolv.dnsmasq

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1

stubby is now working on system restart!

 

[skeal]

I solved the /tmp/resolv.dnsmasq update issue by creating a user script in /jffs/scripts/dnsmasq.postconf:

#!/bin/sh
cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq
service restart_dnsmasq

jffs/configs/resolv.dnsmasq

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1

stubby is now working on system restart!

Wow! I am really interested in this! Hope we can install this on our routers soon!

 

[Xentrk]

Wow! I am really interested in this! Hope we can install this on our routers soon!

Since you have entware, you can install stubby using these commands:

opkg update
opkg install stubby
opkg install ca-certificates

You probably already have ca-certificates installed. Look in /opt/etc/ssl

add to /jffs/scripts/dnsmasq.postconf

cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq
[code]
If the file does not exist, add the shebang to the first line #!/bin/sh and make chmod 744

If you use an OpenVPN client, add the same to /jffs/scripts/openvpn-event

/jffs/configs/resolv.dnsmasq
[CODE]server=127.0.0.1

/opt/etc/stubby/stubby.yml

# stubby.yml configuration file created by Xentrk
# version 1.0.0
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: 128
edns_client_subnet_private : 1
round_robin_upstreams: 0
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453

dnssec_return_status: GETDNS_EXTENSION_TRUE

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 Primary IPv6
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"

/opt/etc/init.d/S61stubby

#!/bin/sh

ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

/jffs/configs/dnsmasq.conf.add (also, disable DNSSEC in webgui)

# Need these for stubby. If comment out, already in /etc/dnsmasq.conf
#no-resolv
server=127.0.0.1#5453
listen-address=127.0.0.1

service restart_dnsmasq
/opt/etc/init.d/S61stubby start

You may need to do the dnsmasq.postconf hack in the previous post. Take note of the current values before making the update in case you need to restore. That should be all that is required. I still need to determine why stubby is not running the last two mornings. Perhaps the dnsmasq.postconf hack is the key. I'll see what happens tomorrow morning and take it from there.

Go to https://1.1.1.1/help to test.

I believe DNSSEC works with stubby. It is just the 1.1.1.1/help test site where DNSSEC does not work. I need to research this some more. But I think that is the take away from the posts I read in the openwrt.org forums.

And lastly, need to determine why stubby was not running when I checked the last two mornings. Maybe the dnsmasq.postconf hack will be the fix?

The maintainer of DNSCrypt stopped supporting it, closed the repository on GitHub and put the domain on sale.

 

[skeal]

Since you have entware, you can install stubby using these commands:

opkg update
opkg install stubby
opkg install ca-certificates

You probably already have ca-certificates installed. Look in /opt/etc/ssl

/opt/etc/stubby/stubby.yml

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions
resolution_type: GETDNS_RESOLUTION_STUB
dnssec_return_status: GETDNS_EXTENSION_TRUE
appdata_dir: "/opt/var/cache/stubby"
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000
tls_backoff_time: 900
listen_addresses:
  - 127.0.0.1@5453
upstream_recursive_servers:
# IPv4 addresses
# # Cloudflare servers
  - address_data: 1.1.1.1
    tls_port: 853
    tls_auth_name: "cloudflare-dns.com"
                 
# # Cloudflare servers
  - address_data: 1.0.0.1    
    tls_port: 853            
    tls_auth_name: "cloudflare-dns.com"

/opt/etc/init.d/S61stubby

#!/bin/sh

ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

/jffs/configs/dnsmasq.conf.add (also, disable DNSSEC in webgui)

# Need these for stubby. If comment out, already in /etc/dnsmasq.conf
no-resolv
#dnssec
 server=127.0.0.1#5453
listen-address=127.0.0.1

You may need to do the dnsmasq.postconf hack in the previous post. Take note of the current values before making the update in case you need to restore. That should be all that is required. I still need to determine why stubby is not running the last two mornings. Perhaps the dnsmasq.postconf hack is the key. I'll see what happens tomorrow morning and take it from there.

Go to https://1.1.1.1/help to test.

The maintainer of DNSCrypt stopped supporting it, closed the repository on GitHub and put the domain on sale.

I'll wait to do this tomorrow after your next post. The stubby not running the next day concerns me, I know you will figure it out!! Would be great to have an installer. This would take off like a rocket if it did!! So excited!!

 

[Xentrk]

Ugh! One of my changes broke something. Diversion is not blocking ads any longer and I'm having routing issues e.g. unable to resolve some websites. Will pick it up tomorrow. I'll reverse my changes and implement one by one to see where it breaks. Looks like the revisions to /tmp/resolv.dnsmasq may be a concern or with my /opt/etc/init.d/S61snubby script. The end goal is to have dnsmasq work with stubby DNS over TLS.

 

[M@rco]

I'm confident you'll figure it out. Maybe it's just a typo...

or with my /opt/etc/init.d/S61snubby script

 

[owine]

I don't understand the need to mess around with resolv.dnsmasq. I presently use the dnscrypt-proxy installer, but previously when I had it setup manually the only config changes required were adding no-resolv to dnsmasq.conf.add and an entry to point dnsmasq to the resolving proxy/stub. I have the DNS fields blank on both the WAN and LAN pages on the webui and both my resolv.dnsmasq and resolv.conf files are accordingly blank. The router only points to itself (i.e. dnsmasq) for DNS resolution which is in turn set to use the proxy/stub set in dnsmasq.conf.add. In review of the manager code provided by the installer from bigeyes0x0, these are the same revisions it makes (in a different manner) and does not need the resolv.dnsmasq changes.

 

[Xentrk]

I don't understand the need to mess around with resolv.dnsmasq.

Me either! I thought the no-resolv line in /jfffs/configs/dnsmasq.conf.add was the option to have dnsmasq ignore resolv.conf and resolv.dnsmasq. I saw some forum posts where the hack to resolv.dnsmasq was required.

I presently use the dnscrypt-proxy installer, but previously when I had it setup manually the only config changes required were adding no-resolv to dnsmasq.conf.add and an entry to point dnsmasq to the resolving proxy/stub. I have the DNS fields blank on both the WAN and LAN pages on the webui and both my resolv.dnsmasq and resolv.conf files are accordingly blank.

The firmware does not allow me to leave the DNS setting on the WAN page empty with a caveat. The default is to use the DNS server of the ISP.

/tmp/resolv.dnsmasq

server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server=110.164.252.222
server=110.164.252.223

Note the 1.1.1.1 entries. Did stubby create those?

/tmp/resolv.dnsmasq

server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server=1.1.1.1

The router only points to itself (i.e. dnsmasq) for DNS resolution which is in turn set to use the proxy/stub set in dnsmasq.conf.add. In review of the manager code provided by the installer from bigeyes0x0, these are the same revisions it makes (in a different manner) and does not need the resolv.dnsmasq changes.

I have stubby working when either /tmp/resolv.conf and /tmp/resolv.dnsmasq are empty or contain the values nameserver 127.0.0.1 and server=127.0.0.1 respectively. The routing issues I reported in my prior post are now solved! Unfortunately, the Diversion ad blocker is the only item that appears to not work. I have not tested my VPN interfaces yet. Everything so far has been done on the WAN iface. I also enabled DNSSEC and https://1.1.1.1/help page reports sweet success!

View attachment 14478

At this point, I have hit a wall and not sure what other steps to take. I did more web searches and nothing new arose. Hoping that @john9527, @RMerlin or another forum member can help on the work accomplished so far.

 

[owine]

Me either! I thought the no-resolv line in /jfffs/configs/dnsmasq.conf.add was the option to have dnsmasq ignore resolv.conf and resolv.dnsmasq. I saw some forum posts where the hack to resolv.dnsmasq was required.


The firmware does not allow me to leave the DNS setting on the WAN page empty with a caveat. The default is to use the DNS server of the ISP.
View attachment 14476

Set this to No.

View attachment 14477

Leave this set as No and blank both DNS fields (you currently have 1.1.1.1 defined)

On the LAN -> DHCP Server page, make sure both DNS fields are blank but set "Advertise router's IP in addition to user-specified DNS" to Yes.

 

[skeal]

On my router you cannot leave both fields of WAN DNS to nothing. It cannot be done.

 

[M@rco]

On my router you cannot leave both fields of WAN DNS to nothing. It cannot be done.

I was about to confirm that, but I can leave them blank and apply. That's on 384.7 beta 1, btw.

 

[skeal]

I was about to confirm that, but I can leave them blank and apply. That's on 384.7 beta 1, btw.

You cannot do that when using a static ip however. I have a static ip.

 

[M@rco]

You cannot do that when using a static ip however. I have a static ip.

Ah, I see. I have a 'static' IP as well, but it's assigned by DHCP from my ISP, so my configuration is probably different from yours.

Edit: 'Static' as in it hasn't changed in years. I believe they use the ISP's routers MAC-address for assignment, (not just like a static lease, apparently they 'calculate' your IP based on your MAC address, within their own pool) so as long as I don't get a new router from them, my IP will remain the same.