Info: Stubby 0.2.3 (latest) is on entware.

[owine]

I believe what's on the WAN page is less important than what's on the LAN page as that defines what is given out to clients. As long as no-resolv is in dnsmasq.conf, I don't think the WAN page DNS servers have any influence.

 

[HowIFix]

I believe what's on the WAN page is less important than what's on the LAN page as that defines what is given out to clients. As long as no-resolv is in dnsmasq.conf, I don't think the WAN page DNS servers have any influence.

What a good joke hahahahaha (I hope it's a joke )

 

[Xentrk]

At some point in my testing the past few days, Diversion ad blocker stopped blocking ads. This morning, I uninstalled stubby and Diversion. A reinstall of Diversion did not fix the issue. I installed both from scratch. Diversion is now working when using stubby! Not sure why it stopped working? The issue of Divsrsion not working was going to be a show stopper for me. But now that it is working again, I will do some more testing. I need to test if stubby and Diversion will work when using an OpenVPN client interface.

As others have mentioned, the Cloudfare test site https://1.1.1.1/help is not configured to report accurate results when DNSSEC is enabled. One must turn off DNSSEC in the Webgui for the site to accurately report status. @HowIFix posted other DNS test sites here that you can use.

I played with the webgui some more. But still find that I can only get stubby and DNS 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.

 

[Xentrk]

Spending some time reviewing my configs. I just discovered why Diversion stopped working. I had accidentally overwritten the contents of /jffs/scripts/dnsmasq.postconf file created by Diversion ad blocker in my attempt to get dnsmasq + stubby to place nice together.

Xentrk Hack

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

Created by Diversion

#!/bin/sh
. /opt/share/diversion/file/post-conf.div # Added by Diversion

Glad that one is resolved.

Another good news item is that stubby stayed running over night!

 

[tomsk]

i would have thought that you wanted the server info in the dnsmasq.conf file to get dnsmasq to forward the requests to stubby? ... just use the dnsmasq.postconf to add it
as an example the way @bigeyes0x0 does his dnscrypt adds this to the dnsmasq.postconf

#!/bin/sh
[ -x /jffs/dnscrypt/manager ] && /jffs/dnscrypt/manager dnsmasq
. /opt/share/diversion/file/post-conf.div # Added by Diversion

but the section of the manager file just adds

dnsmasq)
    sed -i "/^servers-file=.*$/d" /etc/dnsmasq.conf
    append_on_demand /etc/dnsmasq.conf "no-resolv" "server=127.0.0.1#65053"
    ;;

you could do it with a simple pc_append

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
. /opt/share/diversion/file/post-conf.div # Added by Diversion
pc_append "no-resolv" "server=127.0.0.1" $CONFIG

of course you will have to add what ever port stubby is listening on
this page gives some tips
https://wiki.archlinux.org/index.php/Stubby

 

[DonnyJohnny]

Thanks for taking your time to update your testing and result.

I will try out stabby over the weekend too.

I read somewhere, dns over tls seems better coz of lesser overhead compared to dns over https.

 

[skeal]

I hate to say it but, lead the way guys this is over my head. Keep up the good work, it looks like we will have this working soon!!

 

[Xentrk]

Here is a summary of where I'm at.

I append /tmp/etc/dnsmasq.conf updates required by stubby to work by placing the required parms in /jffs/config/dnsmasq.conf.add

# Need these for stubby.
#dnssec
no-resolv
server=127.0.0.1#5453

You can make the changes to dnsmasq.conf.add take effect by typing service restart_dnsmasq.

Note: I have the dnssec parm commented out for testing purposes as the https://1.1.1.1/help page does not report a working status when using DNSSEC.

Inside /tmp/etc/dnsmasq.conf, there is an entry for a DNS servers-file:

servers-file=/tmp/resolv.dnsmasq

In the Web-Gui, I set DNS Server 1 to 1.1.1.1, which writes the line:

server=1.1.1.1

to /tmp/resolv.dnsmasq.

I have to replace the entry created from the Web Gui with

server=127.0.0..1

for stubby to work over the WAN iface.

I will test this hack to get around the edit in the WAN gui page that prevents entering 127.0.0.1 as a DNS server to prevent having to update the /tmp/resolv.dnsmasq via a script.

nvram set wan0_dns1_x=127.0.0.1
nvram set wan_dns=127.0.0.1
nvram set wan_dns1_x=127.0.0.1
nvram set wan0_xdns=127.0.0.1
nvram set wan0_dns1_x=127.0.0.1
nvram commit
service restart_dnsmasq

Issues start to occur is when VPN Clients are involved. There are two DNS settings I have used for handling DNS when using VPN client - Exclusive or Strict.

In the OpenVPN Client, if I set Accept DNS Configuration = Strict, and in Custom Config section, add the entry dhcp-option DNS 127.0.0.1, stubby works over the VPN iface when /tmp/resolv.dnsmasq set to

server=127.0.0..1

. However, a DNS leak test will show the Cloudfare DNS servers, which will be near your ISP location.

The firmware creates /tmp/resolv.dnsmasq based on the DNS entries on the WAN gui and the VPN clients.

