Stubby-Installer-Asuswrt-Merlin

[skeal]

Can you run this command please?

stubby -C /opt/etc/stubby/stubby.yml -i

Read the bottom line please.

 

[TheUntouchable]

I am now a little bit confused.. I had to reinstall stubby to be able to execute that command, but now the installation worked and stuppy could be started..

Anyway, here the bottom line:
Result: Config file syntax is valid.

 

[skeal]

I am now a little bit confused.. I had to reinstall stubby to be able to execute that command, but now the installation worked and stuppy could be started..

Anyway, here the bottom line:
Result: Config file syntax is valid.

perfect that's what you want. If you make any changes to the stubby.yml run this command to check if your changes are recognized properly.

 

[PeterV]

Only to share some info, it's not a complain, but:

• I have a AC86U, stubby installed and configured to use cloudflare, google and quad9, via ipv4, i.e. - 5 upstreams.
• I had a monitoring tool (via monit) to check the stubby resolving directly via

  /opt/bin/drill one.one.one.one @127.0.0.1 -p 5453 A IN | grep -c 'A\s1\.[01]\.[01]\.1'

• In normal circumstances it have to return value 2 (i.e. 1.1.1.1 & 1.0.0.1)
• it make checks every 15 second (approximately)
• And I have an error messages every 2-3-5 minutes
• Spoiler: log entries

  2019-03-19T21:27:56+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:32:07+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:33:41+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:35:13+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:38:50+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:40:22+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:46:22+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:51:43+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:56:18+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:57:04+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:02:48+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:05:28+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:06:26+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:07:34+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:10:14+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:10:37+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:16:45+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:19:03+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:26:52+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0

If I will look at the stubby log - there is nothing related.
It I will look via stubby -l - then I will see the terminating the session to the all upstreams in more or less the same second or two. May be it's related to such stubby behavior with round-robin=1

 

[Adamm]

I've pushed v1.1.0

Use DNSFilter instead to force DNS requests
Refresh IPv6 prefix on nat-start event
Revert DNS to ISP default on uninstall

@shark

 

[Jack Yaz]

I've pushed v1.1.0

Use DNSFilter instead to force DNS requests
Refresh IPv6 prefix on nat-start event
Revert DNS to ISP default on uninstall

@shark

That looks like it blows away any other dnsfilter rules, is that right?

 

[Adamm]

That looks like it blows away any other dnsfilter rules, is that right?

If you choose to enable it, yes. That way a working install can be insured.

 

[skeal]

If you choose to enable it, yes. That way a working install can be insured.

This is a much better way of handling the forced dns through Stubby. Great work @Adamm !!

 

[bbunge]

If you choose to enable it, yes. That way a working install can be insured.

I guess I do not see the need for a change when firewall rules work quite well why would you mess with DNS filter? My guess is most people do not use DNS filter and it is something else to scrub manually if a thumb drive fails. Might also be good to run changes to the stubby install by the original testers if, for no other reason, a consensus.

Sent from my SM-T380 using Tapatalk

 

[skeal]

I guess I do not see the need for a change when firewall rules work quite well why would you mess with DNS filter? My guess is most people do not use DNS filter and it is something else to scrub manually if a thumb drive fails. Might also be good to run changes to the stubby install by the original testers if, for no other reason, a consensus.

Sent from my SM-T380 using Tapatalk

Although I can appreciate your concern (as one of the original testers) @Adamm has contributed a great deal to this script, which in my opinion is no longer in testing (like Skynet, Diversion etc.) and needs to be supported for his efforts. I for one do not wish him to become discouraged because of this negative feed back. Sorry mate but the testing is over, feedback is great but untoward leverage is not (no harm meant). Thank you everyone who supports our script writers.

 

[EmeraldDeer]

That looks like it blows away any other dnsfilter rules, is that right?

In my case I replied Yes, but it did not blow away anything. Perhaps the risk is only to OpenVPN client users.

Would you like to force all client DNS requests through Stubby
[1]  --> Yes
[2]  --> No

