Info: Stubby 0.2.3 (latest) is on entware.

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!!

 

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

Code:

#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:
  - [email protected]

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

Code:

# 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

Code:

# 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

 

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

Code:

# 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.



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:

Code:

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

Code:

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.

Code:

 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'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:
- [email protected]
- 0::[email protected]

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:
- [email protected]
# - 0::[email protected]

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:
- [email protected]

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!

 

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

Code:

#!/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:

Code:

start|stop|restart|check|kill|reconfigure

Example Usage

Code:

[email protected]:/tmp/home/root# /opt/etc/init.d/S61stubby check
 Checking stubby...              alive.
[email protected]:/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

Code:

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?

Code:

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

 

stubby is now working using Strict mode:

Code:

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

Not sure why it did not work before.

This is the TL;DR on tls_authentication settings:

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.

 

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

Code:

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

/jffs/configs/resolv.dnsmasq

Code:

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!

 

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

Code:

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

Code:

#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:
  - [email protected]
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

Code:

#!/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)

Code:

# 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.

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.

 

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!!

 

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.

 

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

 

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.

 

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.


/tmp/resolv.dnsmasq

Code:

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

Code:

server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server=1.1.1.1

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!



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.

 

Set this to No.

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.

 

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.

 

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.