Stubby-Installer-Asuswrt-Merlin

[Adamm]

One recommendation is to include proxy-dnssec in dnsmasq.conf.add

Another FYI....also automatically done in my fork with stubby enabled and you are not using dnsmasq's dnssec support.

This could be added quite easily, unfortunately I don't know enough about stubby/dnsmasq to know the adverse effects. If I get the thumbs up here that it won't cause unrelated issues I can post a commit.

 

[bbunge]

This could be added quite easily, unfortunately I don't know enough about stubby/dnsmasq to know the adverse effects. If I get the thumbs up here that it won't cause unrelated issues I can post a commit.

My testing has shown that with DNSSEC enabled in Stubby you need proxy-dnssec in dnsmasq.config.add. When using DNSSEC in Merlin, which uses dnsmasq for DNSSEC it may not be needed. I've run DNSSEC both ways with the proxy-dnssec in dnsmasq.conf.add with no bad results.
Of course this poses the question which is the right way to run DNSMASQ? The answer... either. I believe it will be easier to enable and disable in Merlin as there is a gui "switch."

A word of caution, however: Some DNS resolvers still do not play well with DNSSEC. Cloudflare is the only one I have had consistent good results with. Yes, everyone including me has their security concerns and for now I'm using CleanBrowsing Security DNS without DNSSEC. I feel their service does a pretty good job filtering "bad" web sites.

 

[Xentrk]

You can add the RT-AC5300 to your list, I am passing all the tests for "validating-that-stubby-is-working" on the project page.

I am still reading over some of the topic, so I’ll hold a few questions that I have for a bit longer.

Thanks for letting me know. I updated the list on this thread and on GitHub.

 

[Xentrk]

I've installed this months ago as instructed in OP.
I have been reading in this thread about updates and other forks, will the OP get updated to show how to update to latest version?
Thanks for info.

Sorry for the delay in reply. I was traveling and got sick upon my return home and just now getting back on my feet.

Yes, I'll update the OP and collaborate with @Jack Yaz best way to proceed going forward to eliminate any confusion between the original installer and the Fork.

 

[Xentrk]

Took the plunge and installed Stubby with @Jack Yaz's patches for the 86U. All the tests check out including the cloudfare help. Super cool. 2 things I noted:

@preacher65's comment about changing the echo | openssl line worked, but I think the correct command is supposed to be:

echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853

to ensure the Entware certs were correctly installed. That worked as well and makes more logical sense to me at least since you want to check that those certs were correctly installed.

The beta version of the Installer Script used the certificate in the ca-certificates package that is installed in /opt/etc/ssl/certs. Shortly before going live on the forum, I decided to use the default certificate that is installed in the firmware in /rom/etc/ssl/certs. Doing so eliminated the need to install the ca-certificates package. So, if you use the default firmware location, stubby.yml will have the line:

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

If the user wants to use the entware ca-certificates certificate, the line in stubby.yml needs to be:

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

 

[Adamm]

Yes, I'll update the OP and collaborate with @Jack Yaz best way to proceed going forward to eliminate any confusion between the original installer and the Fork.

This pull request contains all the changes present on the fork. Assuming the pull request is accepted, a commit can be pushed to the fork which changes the update url back to the master branch (seamlessly switching users back over). I am very much in favor of less fragmentation and continued collaboration in a unified repo.

 

[Xentrk]

This pull request contains all the changes present on the fork. Assuming the pull request is accepted, a commit can be pushed to the fork which changes the update url back to the master branch (seamlessly switching users back over). I am very much in favor of less fragmentation and continued collaboration in a unified repo.

Thank you @Adamm. I got caught up on the thread. I fell ill after returning from my travels and am starting to get back on my feet. I'll start looking at the pull request and see if I can get it done no later than Friday, perhaps even tomorrow. Like to have it ready for the weekend warriors to use. Having the all of the changes incorporated back into the original installer script will eliminate confusion. Glad to see that all router models are now supported.

