Info: Stubby 0.2.3 (latest) is on entware.

[Xentrk]

Ic.
Another question. Noted that @bigeyes0x0 made the dnscrypt-proxy to execute as nobody (ownership). How do we do that for Stubby?

I notice that when I do a restart command for stubby in terminal. While terminal is active, Stubby is alive. After I shut down (exit) terminal, somehow stubby is terminated.

I've been running Stubby as the admin user. Good feedback though. Something to consider since there is precedent with other services as well e.g. pixelserv-tls. I'll look into this.

 

[DonnyJohnny]

Perhaps Stubby is not consuming enough memory to display on htop? Try these commands:

ps | grep stubby | grep -v grep

netstat -lnptu | grep stubby

Nope. Don’t think is htop being not enough memory to display.
Empty result from the 2 commands above after coming back from exiting terminal.

 

[Xentrk]

@Xentrk
I don’t see the file for “/opt/var/log/stubby.log”
After a reboot, stabby is working. How do we see stabby log if any?
How do we print the stabby log to syslog?

For me, the webgui cannot put 127.0.0.1 but we have just input the router IP address. Example 192.168.1.1
This will save the hack that you made to force change using nvram.

I didn’t use the check if stabby is available. I will monitor at my side if stabby stop working after some time.

Meanwhile, I can see that stabby is using must lesser memory than dnscrypt-proxy.

I have another question. How do we stop router from resolving ipv6 like in dnscrypt-proxy.

Yes, the web gui does not let one put 127.0.0.1 inside the DNS 1 or DNS 2 fields. What I have settled on for now, is placing code in /jffs/scripts/dnsmasq.postconf and /jffs/scripts/openvpn-event to

cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq

Where /jffs/configs/resolv.dnsmasq contents is server=127.0.0.1. Whatever you put in the Web GUI will now be overwritten when dnsmasq is started or a VPN Client is bounced. Otherwise, the firmware will update /tmp/resolv.dnsmasq with the values from the Web GUI, which will cause stubby to no longer resolve.

 

[DonnyJohnny]

Perhaps Stubby is not consuming enough memory to display on htop? Try these commands:

ps | grep stubby | grep -v grep

netstat -lnptu | grep stubby

Having a nohup under preargs, solved my issue.

#!/bin/sh

ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS="nohup"
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

 

[DonnyJohnny]

Yes, the web gui does not let one put 127.0.0.1 inside the DNS 1 or DNS 2 fields. What I have settled on for now, is placing code in /jffs/scripts/dnsmasq.postconf and /jffs/scripts/openvpn-event to

cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq

Where /jffs/configs/resolv.dnsmasq contents is server=127.0.0.1. Whatever you put in the Web GUI will now be overwritten when dnsmasq is started or a VPN Client is bounced. Otherwise, the firmware will update /tmp/resolv.dnsmasq with the values from the Web GUI, which will cause stubby to no longer resolve.

Is there difference or advantage in using 127.0.0.1 over router’s ip (ie. 192.168.1.1)

 

[Xentrk]

Nope. Don’t think is htop being not enough memory to display.
Empty result from the 2 commands above after coming back from exiting terminal.

I've had a few strange errors with some entware packages lately. Running the opkg update command fixed it every time. See if that helps. I"ll look into running Stubby as "the nobody user" next and see how it runs. Maybe that will fix your issues.

Also, try running /jffs/scripts/dnsmasq.postconf from the command line so see if you have errors. Check the system log and see if dnsmasq has any SIGTERM errors.

/jffs/scripts/dnsmasq.postconf

#!/bin/sh
. /opt/share/diversion/file/post-conf.div # Added by Diversion
# Override firmware dns servers
cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq

/jffs/configs/resolv.dnsmasq

server=127.0.0.1

 

[Xentrk]

Is there difference or advantage in using 127.0.0.1 over router’s ip (ie. 192.168.1.1)

All of the examples I found on the web used 127.0.0.1 as the internal DNS server IP address. I would have to test using the router's IP address.

In /jffs/configs/dnsmasq.conf.add, we tell dnsmasq to use 127.0.0.1 port 5453:

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

/opt/etc/stubby/stubby.yml listens internally on 127.0.0.1 port 5453 and sends upstream queries to 1.1.1.1, port 853:

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

 

[Xentrk]

That’s what I did and the moment I exit terminal with the exit command. Somehow it terminate the stubby process and I can’t surf anymore. I went back to use htop to check. Confirmed process is terminated.
Only when I use

nohup stubby -g -v 5 &

then process is retain even after closing terminal.

You reminded me that @John9527 experienced a similar issue when getting Stubby to work on MIPS CPU routers.

I have a AC68U that I use as an AP for my pfSense box. I need to re-purpose as a router for a family member soon. I will test Stubby in the process and let you know if I have issues.

UPDATE: I just changed to another version of a stubby.yml file. When I exited the shell, Stubby stopped working!

 

[john9527]

You reminded me that @John9527 experienced a similar issue when getting Stubby to work on MIPS CPU routers.

The MIPS problem was very specific, and showed up as a failure to start with return code 55. The stubby code needed to be patched to fix it, so your solution wouldn't work for any MIPS routers running 380 or earlier (not sure if stubby is even in the earlier entware repro that supports MIPS, so may be a mute issue)..

 