If you have Accept DNS Configuration = Strict and dhcp-option DNS 127.0.0.1, in a VPN client, the firmware creates an entry like this in /tmp/resolv.dnsmasq:

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=1.1.1.1

If you have Accept DNS Configuration = Exclusive in a VPN client, the firmware creates an entry like this in /tmp/resolv.dnsmasq:

server= 10.9.0.1
server= 10.8.0.1

server=1.1.1.1

I was hoping that a simple fix would be to change the last line from 1.1.1.1 to 127.0.0.1. But, I get routing issues and can't connect to sites.

If I have 5 VPN Clients running, /tmp/resolv.dnsmasq looks like this:

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
server= 10.9.0.1
server= 10.8.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=1.1.1.1

Accept DNS Configuration=Exclusive prevents DNS from leaking. A DNS leak test reports DNS IP as the IP address of the VPN server connected to. This setting uses the DNS servers pushed by your VPN provider. This setting bypasses dnsmasq when using Policy Rules or Policy Rules (Strict), which prevents Diversion from working over the VPN tunnel.

The work around to get Diversion to work over the VPN tunnel when using Policy Rules or Policy Rules (Strict), is to set Accept DNS Configuration = Strict and put the dhcp-option DNS 127.0.0.1 entry in the Custom Config section on the VPN Client.

However, when the VPN client is started, it will create three server entries, one for the dhcp-option entry and two for the DNS servers used by the tunnel. User script openvpnclient1.postconf (1 through 5) may be the best place to put an override of server=127.0.0.1 inside of /tmp/resolv.dnsmasq. I need a break and will pick it up tomorrow. If you only use a WAN iface, /jffs/scripts/dnsmasq.postconf appears to be a good place to override /tmp/resolv.dnsmasq with the server=127.0.0.1 entry.

What I may not be able to resolve is the issue that occurs when you want to use Accept DNS Configuration=Exclusive for one or more VPN clients, and Accept DNS Configuration=Strict for other VPN clients, combined with clients defined to use the WAN iface. The mix of server entries in the /tmp/resolv.dnsmasq file becomes an issue.

The other issue I was having is the stubby process was not running in the morning the first several days of my testing. I had no issues this morning. I will keep monitoring this.

For a final confirmation test, I plan to use Wireshark to confirm DNS traffic is being encrypted.

 

[tomsk]

can you include the port number of stubby in the dhcp-option entry on the VPN client?

 

[blueshark]

it will be nice a script to install and config


edit: sh*! dont have entware installed

 

[Xentrk]

can you include the port number of stubby in the dhcp-option entry on the VPN client?

It looks like I can. However, the multiple server entries still causes stubby not to resolve:

server= 127.0.0.1#5453
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
server= 10.9.0.1
server= 10.8.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=1.1.1.1

What is interesting is my laptop is defined to use OpenVPN client 4. When I bounced it after specifying the port, the server entries were first in the list.

Stubby appears to only resolve when /tmp/resolv.dnsmasq contains server= 127.0.0.1 or server= 127.0.0.1#5453. Prior testing shows it also worked when /tmp/resolv.dnsmasq was empty.

When I bounce a OpenVPN client, the firmware overwrites /tmp/resolv.dnsmasq. I confirmed that /jffs/scripts/openvpn-event will allow me to bypass the firmware behavior by placing the code to update /tmp/resolv.dnmasq in openvpn-event:

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

EDIT: Removed the command service restart_dnsmasq that was on the third line from the openvpn-event script above. It is not required and will break the firmware's ability to remove iptables DNS entries when the tunnel goes down and prevent removal of the /etc/openvpn/clientx-dns.sh script.

Going to take a peak at @john9527 Fork on github to see if I can get any ideas on how to proceed since he implemented stubby. I know he handles the behavior of DNS differently than asuswrt-merling for OpenVPN clients when using Accept DNS Configuration = Exclusive and Strict.

stubby was not running this morning. Issue requires more analysis to determine what is killing the process.

 

[Xentrk]

it will be nice a script to install and config


edit: sh*! dont have entware installed

Easy to do once I complete testing!

 

[Xentrk]

I set up a cron job to check the status of stubby every minute so I can correlate with system events that may be killing the process.

/jffs/scripts/Chk_Stubby.sh

#!/bin/sh
stubby_status=$(ps | grep stubby | grep -v grep)
logger -t "($(basename "$0"))" $$ "$stubby_status"

cron job entry

cru a Chk_Stubby "* * * * * sh /jffs/scripts/Chk_Stubby.sh"

cru l

<snip>
* * * * * sh /jffs/scripts/Chk_Stubby.sh #Chk_Stubby#

 

[tomsk]

according to the man page of dnsmasq

--servers-file=<file>
A special case of --conf-file which differs in two respects. Firstly, only --server and --rev-server are allowed in the configuration file included. Secondly, the file is re-read and the configuration therein is updated when dnsmasq receives SIGHUP.

and
--conf-file=<file>
Specify a different configuration file. The conf-file option is also allowed in configuration files, to include multiple configuration files. A filename of "-" causes dnsmasq to read configuration from stdin.