I also want to say thank you to @Odkrys for updating Stubby for the HND routers and other collaborators @Jack Yaz, @bbunge, @skeal and everyone else who contributes and helps users on the forum. Grateful!

 

[cmkelley]

The beta version of the Installer Script used the certificate in the ca-certificates package that is installed in /opt/etc/ssl/certs. Shortly before going live on the forum, I decided to use the default certificate that is installed in the firmware in /rom/etc/ssl/certs.

Sorry, I was referring to the validation steps in the README - it used to have instructions that wouldn't work, I see it's been fixed now.

Sorry to hear you've been ill. Hope it was nothing serious and you are 100% again soon!

 

[bbunge]

Google announced that their public Domain Name System (DNS) service now comes with support for the DNS-over-TLS security protocol which wraps DNS queries and answers using the Transport Layer Security (TLS) protocol.

https://www.bleepingcomputer.com/ne...s-over-tls-support-to-its-public-dns-service/

 

[skeal]

Google announced that their public Domain Name System (DNS) service now comes with support for the DNS-over-TLS security protocol which wraps DNS queries and answers using the Transport Layer Security (TLS) protocol.

https://www.bleepingcomputer.com/ne...s-over-tls-support-to-its-public-dns-service/

How about that. I guess we should expand the server list in the .yml file.

 

[cmkelley]

Google announced that their public Domain Name System (DNS) service now comes with support for the DNS-over-TLS security protocol which wraps DNS queries and answers using the Transport Layer Security (TLS) protocol.

https://www.bleepingcomputer.com/ne...s-over-tls-support-to-its-public-dns-service/

Heh, yeah, protect your DNS queries from everyone except the entity most likely to scrape them and sell the results to ad companies.

If you live in a country where the government scraping your DNS to find evidence against you, you probably shouldn't be using Google DNS, Google will be more than happy to sell your DNS records to whoever wants to pay the going rate.

 

[skeal]

Heh, yeah, protect your DNS queries from everyone except the entity most likely to scrape them and sell the results to ad companies.

If you live in a country where the government scraping your DNS to find evidence against you, you probably shouldn't be using Google DNS, Google will be more than happy to sell your DNS records to whoever wants to pay the going rate.

Still should be a choice, some people don't care about google and there analytics.

 

[bbunge]

Am trying to figure out the tls_auth_name: for Google. Not finding it via Google search...

Without that Stubby fails...

 

[skeal]

Am trying to figure out the tls_auth_name: for Google. Not finding it via Google search...

Without that Stubby fails...

How about trying dns.google.com When I ping it, it responds. Total guess though.

 

[dave14305]

How about trying dns.google.com When I ping it, it responds. Total guess though.

I’ve seen references to just dns.google as well.

 

[cmkelley]

Still should be a choice, some people don't care about google and there analytics.

I don't disagree. Just seems ironic to use something like DoT to access google's DNS.

 

[Xentrk]

I’ve seen references to just dns.google as well.

Looks like dns.google is the name of the resolver. Technical details on the developers google site:

https://developers.google.com/speed/public-dns/docs/dns-over-tls

 

[bbunge]

Looks like dns.google is the name of the resolver. Technical details on the developers google site:

https://developers.google.com/speed/public-dns/docs/dns-over-tls

Actually if you ping dns.google it returns 8.8.4.4

I tried dns.google.com earlier and it did not work

 

[dave14305]

This config worked on Johns fork:

upstream_recursive_servers:
# Google Primary
  - address_data: 8.8.8.8
    tls_auth_name: "dns.google"
# Google Secondary
  - address_data: 8.8.4.4
    tls_auth_name: "dns.google"

 

[bbunge]

This config worked on Johns fork:

upstream_recursive_servers:
# Google Primary
  - address_data: 8.8.8.8
    tls_auth_name: "dns.google"
# Google Secondary
  - address_data: 8.8.4.4
    tls_auth_name: "dns.google"

Works on Stubby, too.