[DonnyJohnny]

You reminded me that @John9527 experienced a similar issue when getting Stubby to work on MIPS CPU routers.

I have a AC68U that I use as an AP for my pfSense box. I need to re-purpose as a router for a family member soon. I will test Stubby in the process and let you know if I have issues.

UPDATE: I just changed to another version of a stubby.yml file. When I exited the shell, Stubby stopped working!

I have tried a few restart of stubby with “/opt/etc/init.d/S61stubby restart”. There is no issue even after exit shell.
The nohup under PREARGS in S61stubby solved the problem.

I had also added Quad9 9.9.9.9 (DNSSEC) in my yml since they have server in my country. Take note that 9.9.9.10 do not have DNSSEC.

 

[Xentrk]

I have tried a few restart of stubby with “/opt/etc/init.d/S61stubby restart”. There is no issue even after exit shell.
The nohup under PREARGS in S61stubby solved the problem.

I had also added Quad9 9.9.9.9 (DNSSEC) in my yml since they have server in my country. Take note that 9.9.9.10 do not have DNSSEC.

Thanks for the update @DonnyJohnny ! Strange how the issue started for me this morning. I'm confused. I did update to 380.7 Beta 2 this morning. I doubt that is the cause as I also made some other changes that were causing issues. I'll keep plugging away.

I had to disable DNSSEC in the webgui in order for the 1.1.1.1/help site to work. It does not support DNSSEC. If I recall, DNSSEC works with Stubby when I comment out in DNSSEC in dnsmasq.conf.add. I''ll have to test this some more.

You can use the sites @HowIFix posted here for additional testing.

 

[Xentrk]

I did not do a power cycle on the router after the Beta 2 upgrade. So, I just did one. That appears to have fixed the issue with the Stubby process being killed when I exited the SSH session.

 

[Xentrk]

I have tried a few restart of stubby with “/opt/etc/init.d/S61stubby restart”. There is no issue even after exit shell.
The nohup under PREARGS in S61stubby solved the problem.

I had also added Quad9 9.9.9.9 (DNSSEC) in my yml since they have server in my country. Take note that 9.9.9.10 do not have DNSSEC.

I think it is a good idea to standardize the stubby.yml file that @john9527 uses in the Fork. Some changes are required though:

• tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt
  
• appdata_dir: "/opt/var/cache/stubby"

You can remove the comments ( # ) for the Quad9 DNS if you prefer to use Quad9. I had included the secondary IPv4 server address for Cloudfare (1.0.0.1) in my prior testing but removed that reference to standardize with what @john9527 has done on the Fork.

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"

 

[john9527]

You can remove the comments ( # ) for the Quad9 DNS if you prefer to use Quad9. I had included the secondary IPv4 server address for Cloudfare (1.0.0.1) in my prior testing but removed that reference to standardize with what @john9527 has done on the Fork.

Remember, on my fork there is a selection box where you can select any of the 30 or so defined servers.....so the server selection is a personal choice.

https://www.snbforums.com/threads/f...lts-releases-v34e3.18914/page-398#post-426091

 

[Xentrk]

Remember, on my fork there is a selection box where you can select any of the 30 or so defined servers.....so the server selection is a personal choice.

https://www.snbforums.com/threads/f...lts-releases-v34e3.18914/page-398#post-426091

Do you know if any of the other TLS supported servers have a test site like https://1.1.1.1/help?

Some people may be interested in DNS Performance Analytics and Comparison
Authoritative DNS providers https://www.dnsperf.com/
Public DNS resolvers https://www.dnsperf.com/#!dns-resolvers

 

[DonnyJohnny]

Just wondering how stubby divert dns queries to upstream 853.

My thinking.
When we surf the net, does the dns queries goes thru 53 then reroute to 127.0.0.1#8453 the stubby as proxy the queries to upstream dns 853. Am I right?

Is the below iptables command still valid to force all 53 to router ip or 127.0.0.1, idea is to make sure no dns leak .

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)

 

[skeal]

I am such a geek! I am so stoked about this project!! Keep up the solid work you guys...together you can do this!..

 

[tomsk]

Just wondering how stubby divert dns queries to upstream 853.

My thinking.
When we surf the net, does the dns queries goes thru 53 then reroute to 127.0.0.1#8453 the stubby as proxy the queries to upstream dns 853. Am I right?

Is the below iptables command still valid to force all 53 to router ip or 127.0.0.1, idea is to make sure no dns leak .

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)

dnsmasq will listen for dns requests on 127.0.0.1 port 53 by default so those IP tables are still good for that.
dnsmasq will then forward the requests to stubby at 127.0.0.1 on what ever port you have selected for it. Stubby will then do its encryption magic and forward the request to the upstream dns on port 853

 

[john9527]

One thing to consider though....if you are using QoS and have a rule to prioritize DNS, that will need to be updated to support port 853 since that is now the DNS port (kudos to @ColinTaylor for figuring this one out!)

 

[tomsk]

One thing to consider though....if you are using QoS and have a rule to prioritize DNS, that will need to be updated to support port 853 since that is now the DNS port (kudos to @ColinTaylor for figuring this one out!)

he's clever like that