So not sure if that would override the server= entry you already have in dnsmasq.conf?

 

[Xentrk]

according to the man page of dnsmasq

--servers-file=<file>
A special case of --conf-file which differs in two respects. Firstly, only --server and --rev-server are allowed in the configuration file included. Secondly, the file is re-read and the configuration therein is updated when dnsmasq receives SIGHUP.

and
--conf-file=<file>
Specify a different configuration file. The conf-file option is also allowed in configuration files, to include multiple configuration files. A filename of "-" causes dnsmasq to read configuration from stdin.

So not sure if that would override the server= entry you already have in dnsmasq.conf?

I've been pondering an entry in dnsmasq for my own servers file. I have a concern that the default entry the firmware creates for servers=/tmp/resolv.dnsmasq would take precedence over an entry I create in dnsmasq.conf.add. I need more testing to confirm. But I was trying this with a another dnsamsq parameter the other day and that was the result.

I found the /tmp/resolv.dnsmasq file is updated when an OpenVPN client is bounced and at dnsmasq start. For now, I put code to update /tmp/resolv.dnsmasq (with the server=127.0.0.1 line) in /jffs/scripts/dnsmasq.postconf and /jffs/scripts/openvpn-event. So far so good. I'm monitoring now to see what is killing stubby overnight.

 

[Xentrk]

Stubby was running this morning. Perhaps the last edits I made to /jffs/scripts/dnsmasq.postconf and /jffs/scripts/openvpn-event to override the firmware populating /tmp/resolv.dnsmasq made the difference? I'll continue to monitor using the cron job I set up.

The issue with my hacks is OpenVPN clients that use Accept DNS Configuration = Exclusive will not be able to connect since the /tmp/resolv.dnsmasq no longer contains the DNS servers used by the tunnel, 10.9.0.1 and 10.8.0.1. The fix is similar to the hack I use to get Diversion to work over the OpenVPN tunnel. I don't understand this completely yet, but the firmware creates DNS 10.9.0.1 and 10.8.01 and routes it to the DNS of the VPN tunnel. See the log entry below:

Sep 14 08:20:58 RT-AC88U-8248 ovpn-client2[1452]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.9.0.1,dhcp-option DNS 10.8.0.1,route 10.24.0.1,topology net30,ping 5,ping-restart 30,compress,ifconfig 10.24.0.10 10.24.0.9,peer-id 1,cipher AES-128-GCM'

Adding these lines to the Custom Configuration section when Accept DNS Configuration = Exclusive fixes the issue:

dhcp-option DNS 10.9.0.1
dhcp-option DNS 10.8.0.1

LAN clients connected to the OpenVPN iface will now use the DNS provided by the VPN tunnel. ipleak tests will report the DNS as the same IP address as the VPN server connected to. LAN clients that use the WAN iface will use the DNS server specified in stubby!

This hack closes out the concern I had for OpenVPN users who require the Accept DNS Configuration = Exclusive setting.

In an earlier post, I provided three different stubby.yml configuration files. Each one worked. I want to understand the differences of the configurations better.

If stubby remains stable over the weekend, I'll have to assume the hacks to dnsmasq.postconf and openvpn-event fixed the issue with stubby process not running as I have no other explanation at this time. If stable, I'll work on an installer script for stubby and a how to guide in my x3mtek.com blog site.

 

[skeal]

@Xentrk once again you are totally awesome!! Brilliant work and problem solving. I've been following along to pick up what I can in knowledge. This is so cool..

 

[tomsk]

is there a port issue here?.... stubby will be trying to use port 853 whereas the regular DNS is port 53..perhaps what ever mechanism in deciding how to route the DNS requests (probably IPtables) is only looking at port 53?

 

[bigeyes0x0]

This is what I gathered from exp and speculation, haven't read the actual doc, but DoT should be a lighter protocol than DoH. The problem is the port it uses is not 443 by default like DoH. DoH completely masks DNS queries as HTTP request, it should help with a bunch of things.

As for getting this into my script as someone will probably ask, the work required (compiling for different platforms, testing, reintegrate some features I removed in my script as dnscrypt-proxy implemented them) is too much for me with other stuffs at the moment so not in any near future.

 

[Xentrk]

is there a port issue here?.... stubby will be trying to use port 853 whereas the regular DNS is port 53..perhaps what ever mechanism in deciding how to route the DNS requests (probably IPtables) is only looking at port 53?

Good question. I did look at that the other day and did not notice any conflicts. I ran another check and saw some orphaned iptables Chain for one of the VPN clients in DNSVPNx. This is the result of some work I am doing on a project. I went ahead and cleaned it up.

Many of the tutorials I found use the following is dnsmasq.conf and stubby.yml configuration with cloudfare DNS 1.1.1.1. The main one I used is from openwrt [Tutorial] DNS-over-TLS with dnsmasq and stubby (no need for unbound)

dnsmasq.conf.add

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

I find it works without having specifying the listen-address. For now, I have it commented out.

stubby.yml

<snip>
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"