[1-2]: 1

This setting is incompatible with DNSFilter
No active OpenVPN Clients found. Skipping creation of /jffs/scripts/openvpn-event
If you decide to run an OpenVPN Client in the future, rerun the installer script
to update /jffs/scripts/openvpn-event
 Shutting down stubby...              done.
 Starting stubby...              done.
Installation of Stubby completed

 

[skeal]

No active OpenVPN Clients found. Skipping creation of /jffs/scripts/openvpn-event If you decide to run an OpenVPN Client in the future, rerun the installer script to update /jffs/scripts/openvpn-event

This part of the scripts output is saying that you don't have a OVPN client configured and that if you do configure one to re-run the script to add the openvpn-event to scripts.

 

[skeal]

This setting is incompatible with DNSFilter

I didn't see this output when updating.

 

[skeal]

In my case I replied Yes, but it did not blow away anything. Perhaps the risk is only to OpenVPN client users.

Would you like to force all client DNS requests through Stubby
[1]  --> Yes
[2]  --> No

[1-2]: 1

This setting is incompatible with DNSFilter
No active OpenVPN Clients found. Skipping creation of /jffs/scripts/openvpn-event
If you decide to run an OpenVPN Client in the future, rerun the installer script
to update /jffs/scripts/openvpn-event
 Shutting down stubby...              done.
 Starting stubby...              done.
Installation of Stubby completed

This is what I have in DNS Filtering:

 

[EmeraldDeer]

I didn't see this output when updating.

Perhaps this was a message from an earlier version. I updated Stubby Configuration before updating install_stubby.sh. The other way around would have been preferable.

I have the same DNSfilter settings as you.

 

[Adamm]

In my case I replied Yes, but it did not blow away anything. Perhaps the risk is only to OpenVPN client users.

That output indicates you are still using the old version of the script. Update the script first then run the installer

 

[Xentrk]

This is what I have in DNS Filtering:

Thanks for the screen picture. I will need to add it to the README.md so people have a visual on how DNS Filter is enabled to force LAN clients to use Stubby. I only experimented with DNS Filter briefly in the distant past to confirm that setting DNS in the DNS Filter will break Diversion ad blocker.

 

[PeterV]

Only to share some info, it's not a complain, but:

• I have a AC86U, stubby installed and configured to use cloudflare, google and quad9, via ipv4, i.e. - 5 upstreams.
• I had a monitoring tool (via monit) to check the stubby resolving directly via

  /opt/bin/drill one.one.one.one @127.0.0.1 -p 5453 A IN | grep -c 'A\s1\.[01]\.[01]\.1'

• In normal circumstances it have to return value 2 (i.e. 1.1.1.1 & 1.0.0.1)
• it make checks every 15 second (approximately)
• And I have an error messages every 2-3-5 minutes
• Spoiler: log entries

  2019-03-19T21:27:56+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:32:07+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:33:41+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:35:13+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:38:50+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:40:22+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:46:22+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:51:43+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:56:18+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T21:57:04+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:02:48+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:05:28+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:06:26+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:07:34+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:10:14+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:10:37+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:16:45+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:19:03+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0
  2019-03-19T22:26:52+02:00 192.168.99.1 monit[2030]: 'stubby_is_ok' status failed (1) -- 0

If I will look at the stubby log - there is nothing related.
It I will look via stubby -l - then I will see the terminating the session to the all upstreams in more or less the same second or two. May be it's related to such stubby behavior with round-robin=1

It's look like I found the root casue - it's a google dns via TLS.
After removing Google DNS upstream the issus looks like gone ...

 

[shark]

I've pushed v1.1.0

Use DNSFilter instead to force DNS requests
Refresh IPv6 prefix on nat-start event
Revert DNS to ISP default on uninstall

@shark

Thank you

 

[Elmer]

As soon as I remove the # from the two lines following "Quad 9 Secure Primary" and restart stubby, it dies. What am I doing wrong?

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