English Forums > Tutorials and FAQs
FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
firewall:
directnupe,
thanks, as always, for your marvelous write-ups surrounding DNS PRIVACY. i commend you again for your efforts.
it should be noted here that nextdns will sunset their beta program in june and will henceforth enforce their monthly limit of 300,000 queries for free accounts. an unfortunate fact, however it is an affordable fee and will certainly still be worthy of consideration for many.
regards,
firewall
mrancier:
--- Quote from: directnupe on May 20, 2020, 10:49:35 pm ---
--- Quote from: mrancier on April 29, 2020, 01:32:45 am ---trying to get this to work with nextdns or blockerdns, but although stubby runs, when I try to dig the server to test it I get "WARNING: recursion requested but not available".
Running latest production 20.1.5.
Any help would be appreciated.
--- End quote ---
Dear mrancier,
Hello and I hope that you are both safe and well. Forgive me for not getting back to you earlier. My main router is OpenWRT and I use both nextdns and blockerdns. I just ran the dig commands for both of these with no issues. Now - to be transparent, I am running getdns stubby and unbound on localhost ( 127.0.0.1 ) on my OpenWRT router. So try changing to that setup and test it ( you know troubleshooting ). Here below for how to : https://forum.opnsense.org/index.php?PHPSESSID=k6ivse7g94849ga6nk9r8kg9g5&topic=13487.0
The other possibility could involve how you are configuring blockerdns and nextdns respectively. See here for nextdns demo and illustration : https://nextdns.io/ - Click on " Try It Now For Free "
you must append your own prefix to the DNS OVER TLS endpoint ( see this entry at the very bottom of the page ) :
DNS-over-TLS
Prepend the name to the provided domain (the name should only contain a-z, A-Z, 0-9 and -). Use -- for spaces.
For "John Router", you would use John--Router-f7fc55.dns.nextdns.io as your DNS-over-TLS endpoint.
That may solve your issue on nextdns. As for blockerdns - Tambe recently changed his IP addresses - use the following command line entry to determine them for yourself:
dig +short abcdefgh.blockerdns.com ( where abcdefgh is your blockerdns "username" ) see here : https://blockerdns.com/overview read the section here :
Do I get a username and/or password to use blockerDNS? How do you know I'm actually a user if all I'm doing is putting in a DNS server in my settings?
If you're accessing our service via DNS over TLS or DNS over HTTPS, the way we handle authentication is by giving you a unique URL to put as your setting. It'll be something like asdfghjkl.blockerdns.com. The first portion is what serves as your "username".
You must be careful and precise when entering server - address_data: tls_auth_name: and value: for SPKI key - hope this helps and stay safe
--- End quote ---
I've setup things in copy/paste fashion from your instructions and it will resolve, exactly, one query correctly and then changes to SERVFAIL. If I restart stubby it does the same thing : First query works, every subsequent query fails. Again, this is with the exact same config you posted, save for the LAN address. Not sure what is going on. Any help is, naturally, appreciate it.
Koldnitz:
Directnupe,
Thanks you for the awesome write up.
Please note a few things that I noticed messing with this all last weekend / finally fixed today.
A - Issue this command :
# mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh
Make it executable - I run two commands - it works for me:
# chmod 744 /usr/local/etc/rc.d/stubby.sh # chmod a+x /usr/local/etc/rc.d/stubby.sh
You do need not to do this part.
Out of the box installed via the pkg manager /usr/local/etc/rc.d/stubby will work / start correctly.
I was unable to get stubby to work with any TLS Server that did not include a pinset
Using the method Directnupe linked to where openssl calculated a server's pinset, allowed me to use cloudflare / google DNS servers.
This was not an optimum solution because they change their certificates (google did theirs today it seems), and your DNS servers would stop working / you will have to recalculate the pinset.
Without the tls_pubkey_pinset I would get the following error in stubby's logs:
unable to get local issuer certificate
I do not understand why tls_ca_path will not work. It did not work for me in unbound either, hence me using Directnupe's write-up.
Then it did not work with stubby.
Furthermore, I have noticed that opnsense does not make the symbolic link to /etc/ssl/cert.pem (the package options are set to not make symbolic links for some reason), but it seems to be installed nevertheless (?) at the same time ca-root-nss package was. The wisdom on these forums seem to be to use the cert.pem, but elsewhere I have seen it said to use ca-root-nss.crt.
***************SUPER IMPORTANT***********************************
*******The way to fix this on opnsense 20.1.8_1*****************
Use nano to edit /usr/local/etc/stubby/stubby.yml
Change:
tls_ca_path: "/etc/ssl/"
to
tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt"
or
tls_ca_file: "/etc/ssl/cert.pem"
I have confirmed that my cert.pem file appears to be identical with the ca-root-nss.crt file but with the addition of my opnvpn certificate.
Now it works.
I have disabled tls_pubkey_pinset on cloudflare and google dns servers and everything is working correctly.
I hope this helps someone.
Cheers,
Nekromantik:
have this working but first time you visit website it does add a long delay
anyway to make this quicker?
Koldnitz:
Nekromantik,
The DNS servers recommended in the original post were very slow for me (Texas).
I am using cloudflare (1.1.1.1 and 1.0.0.1) and recursion time usually ends up looking like this on the unbound statistics tab: 0.16 average and 0.1 median.
Cloudflare is by far the fastest DNS, and mixing it with google and quad 9 noticeable slows things down. When you throw NextDNS in the mix it gets even slower.
When I used the Directnupe's recommended A+ servers based in the USA it was averaging 1.5 seconds for a recursion. Those servers are based in East / West coast so it might be where I am located geographically.
I also messed around with the TTL on unbound and made it serve expired and it seemed to up the amount of cache hits significantly.
Using only Cloudflare with Stubby/Unbound cache I do not notice any difference from when I was just using unbound to forward to Cloudflare / Google servers from the general setting DNS area.
Cheers,
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version