Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - directnupe

Pages: [1] 2 3 4

Tutorials and FAQs / Re: OPNsense 21.7.1 - New Fresh Guaranteed DNS OVER TLS

« on: November 18, 2021, 09:02:24 am »

Quote from: opnfwb on November 04, 2021, 11:43:45 pm

Quote from: comet on November 04, 2021, 07:33:54 pm
Thank you for explaining all that. I took a look at the Unbound configuration and saw what you are talking about, the only thing I don't really understand is that there is a field for "Verify CN" (the help tip is "Verify if CN in certificate matches this value") but I am not sure what you are supposed to put there. If you look at the list of servers in the top post there is nothing indicated as a "CN"; I do see that most have "tls_pubkey_pinset" entries but I assume that's not the same thing.
With all due respect and I don't mean this negatively but this shows you haven't look in to how DoT works. You'll either need a pinset or ideally, avoid using a pinset and instead have the TLS connection match with the dns name issued to the certificate so that the resolver can verify that the queries are actually coming from an intended source (dns.quad9.net, one.one.one.one, etc. etc.). This is no doubt more complicated than "regular" DNS, but then again so is an Unbound resolver (which OPNsense ships with by default) compared to a dnsmasq based forwarder configuration in most consumer gear.

Quote from: comet on November 04, 2021, 07:33:54 pm
The other thing is there are no default or suggested entries; ..... Or failing that, a link to an article somewhere that contains that information.
Stubby ships with a default config. The DoT providers that you wish to use will need to be your own decision. It's quite normal to not ship a list of defaults because people may not want them or even worse, they could end up being monetized and not in a user's interest for privacy. Again the rule here is if you're going to enable DoT, you'll need to do a small amount of searching to understand it and make the choice which provider you think has your best interests in mind. I wouldn't expect OPNsense devs, or anyone else for that matter, to do that for me.

Again not trying to sound like a "let me google that for you" post but this is all covered extensively here in the forums over many years (DoT was first launched with an Unbound update back in April 2018).

Basic info here and some config examples (note, the config isn't needed because new OPNsense does that for you with the DoT GUI page): https://www.ctrl.blog/entry/unbound-tls-forwarding.html

A discussion about the two major DoT providers, CloudFlare and Quad9, and additional input from Quad9's management. CloudFlare also posts in that thread with their input.: https://www.snbforums.com/threads/cloud9-dns.56918/

Quote from: comet on November 04, 2021, 07:33:54 pm
Maybe DNS over TLS is too new, or there really are that few servers that support it, if so I apologize if I am asking for too much, but I am just trying to understand if this is something that is possible. As for the comment about the article being for those "that wish to try something a bit more performant than Unbound DoT", I guess I would say that while I suppose everyone would like maximum performance (however they define that), not everyone has the time, patience, or ability to learn how to tweak things to the very max (that's as true of computer networking as it is of mechanical things such as car engines). I would just be happy if it works reliably and doesn't become a bottleneck to network traffic.
If you just want working and reliable DoT with minimal configuration, the built in DoT GUI page in OPNsense is the way to go. Choose a DoT provider, input their port, IP, DNS name and you're up and running.

You also need to be aware of the differences between a resolver and a forwarder. Anytime you go DoT, you're always putting all of your trust in the provider you choose to forward your queries to. You're essentially abdicating the resolver portion of Unbound and just having it forward all of its queries to a chosen provider. Yes, they will be encrypted so that your ISP can't see them, but the provider can still decrypt and see them. So you're exchanging anonymity at the DNS level for anonymity between your ISP and your DNS traffic.

OPNsense ships by default in resolver mode, which means all of your DNS queries are sent in plaintext so that your ISP (or anyone else) in the middle can potentially see them, but the queries are sent randomly to hundreds of various root servers and the local Unbound service within OPNsense resolves them and caches them. OPNsense also has two easy check boxes during the initial setup to enable DNSSEC in resolver mode, which adds an additional layer of security from the root resolvers (there's those nice check boxes again ) The likelihood that a single DNS provider would be able to get enough metadata on your network activity would be reduced, at the expense of everyone else being able to potentially see it on the wire. It's always a trade off. You need to educate yourself and decide. And yes, most people just give up and use consumer gear or just use the defaults at this stage in the game.

Thanks for taking the time and patience to try to explain things to do guy. God Bless You. Check out my new work :

https://forum.opnsense.org/index.php?topic=25614.0

Peace

Tutorials and FAQs / Re: OPNsense 21.7.1 - New Fresh Guaranteed DNS OVER TLS

« on: November 18, 2021, 08:59:35 am »

Quote from: comet on November 02, 2021, 12:34:58 pm

To start with I am not in any way knocking you for posting these instructions, I'm sure you took a lot of time to write them up and for that you should be commended. But what I find incredible is that you have to go through all this in the first place. I am sorry, but this is just WAAAAAY too difficult for any average user (and maybe some readers think only technically minded people use OPNsense, but that's not necessarily true). This kind of reminds me of the method you had to use to set up an Internet connection back in the very early days of Windows, until Microsoft came out with a version of Windows that made setting up network connectivity relatively painless.

What OPNsense needs is a page specifically for enabling DNS over TLS, that would be used by both OPNsense itself and by any device on the local network that uses the OPNsense IP address for DNS (including devices that use DHCP to get their network connectivity information). And that page should have exactly two things:

A checkbox to enable or disable DNS over TLS
A textbox with a list of servers capable of receiving DNS over TLS queries (and/or alternately, checkboxes to enable or disable certain popular and well-known servers)

And that's ALL. If anything else is needed then OPNsense should assume sensible defaults, and not trouble the user about them. For those that simply must have the ability to tweak, you could have an Advanced Settings section, but this should be pre-populated with a working configuration.

Features that are hard to use don't get used, except by a very small minority that actually has the knowledge and patience to use them. OPNsense is really bad about making some features much harder to use than they should be. Another example of this is intrusion detection - that's another one that ideally should be "just click on a checkbox to turn it on and done (unless you really have a burning desire to tweak the advanced settings)." When you need an article this long to explain how to do something that should be drop-dead easy, that's a real design failure. Look at how easy it is to turn on DNS over HTTPS in Firefox - you go to the Network Settings and click one checkbox at the bottom of the Connection Settings pane, and either use the default provider or use a custom one. That's how easy it should be in any decent router software! And I HOPE that is how easy it will be in some future version of OPNsense.

See if this is simple enough for you

https://forum.opnsense.org/index.php?topic=25614.0

and if command line work is to daunting a task for you - you can configure AdGuardHome through WEBGUI

Peace

Tutorials and FAQs / Re: OPNsense 21.7.1 - New Fresh Guaranteed DNS OVER TLS

« on: November 18, 2021, 08:57:35 am »

Quote from: directnupe on November 18, 2021, 08:54:49 am

Quote from: opnfwb on November 01, 2021, 05:36:09 pm
Question regarding this configuration, will this survive OPNsense release upgrades and will the stubby package automatically be upgraded if a newer version is available?

The answer to will this survive OPNsense release upgrades is
YES

The answer to will the stubby package automatically be upgraded if a newer version is available is
NO

However, getdns and stubby on FreeBSD have not been updated / upgraded for a couple of years - why not - I have no idea. Check out my new tutorial OPNsense AdGuardHome TOTAL CONTROL MODE ! ( DOQ )
found here : AdGuardHome is DOH DOT and DOQ supported

https://forum.opnsense.org/index.php?topic=25614.0

Peace

Tutorials and FAQs / Re: OPNsense 21.7.1 - New Fresh Guaranteed DNS OVER TLS

« on: November 18, 2021, 08:56:55 am »

Quote from: cookiemonster on November 03, 2021, 10:31:40 am

opnfwb - spot on.
If someone wants to use DoT, OPN devs have done a wonderful job for simplicity.

What makes this post a little long is there is a very long list of resolvers. If we were to see past that, it is very simple. Credit to the OP for making it look simple.

Thanks cookiemonster for the defense - check out my new work

https://forum.opnsense.org/index.php?topic=25614.0

Tutorials and FAQs / Re: OPNsense 21.7.1 - New Fresh Guaranteed DNS OVER TLS

« on: November 18, 2021, 08:54:49 am »

Quote from: opnfwb on November 01, 2021, 05:36:09 pm

Question regarding this configuration, will this survive OPNsense release upgrades and will the stubby package automatically be upgraded if a newer version is available?

The answer to will this survive OPNsense release upgrades is
YES

The answer to will the stubby package automatically be upgraded if a newer version is available is
NO

However, getdns and stubby on FreeBSD have not been updated / upgraded for a couple of years - why not - I have no idea. Check out my new tutorial OPNsense AdGuardHome TOTAL CONTROL MODE ! ( DOQ )
found here : AdGuardHome is DOH DOT and DOQ supported
Peace

Tutorials and FAQs / OPNsense AdGuardHome TOTAL CONTROL MODE ! ( DOQ )

« on: November 17, 2021, 10:20:26 am »

Go Here For The Intro and ALL ScreenShots :
https://forums.torguard.net/index.php?/topic/2545-opnsense-adguardhome-total-control-mode-doq/

Y'all know how I get down by now. " The Intro " is where it is always at - https://www.youtube.com/watch?v=YiOgPd18UmQ - you just may want to glean the wisdom offered herein - https://genius.com/James-brown-mind-power-lyrics on to the next entry - https://www.youtube.com/watch?v=t7Csc6l4QLs - yes, I go eclectic and electric - https://genius.com/Reo-speedwagon-take-it-on-the-run-lyrics - Surprise Bonus : https://www.youtube.com/watch?v=7pOkpwgOOiI

OK - now that we are rolling - we are going to learn how to install, configure and run OPNsense 21.7 AdGuardHome. See here for basic guide : https://broadbandforum.co/threads/installing-adguard-home-on-pfsense.205884/ - Now this guide is designed for AdGuardHome on pfSense; however, I am going to modify it for OPNsense. I know that there is a plugin for OPNsense 21.7 AdGuardHome, but I prefer this method as it gives me more control over updates / upgrades and configuration. In addition, this aforementioned guide sets up AdGuardHome on the LAN for DNS. I am going to set up AdGuardHome DNS on both the IPV4 and IPV6 local hosts - which are the default interfaces for OPNsense UNBOUND.

AdGuardHome works flawlessly with both OpenVPN and WireGuard protocols.
No need for firewall rules or port forwarding with this set up. It works " as is "
right " OUT THE BOX ".

Step 1: Do Not Change the Port of your OPNsense DNS Resolver
To enable rDNS lookups and hostname lookups for devices on your LAN, enable
" DHCP Registration" and " Static DHCP" in DNS Resolver settings.

Step 2: Install these packages below, so that you can install AdGuardHome.

Code: [Select]

pkg install ca_root_nss
pkg install screen
pkg install nano
pkg install sudo   ## AdGuardHome will not install as service without sudo

Step 3 : Go to this page for auto installation script - the script will download proper package for your architecture.

https://github.com/AdguardTeam/AdGuardHome#test-unstable-versions

Using AGH install script is easier and simpler for most users. Just use their Edge builds
as they are most up to date. It will also warn if there is missing dependencies.

Code: [Select]

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -c edge
ATTENTION : I strongly suggest that you watch this video before you begin. Although lengthy - it is very informative and worthwhile. https://www.youtube.com/watch?v=yMcM40ipDlQ Van Tech Corner OpenWRT AdGuard Home. You also will be able to follow this guide much better - as a ( moving ) picture is worth a thousand words. Follow directions carefully - you will have AdGuard Home up and running on OPNsense by the end of this guide / tutorial.

Step 4 - After installation scripts runs, you should be seeing something like below. Post Install Screenshot
Naturally you may see a different IP Address depending on your network interfaces - but you must use the LAN for initial AdGuardHome Configuration
here it is - http://192.168.5.10:3000

Pick out your LAN interface so that you can perform initial configuration of AdGuardHome . Now, I am going to show you how to use AdGuard Home with UNBOUND. Once again I implore you to look at Van Tech Corner OpenWRT AdGuard Home Video https://www.youtube.com/watch?v=yMcM40ipDlQ
A - Choose LAN Address For Web Interface - Port 8088 / Choose Localhost ( 127.0.0.1 ) For DNS - Change to Port 5353

Step 5 - Now we need to configure UNBOUND for AdGuardHome. We are going to install https://github.com/mimugmail/opn-repo OPNsense repo by mimugmail
so that we may be able to add UNBOUND " Custom Options " to OPNsense 21.7.
Install repository following commands below :

Code: [Select]

# fetch -o /usr/local/etc/pkg/repos/mimugmail.conf https://www.routerperformance.net/mimugmail.conf
# pkg update
# pkg install os-unboundcustom-maxit

After installing plugin os-unboundcustom-maxit, go to Services > Unbound DNS > Custom Options
in the box enter the following found below :

Code: [Select]

server:
do-not-query-localhost: no
forward-zone:
 name: "."    # Allow all DNS queries
 forward-addr: 127.0.0.1@5353
 forward-addr: ::1@5353

Then go to System > Settings > General > DNS Servers and enter the following :
1 - 127.0.0.1
2 - ::1 ### both without any gateway

and

3 - Remove ( Do Not ) Check
" Allow DNS server list to be overridden by DHCP/PPP on WAN " Option

Step 6 - Making AdGuard Home start on boot :
Special thanks to eoghan2t9 for a start up script for AdGuardHome which works flawlessly.
The script is found here : https://github.com/AdguardTeam/AdGuardHome/issues/1352
Some modifications are required for OPNsense 21.7 AdGuardHome. Follow these steps below :

Code: [Select]

A - # mv /usr/local/etc/rc.d/AdGuardHome /usr/local/etc/rc.d/adguardhome.sh
B - # nano /usr/local/etc/rc.d/adguardhome.sh

C - Delete the contents of the file and fill it with these contents below :

Code: [Select]

#!/bin/sh

. /etc/rc.subr

name="adguardhome"
rcvar="adguardhome_enable"
adguardhome_user="root"
adguardhome_command="/opt/AdGuardHome/AdGuardHome"
pidfile="/var/run/${name}.pid"
command="/usr/sbin/daemon"
command_args="-P ${pidfile} -r -f ${adguardhome_command}"

load_rc_config $name
: ${adguardhome_enable:=yes}

run_rc_command "$1"

D- Make it executable - I run this command - it works for me:

Code: [Select]

# chmod 755 /usr/local/etc/rc.d/adguardhome.sh
E - In order to have OPNsense use default start up script ( /usr/local/etc/rc.d/adguardhome.sh )
at boot time you will have to create a boot time start up script for it
in /etc/rc.conf.d/. Not to prolong this - do the following :

Code: [Select]

# touch /etc/rc.conf.d/adguardhome  - create the needed new file
# nano /etc/rc.conf.d/adguardhome   - in the new file enter the following two lines:

adguardhome_enable="YES"
adguardhome_bootup_run="/usr/local/etc/rc.d/adguardhome.sh"

Save and exit / then make the file executable - once again - works for me :

Code: [Select]

# chmod 755 /etc/rc.conf.d/adguardhome
Step 7 - Configure AdGuardHome via AdGuardHome.yaml for UNBOUND
We will edit the sections listed below :
( a ) dns: ( bind_hosts: )
( b ) upstream_dns:
( c ) bootstrap_dns:
( d ) all_servers:
( e ) filters:

# nano /opt/AdGuardHome/AdGuardHome.yaml

Code: [Select]

dns:
  bind_hosts:
  - 127.0.0.1
  - ::1
  port: 5353

We will edit the sections listed below
( a ) upstream_dns: ( b ) bootstrap_dns: ( c ) all_servers:

Code: [Select]

  upstream_dns:
  - quic://dns.adguard.com:784
  - quic://dot-jp.blahdns.com:784
  - quic://dot-fi.blahdns.com:784
  - quic://dot-sg.blahdns.com:784
  - quic://dot-de.blahdns.com:784
  - quic://doh.tiar.app:784
  - quic://dns.emeraldonion.org:8853
  - quic://uk.adhole.org:784
  - quic://de.adhole.org:784
  - quic://sg.adhole.org:784
  - quic://dandelionsprout.asuscomm.com:48582
  - quic://dns.arapurayil.com:784
  - quic://dns.comss.one:784
  - quic://dns.east.comss.one:784
  - tls://getdnsapi.net
  - tls://dns-nyc.aaflalo.me
  - tls://dns.cmrg.net
  - tls://dot.ny.ahadns.net
  - tls://dot.la.ahadns.net
  - tls://dot.chi.ahadns.net
  - tls://ordns.he.net
  - tls://us-east.adhole.org
  - tls://dns.neutopia.org
  - tls://dns.digitale-gesellschaft.ch
  - tls://dot.sb
  - tls://draco.plan9-ns2.com
  upstream_dns_file: ""
  bootstrap_dns:
  - 1.1.1.2:853
  - 1.0.0.2:853
  - 2606:4700:4700::1112:853
  - 2606:4700:4700::1002:853
  all_servers: true

Enter the following below for filters :

Code: [Select]

filters:
- enabled: true
  url: https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt
  name: AdGuard DNS filter
  id: 1
- enabled: true
  url: https://badmojr.github.io/1Hosts/Lite/adblock.txt
  name: 1Hosts (Lite)
  id: 1635566025
- enabled: true
  url: https://raw.githubusercontent.com/durablenapkin/scamblocklist/master/adguard.txt
  name: Scam Blocklist by DurableNapkin
  id: 1625359388
- enabled: true
  url: https://block.energized.pro/basic/formats/hosts.txt
  name: Energized Basic Protection
  id: 1625359389
- enabled: true
  url: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
  name: https://github.com/StevenBlack/hosts
  id: 1625359390
- enabled: true
  url: https://osint.digitalside.it/Threat-Intel/lists/latestdomains.txt
  name: https://firebog.net/  - OSINT.digitalside.it
  id: 1625359391
- enabled: true
  url: https://v.firebog.net/hosts/Easyprivacy.txt
  name: https://firebog.net/  - EasyPrivacy
  id: 1625359393
whitelist_filters:
- enabled: true
  url: https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt
  name: https://github.com/anudeepND/whitelist
  id: 1625359392
user_rules: []

After configuring AdGuardHome via AdGuardHome.yaml both of the commands below :

Code: [Select]

a - # /usr/local/etc/rc.d/adguardhome.sh restart
b - # /usr/local/etc/rc.d/unbound onestart

Step 8 - I strongly recommend enabled Encryption. With Encryption AdGuard Home admin interface will work over HTTPS, and the DNS server will listen for requests over DNS-over-HTTPS and DNS-over-TLS. For Encryption = Go To Top of AdGuardHome WEB GUI - Settings > Encryption settings the follow instructions
( a ) - enable Encryption - check the Box
( b ) - Fill in full server name such as this example - freedom.babybaby.mywire.org : https://www.wolffhaven45.com/2017/11/07/intranet-ssl-certificate-for-pfsense-using-lets-encrypt--cloudflare/ - I recommend Dynu ACME LET’S ENCRYPT

( c ) Certificates :
In order to use encryption, you need to provide a valid SSL certificates chain for your domain.
You can get a free certificate on LetsEncrypt.org or you can buy it from one of the trusted Certificate Authorities.
If you follow the tutorial above you can issue yourself a LetsEncrypt Certificate cost free. This is fictional domain.
See here for how to get Dynu Account and Credentials : https://forum.openwrt.org/t/dynu-openwrt-acme-lets-encrypt/110758

Your certificate and key would be in the following format below :

Code: [Select]

/var/etc/acme-client/home//freedom.babybaby.mywire.org/fullchain.cer
/var/etc/acme-client/home/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key

In order to log into Encrypted AdGuardHome WEB GUI
you must move OPNsense WEBGUI to a different port than 443 -
You may now log into Encrypted AdGuardHome WEB GUI -
this option is available by entering the following ( from example above ) :

Code: [Select]

https://freedom.babybaby.mywire.org:443 - with Encryption Enabled
you will see " green padlock " when logging in / your certificate pulls double duty.

say moved FireWall Admin to Port 1443 - you may still log into your OPNsense Encrypted WEBGUI at :

Code: [Select]

https://freedom.babybaby.mywire.org:1443
PS - I started this journey in order to learn how to use DNS-over-QUIC, or DoQ.
In full disclosure I exclusively use DNS-over-QUIC upstream servers with AdGuardHome.
Also, I used Encryption for DNS OVER TLS bootstrap servers.
So - the whole damn thing ( my DNS ) is encrypted.
BTW, I certainly will not at all miss having to update the SPKI PIN Keys
for DOT SERVERS in the Stubby yaml configuration file.

Bonus Feature:
For Those Who Care To PIMP Their AdGuardHome WEBGUI
You must install Stylish Addon To Use AdGuardHome Dark Theme
Firefox addon : https://addons.mozilla.org/en-US/firefox/addon/stylish/
Chrome extension : https://tinyurl.com/yntw4wyw

Go here - For Stylish Dark Themes :
https://userstyles.org/styles/browse?search_terms=adguard&type=false

I use XENORCHISM -

https://userstyles.org/styles/178841/adguard-home-dark-theme

You must enter your LAN IP ADDRESS IN " Customize Settings " Box prior to installation
If you enabled Encryption with a valid SSL certificates chain for your domain - then enter
your Full Domain Name in " Customize Settings " Box prior to installation instead of LAN IP.

Code: [Select]

As per this example, Full Domain Name in 
" Customize Settings " Box  see below :

freedom.babybaby.mywire.org

You may then access AdGuardHome WEBGIU on port 443 - here is example from above :

Code: [Select]

https://freedom.babybaby.mywire.org:443 - with Encryption Enabled
you will see " green padlock " when logging in / your certificate pulls double duty

See AdGuardHome Dark Screenshot

When a new AdGuardHome version becomes available on The Edge Channel it will show up
in the WEBGUI. All you need to do in order to stay up to date is press the " update to the latest version "
button on the AdGuardHome WEBGUI page. Easy Peasy.

Tutorials and FAQs / Re: OPNsense 21.7.1 - New Fresh Guaranteed DNS OVER TLS

« on: October 16, 2021, 06:24:07 am »

Dear cookiemonster,
Hello and I hope that you are both safe and well. Thank you for your kind words, and I appreciate you telling me about mimugmail / opn-repo and I have added that option to this tutorial. Re:
If you want, I can help you troubleshoot separately the issue you encountered. - well, since everyone should be able to get this working by now - I really do not want to put you out. However, I would like to find out why the SSH commands -

B - # touch /usr/local/etc/unbound.opnsense.d/unbound_srv.conf
C - # nano /usr/local/etc/unbound.opnsense.d/unbound_srv.conf

seem to not work - at least at the time I attempted this

Do you think it has do with file permissions or some issue issue - yes I would like to know - just for future reference.Thanks again for your feedback and kindness

Peace -

directnupe

Tutorials and FAQs / OPNsense 21.7.1 - New Fresh Guaranteed DNS OVER TLS

« on: October 13, 2021, 06:42:51 pm »

Dear Community,
First you all know the drill by now - " The Intro " - two throwbacks - https://www.youtube.com/watch?v=m5FCcDEA6mY - lyrics - https://genius.com/Neil-young-southern-man-lyrics - and don't you know - https://www.youtube.com/watch?v=wkA7ok5MySk - https://genius.com/Funkadelic-if-you-dont-like-the-effects-dont-produce-the-cause-lyrics - OK - now that our long standing tradition of public elucidation has been fulfilled - let's get down to the business at hand.

Since version OPNsense 18.7 - you may install stubby and getdns on OPNsense by simply issuing command # pkg install getdns ( Special Thanks and Kudos to Franco and the marvelous OPNsense Development Team ) - Please disregard and do not use any guides and / or tutorials which predate this one which covers installation and configuration of DNS Privacy on OPNsense FireWall. This is an updated guide / tutorial which explains how to setup adding DNS-Over-TLS support for OPNsense. However, there has been a minor change ( yet little known ) in UNBOUND on OPNsense 21.7.1 with regard to configure it to work with Stubby for DNS Privacy DNS OVER TLS. So, let's get started strait away. See here for previous more in depth guide concerning the benefits of DNS Privacy : https://bit.ly/3j0QT1l

So here we go. So go ahead and issue command :

A - # pkg install getdns

in order to get started. After installing getdns which includes stubby follow the steps below.

1 - Now to put all of this together, The stubby.in file is located here - /usr/local/etc/rc.d/stubby by default.
First though Stubby needs Unbound root.key - run this command before getting started:

A - # su -m unbound -c /usr/local/sbin/unbound-anchor Then -
B - Issue this command : # mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh
Make it executable - I run this command - it works for me:
C - # chmod 755 /usr/local/etc/rc.d/stubby.sh
D - Yes must enable Stubby Daemon in the file - open file by :
E - # nano /usr/local/etc/rc.d/stubby.sh
go to line 27 - : ${stubby_enable="NO"} change the setting to : ${stubby_enable="YES"} -
that is all you have to do to this file. It comes already configured. Save and exit.

2 - Now you must configure Stubby to resolve DNS OVER TLS - enter command below :

A -# nano /usr/local/etc/stubby/stubby.yml - make your file match some thing similar to this

################################################################################
######################## STUBBY YAML CONFIG FILE ###############################
################################################################################
# This is a yaml version of the stubby configuration file (it replaces the
# json based stubby.conf file used in earlier versions of getdns/stubby).
#
# For more information see
# https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby
#

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
idle_timeout: 9000
listen_addresses:
- 127.0.0.1@8053
- 0::1@8053
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
round_robin_upstreams: 1
tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt"
dnssec_trust_anchors: "/usr/local/etc/unbound/root.key" # add the right path

upstream_recursive_servers:
### IPV4 Servers ###
### DNS Privacy DOT Test Servers ###
## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD )
- address_data: 185.49.141.37
- address_data: 2a04:b900:0:100::38
tls_auth_name: "getdnsapi.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
## 2 - The Surfnet/Sinodun DNS TLS Servers #3 A+ ( NLD )
- address_data: 145.100.185.18
- address_data: 2001:610:1:40ba:145:100:185:18
tls_port: 853
tls_auth_name: "dnsovertls3.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
## xx - The The Surfnet/Sinodun DNS TLS Server A ( NLD )
- address_data: 145.100.185.15
- address_data: 2001:610:1:40ba:145:100:185:15
tls_auth_name: "dnsovertls.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
## xx - The The Surfnet/Sinodun DNS TLS Server #1 A ( NLD )
- address_data: 145.100.185.16
- address_data: 2001:610:1:40ba:145:100:185:16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
## 3 - The dns.cmrg.net DNS TLS Server A+ ( CAN )
- address_data: 199.58.81.218
- address_data: 2001:470:1c:76d::53
tls_auth_name: "dns.cmrg.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
## 4 - The BlahDNS Japan DNS TLS Server A+ ( JPN )
- address_data: 139.162.112.47
- address_data: 2400:8902::f03c:92ff:fe27:344b
tls_auth_name: "dot-jp.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: /llFOsnvj7GcXasKrojhZl6nRnnn4D8sRuDUKEdiZzM=
## xx - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU )
- address_data: 78.46.244.143
- address_data: 2a01:4f8:c17:ec67::1
tls_auth_name: "dot-de.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: c6xmf1GsYo1IFyxc+CWfjYo+xpSV9i98H7InJTDylsU=
## xx - The BlahDNS Finland DNS TLS Server A+ ( FIN )
- address_data: 95.216.212.177
- address_data: 2a01:4f9:c010:43ce::1
tls_auth_name: "dot-fi.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: EVL610kmcSvN01nzJkkzl94IHiIVvW0PovbB5En2QfU=
## xx - The BlahDNS Singapore DNS TLS Server A+ ( SGP )
- address_data: 192.53.175.149
- address_data: 2400:8901::f03c:92ff:fe27:870a
tls_auth_name: "dot-sg.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: B+aX4NBLfDsKlOWf8RM6rjL8yOCF9sZlHQnarDNrrWM=
## xx - The BlahDNS Switzerland DNS TLS Server A+ ( CHE )
- address_data: 45.91.92.121
- address_data: 2a05:9406::175
tls_auth_name: "dot-ch.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: cxti1XR6uW483xAioP3d1ZaoGSy+obY6WaE4fW1A6Nk=
## 5 - The dns.neutopia.org DNS TLS Server A+ ( FRA )
- address_data: 89.234.186.112
tls_auth_name: "dns.neutopia.org"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
## 6 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT )
- address_data: 146.255.56.98
- address_data: 2a02:1b8:10:234::2
tls_auth_name: "dot1.applied-privacy.net"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: xhQVPE+X85b9LkORuEhxfsxE1X2EbOm8v5ytxCqg5BI=
## 7 - The Secure DNS Project by PumpleX DNS TLS Server #1 A+ ( GBR )
- address_data: 51.38.83.141
tls_auth_name: "dns.oszx.co"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Am37BK5eBKSafYNJupWsoh5pokR3wwJ5zs7xvniF6XE=
## 8 - The dismail.de DNS TLS Server #1 A+ ( DEU )
- address_data: 80.241.218.68
tls_port: 853
tls_auth_name: "fdns1.dismail.de"
tls_pubkey_pinset:
- digest: "sha256"
value: MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU=
## xx - The dismail.de DNS TLS Server #2 A+ ( USA )
- address_data: 159.69.114.157
tls_port: 853
tls_auth_name: "fdns2.dismail.de"
tls_pubkey_pinset:
- digest: "sha256"
value: yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w=
## 9 - The Lorraine Data Network DNS TLS Server A+ ( FRA )
- address_data: 80.67.188.188
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=
## This certificate is currently expired which
## does not pose any concerns in SPKI mode
## (in practice with Stubby)
## Source : https://ldn-fai.net/serveur-dns-recursif-ouvert/
## 10 - The ibksturm.synology.me DNS TLS Server A+ ( CHE )
- address_data: 213.196.191.96
tls_auth_name: "ibksturm.synology.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: yrMslOFXpWeLoNw0YgQk/pA5vl2mqXfBOASYLLeqDxc=
## 11 - The dns.flatuslifir.is DNS TLS Server A+ ( ISL )
- address_data: 46.239.223.80
tls_auth_name: "dns.flatuslifir.is"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: b9sJFKc+wycfm4FHB9ddNopdeKceru+sZk0w5nz4xfQ=
### Publicly Available DOT Test Servers ###
## 12 - The FEROZ SALAM DNS TLS Server A+ ( GBR )
- address_data: 46.101.66.244
tls_auth_name: "doh.li"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: ugm6mY2NNKi0I/Q+pofAgx0c31tbcW6xYAImZXr5Oqo=
## 13 - The Andrews & Arnold DNS TLS Server #1 A+ ( GBR )
- address_data: 217.169.20.23
tls_auth_name: "dns.aa.net.uk"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: sS2Atff8wMigRVTxmS36FbMaXiCWsxLgD3AOtTA9eeU=
## xx - The Andrews & Arnold DNS TLS Server #2 A+ ( GBR )
- address_data: 217.169.20.22
tls_auth_name: "dns.aa.net.uk"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /jchI7afFvSaVm4DCTksJcPHyK7uvbcwNUtTNNV4Bek=
## 14 - The dns.seby.io - Vultr DNS TLS Server A+ ( AUS )
- address_data: 45.76.113.31
tls_auth_name: "dot.seby.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM=
## xx - The dns.seby.io - OVH DNS TLS Server A+ ( AUS )
- address_data: 139.99.222.72
tls_auth_name: "dot.seby.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /3AxvvuWCQmYQ4/mqHJzPL1rPC7KxaahVPmUkoSVR5A=
## 15 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE )
- address_data: 185.95.218.43
- address_data: 2a05:fc84::43
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: sAH7JR5A8WA+hs1ZGXPS/uq3Y1wufBi2wQ8Crk+oR2Q=
## xx - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE )
- address_data: 185.95.218.42
- address_data: 2a05:fc84::42
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Fpgt86sGjlL4sbgNmd1WX0BYEIEJ7yQk9rp+uQKxI+w=
## 16 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA )
- address_data: 168.235.81.167
tls_auth_name: "dns-nyc.aaflalo.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Dn58VD18MLkmmG9wvzvSs30Tu1Rd65igDLpp1odYaAc=

# Set the acceptable ciphers for DNS over TLS. With OpenSSL 1.1.1 this list is
# for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the
#tls_ciphersuites option. This option can also be given per upstream.
tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"
# Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required
# for this option. This option can also be given per upstream.
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
# Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_min_version: GETDNS_TLS1_2
# Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_max_version: GETDNS_TLS1_3

When I get some time - next day or two - I will post a separate Forum entry which lists
many more DNS OVER TLS servers that are publicly available for. However, these are more than
enough to get you started.

3 - In order to have OPNsense 21.7.1 use default start up script ( /usr/local/etc/rc.d/stubby.sh )
at boot time it helps to create a boot time start up script for it in /etc/rc.conf.d/.
Not to prolong this - do the following :

# touch /etc/rc.conf.d/stubby - create the needed new file
# nano /etc/rc.conf.d/stubby - in the new file enter the following two lines:

stubby_enable="YES"
stubby_bootup_run="/usr/local/etc/rc.d/stubby.sh"

Save and exit / then make the file executable - once again - works for me :

# chmod 755 /etc/rc.conf.d/stubby

4 - Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS.
This is where there has been a ( major ) change to UNBOUND on OPNsense 21.7.1 .
The bottom line is that there is no longer any option whatsoever for you
to configure UNBOUND Custom Options via OPNsense 21.7.1 WEBGUI.

A - See here for the changes - https://bit.ly/3vfx1MT - then scroll down to Advanced Configurations.
There you may read about the changes I alluded to earlier.

So here is how we go about configuring Unbound/Stubby combination for OPNsense 21.7.1

Some user combine Unbound (as a caching proxy with other features such as DNS Blacklisting)
and Stubby (as fully featured TLS forwarder). This is what we are out to achieve.

Advanced Configurations
Some installations require configuration settings that are not accessible in the UI. To support these,
individual configuration files with a .conf extension can be put into the
/usr/local/etc/unbound.opnsense.d directory.

Now theoretically - you should be able to create the need file by doing the following below :

B - # touch /usr/local/etc/unbound.opnsense.d/unbound_srv.conf
C - # nano /usr/local/etc/unbound.opnsense.d/unbound_srv.conf

enter the following in the new file as detailed below :

####################################################

### Unbound Advanced Configuration
server:
tls-cert-bundle: "/usr/local/share/certs/ca-root-nss.crt"
hide-trustanchor: yes
harden-glue: yes
harden-dnssec-stripped: yes
num-threads: 4
rrset-cache-size: 256m
msg-cache-size: 128m
so-rcvbuf: 1m
val-clean-additional: yes
minimal-responses: yes
harden-referral-path: yes
aggressive-nsec: yes
prefetch: yes
qname-minimisation: yes
qname-minimisation-strict: yes
rrset-roundrobin: yes
target-fetch-policy: "0 0 0 0 0"
max-udp-size: 3072
harden-below-nxdomain: yes
ip-ratelimit: 300
ip-ratelimit-factor: 10
incoming-num-tcp: 100
edns-buffer-size: 1472

do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8053
forward-addr: 0::1@8053

##################################################

*** Note that the file you create must end in .conf in order to be automatically
included by the UI generated configuration. Also, Name collisions with plugin code,
which use this extension point e. g. dnsbl.conf, may occur. So be sure to use a unique filename.

unbound_srv.conf is a unique filename on OPNsense 21.7.1 for sure - trust me.

5 - Now, I have one caveat - when I created this file ( as described above ) via SSH - there was
an issue where DNS OVER TLS did not work at all or as it should - the resolvers did not connect.
Perhaps the file needs permissions - you can try -

chmod 664 /usr/local/etc/unbound.opnsense.d/unbound_srv.conf

and see how this works out for you

GUARANTEED SOLUTION:

What I did was use WINSCP in order to have this setup perform as intended. Use your
favorite text editor ( I use EditPad Pro ) and copy Unbound Advanced Configuration above -
into a new file labeled - unbound_srv.conf - Save this file to a local directory on your
computer. Next, follow the steps below :

A - WINSCP into your OPNsense 21.7.1 Firewall via SFTP protocol - SCP will not
connect on OPNsense. Make sure to use SFTP protocol.
Go into ( open ) the directory below on the right side of WINSCP interface :

/usr/local/etc/unbound.opnsense.d/

B - Go into the directory on your computer where you have the unbound_srv.conf file
which you previously created and filled out with the Unbound Advanced Configuration.
This will be on the left side of WINSCP.

C - Drag and Drop unbound_srv.conf ( on the left side of WINSCP ) into the
/usr/local/etc/unbound.opnsense.d/unbound_srv.conf ( directory which is open )
on the right side of of WINSCP. Done - close and exit

This WINSCP method is GUARANTED to work !!! - I strongly suggest that you choose to
make this your preferred Unbound Advanced Configuration option for OPNsense 21.7.1 !!!

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Easiest Method To Bring Back Unbound Advanced Configuration
For OPNsense 21.7.1 WEBGUI Special Thanks to
cookiemonster from the OPNsense forum.

You can add the mimugmail / opn-repo to your OPNsense 21.7.1 Firewall
found here ( https://tinyurl.com/4r4xdrtp ) see details below :

A - # fetch -o /usr/local/etc/pkg/repos/mimugmail.conf https://www.routerperformance.net/mimugmail.conf
B - # pkg update
Then either add plugin os-unboundcustom-maxit from WEBGUI

C - or issue command # pkg install os-unboundcustom-maxit

Then go to Services > Unbound DNS > Custom Options - you may enter your
Unbound Advanced Configuration entries here - enable Custom Options -
then restart Unbound DNS and then issue command

F - # /usr/local/etc/rc.d/stubby.sh restart

FYI - os-unboundcustom-maxit plugin while adding Custom Options to WEBGUI - creates
a file named custom-maxit.conf in the /usr/local/etc/unbound.opnsense.d/ directory

ALTERNATE METHOD TO INSTALL mimugmail /opn-repo

Sometimes you may get an error with fetch command ( SSL ) when trying to add
mimugmail /opn-repo . This is a workaround to add mimugmail /opn-repo manually.

touch /usr/local/etc/pkg/repos/mimugmail.conf
nano /usr/local/etc/pkg/repos/mimugmail.conf

Then enter the contents contained between the lines below :

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

mimugmail: {
url: "https://opn-repo.routerperformance.net/repo/${ABI}",
priority: 190,
enabled: yes
}

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Next after manually adding mimugmail /opn-repo to OPNsense 21.7.1
continue as normal :

# pkg update
# pkg install os-unboundcustom-maxit

You are then all set

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

6 - Next -Under System > Settings > General Settings

A - Set the first DNS Server to 127.0.0.1 with no gateway selected /

Make sure that DNS server option

B - Allow DNS server list to be overridden by DHCP/PPP on WAN - Is Not I repeat - Is Not Checked !

and DNS server option

C - Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Not - I repeat - Is Not Checked !

D - Save and Apply

Reboot your router or run command # /usr/local/etc/rc.d/stubby.sh restart

You are all set up and now. You are now running DNS OVER TLS with GETDNS plus STUBBY
( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server.

Tutorials and FAQs / Re: HOW TO OpenVPN OPNsense CLIENT DEAD SIMPLE

« on: September 03, 2020, 05:16:47 am »

Dear bpalob,
You said -
" I also tried with the 4 FW rules described in the other guide, but I do not see these 4 auto generated rules... "

The correct Answer :
You need to create all of these manually. One by one - create first rule then clone it - and do this for each following rule.

Tutorials and FAQs / Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY

« on: May 20, 2020, 11:04:29 pm »

Quote from: Easylarveur on May 20, 2020, 09:47:05 pm

Thank you for this big update on how to install unbound + stubby on opnsense.

I am a satisfied user of these 2 softwares for about a year now.
I have got a few questions for you. I hope you will have the time to answer a few of them.

1) I have seen that you have enable the DNSSEC extension in Stubby.
We can see it in the stubby.yml files:
Quote
dnssec_return_status: GETDNS_EXTENSION_TRUE

If you have already activated the DNSSEC validation in unbound, don't you think that it is useless to activate it in stubby?
I have enabled DNSSEC only in unbound and everything is fine.
Unbound is making all the stuff about the dns queries. I am using stubby only to send the dns queries from unbound with DoT or DoH to several servers.

2) I will try your new settings with the main LAN Address instead of the localhost address. What is exactly the pro of this new settings ?

3)With the new plugin unbound-plus we will soon not have access anymore to the "custom options" in unbound GUI.
Where can we then specify the following to transfer the dns queries from unbound to stubby?
Quote
server:
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 192.168.7.11@8053 ## ( Your One Main LAN Address )
## END OF ENTRY

Thanks again for all the help provided on the install of stubby on opnsense.

Dear Easylarveur,
Hello and I hope that you are safe and doing well in these days. As far as Stubby ( it is called a stub resolver ) so it is actually doing the DNS look ups and forwarding them to UNBOUND. I am not a pure expert or sure of this - however; this is the suggested setup from DNSPRIVACY. See here below :
https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby#ConfiguringStubby-DNSSEC

DNSSEC
To enable DNSSEC validation when using Stubby add the following option to the configuration file
dnssec_return_status: GETDNS_EXTENSION_TRUE

As to the advantages of this setup - this from the top of the page for this tutorial

Stop OPNsense Router from occasionally allowing UNBOUND Root Hints to resolve queries on its own. This configuration ensures that localhost ( 127.0.0.1 ) will not be used as a resolver on OPNsense Box. You will only use GETDNS and STUBBY DNS SERVERS if you follow this tutorial. You will use your One Main LAN Interface as the listening interface for STUBBY and the listening and outgoing interface for your UNBOUND DNS RESOLVER on OPNsense. So, let's get started.

See Below For Definition and Function Of Unbound Root Hints :
Unbound is a caching DNS resolver. It uses a built in list of authoritative
nameservers for the root zone (.), the so called root hints. On receiving a
DNS query it will ask the root nameservers for an answer and will in almost
all cases receive a delegation to a top level domain (TLD) authoritative nameserver.
Source Document : https://man.openbsd.org/unbound

My reference :
https://forum.netgate.com/topic/130832/solution-posted-dns-tls-getdns-stubby-from-pfsense-freebsd-ports/13
Read Actionhenk' Comment in the thread - second to the last - this is why I set this up this way. However, you can always use the standard installation found here :
https://forum.opnsense.org/index.php?PHPSESSID=k6ivse7g94849ga6nk9r8kg9g5&topic=13487.0

It is up to you - hope this helps

Tutorials and FAQs / Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY

« 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.

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

Tutorials and FAQs / FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY

« on: February 16, 2020, 07:37:27 am »

LAN Interface For GETDNS and STUBBY Plus UNBOUND
WHY YOU ASK ? ANSWER : IN LIFE ONE SHOULD HAVE OPTIONS

IMPORTANT UPDATED INFORMATION !!! - READ FULL GUIDE BEFORE GETTING STARTED !!!

Stop OPNsense Router from occasionally allowing UNBOUND Root Hints to resolve queries on its own. This configuration ensures that localhost ( 127.0.0.1 ) will not be used as a resolver on OPNsense Box. You will only use GETDNS and STUBBY DNS SERVERS if you follow this tutorial. You will use your One Main LAN Interface as the listening interface for STUBBY and the listening and outgoing interface for your UNBOUND DNS RESOLVER on OPNsense. So, let's get started.

See Below For Definition and Function Of Unbound Root Hints :
Unbound is a caching DNS resolver. It uses a built in list of authoritative
nameservers for the root zone (.), the so called root hints. On receiving a
DNS query it will ask the root nameservers for an answer and will in almost
all cases receive a delegation to a top level domain (TLD) authoritative nameserver.
Source Document : https://man.openbsd.org/unbound

First you all know the drill by now - " The Intro " we would all have a better world if we remember to practice the concept that - NOW ! is the time for all of US ( A ) to GET UP & GET INVLOVED and act with SOUL POWER ! - lyrics to sing along : https://genius.com/James-brown-get-up-get-into-it-get-involved-lyrics plus https://genius.com/James-brown-soul-power-lyrics and video : https://www.youtube.com/watch?v=1pvIarW3xHg Bonus JB : https://www.youtube.com/watch?v=v8TvBPshngE - Since version OPNsense 18.7 - you may install stubby and getdns on OPNsense by simply issuing command # pkg install getdns ( Special Thanks and Kudos to Franco and the marvelous OPNsense Development Team ) - Please disregard and do not use any guides and / or tutorials which pre-date this one which covers installation and configuration of DNS Privacy on OPNsense FireWall. This is an updated guide / tutorial which explains how to setup adding DNS-Over-TLS support for OPNsense. I run GetDns and Stubby forwarded to and integrated with Unbound. For those who wish to explore Stubby and GetDns - this method is the one recommended by DNSPRIVACY - see here :

https://getdnsapi.net/
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients#DNSPrivacyClients-Unbound - please read this carefully - you will note that it indicates : Unbound As A DNS TLS Client Features:Unbound can be run as a local caching forwarder, configured to use SSL upstream, however it cannot yet authenticate upstreams, re-use TCP/TLS connections, be configured for Opportunistic mode or send several of the privacy related options (padding, ECS privacy) etc. Some users combine Unbound (as a caching proxy with other features such as DNS Blacklisting) and Stubby (as a fully featured TLS forwarder).

I was asked by a still skeptical devotee of DOH
" What makes this way better than just running the DNS-over-https-proxy ?
My answer was : Read this and make your
decisions and conclusions concerning DOH vs DOT .
Here is the article below :
https://www.netmeister.org/blog/doh-dot-dnssec.html

Bottom Line Conclusion From Jan Schaumann - The Author of This Blog Entry :
For that, my current preference is quite clearly DNS-over-TLS:
I fear a bifurcation of DNS resolution by apps combined with the
push for using public resolvers with DoH will lead to a more complex
environment and threat model for many users.

Short Synopsis of DOH:
In other words , ( with DOH ) we gain the same
protections as with DoT for our web applications,
but leaves all other DNS traffic vulnerable.

Subsequently, as a matter of fact and in practice
with DNS OVER TLS ALL DNS traffic is invulnerable
and protected.This is why I run DOT and
eschew DOH on my OPNsense Router.

Further, Personally, I run GETDNS STUBBY and UNBOUND as
described here along with ( wait for it )
FireFox DOH along with Encrypted SNI - plus TLS v 1.3 in Stubby
and naturally a properly configured and encrypted VPN -

Your OPNsense /etc/resolv.conf file before and after configuring
LAN Interface For GETDNS and STUBBY Plus UNBOUND as described in
this tutorial.

Your OPNsense Firewall
# domain secureone.duckdns.org # Domain Used In My
# OpenWRT DuckDNS LET’S ENCRYPT CERTIFICATES MADE SIMPLE Tutorial

Before Below :
# cat /etc/resolv.conf
domain secureone.duckdns.org
nameserver 127.0.0.1
nameserver 127.0.0.1

After Below :
~ # cat /etc/resolv.conf
domain secureone.duckdns.org
nameserver 192.168.7.11

These are the reasons I choose to use GetDns and Stubby with Unbound. Those reasons being so that I can take full advantage of all of the most secure privacy features available when running DNS OVER TLS. What I give you here is the absolute best method of implementation and deployment of DNS OVER TLS. For any and all who may be wondering why DNS OVER TLS is all the rage - read this:
https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt I always set up DNS OVER TLS first before configuring OpenVPN and / or WireGuard on OPNsense - this DNS solution works flawlessly with either VPN protocol. So here we go. So go ahead and issue command # pkg install getdns in order to get started. After installing getdns which includes stubby follow the steps below.

1 - Now Ryan Steinmetz aka zi - the port maintainer and developer of this port was kind enough to include a start up script ( stubby.in ) for this package. See the stubby.in here in the raw : https://svnweb.freebsd.org/ports/head/dns/getdns/files/stubby.in?view=markup. All I had to do was ask him and he did for any and all who elect to use this great piece of FreeBSD software.

2 - Now to put all of this together, The stubby.in file is located here - /usr/local/etc/rc.d/stubby by default. First though Stubby needs Unbound root.key - run this command before getting started:
# su -m unbound -c /usr/local/sbin/unbound-anchor Then -
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
B - Yes must enable Stubby Daemon in the file - open file by : nano /usr/local/etc/rc.d/stubby.sh
go to line 27 - : ${stubby_enable="NO"} change the setting to : ${stubby_enable="YES"} - that is all you have to do to this file. It comes pre-configured. Save and exit.

3 - You can and should also check real time status of DNS Privacy Servers as they are experimental and are not always stable - you can monitor DNS TLS Servers Real Time Status here below:
https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/
I have read here: https://www.monperrus.net/martin/randomization-encryption-dns-requests that Also, it is good to set up some servers that listens on port 443 and others on port 853, so as to be resilient if you are on a network with blocked ports. You can also blend IPv4 and IPv6 addresses.

Now you must configure Stubby to resolve DNS OVER TLS - nano /usr/local/etc/stubby/stubby.yml
VERY IMPORTANT UPDATE: After checking, rechecking and the triple checking on this website mentioned above : https://www.immuniweb.com/ssl/?id=Su8SeUQ4 I have made some very serious discoveries regarding which DNS Privacy Test Servers to use. The bottom line that I strongly suggest you only choose to deploy servers which support the TLSv1.3 protocol. See here for information and importance of TLSv1.3 : https://kinsta.com/blog/tls-1-3/
I will save you some considerable leg work and post below the best configuration for your stubby.yml file. Here it is:
## All DNS Privacy Servers Below Tested and Updated On November 3 2020 With A+ Rating - 100% Perfecto Configuration on website: https://www.immuniweb.com/ssl/?id=Su8SeUQ4n ** These servers support the most recent and secure TLS protocol version of TLS 1.3 **
Good configuration - These server configurations support only TLSv1.2 and TLSv1.3 protocols - current most secure encryption.
# Also I have added the Country Locations of These DNS PRIVACY Servers using the Alpha 3 Code Format
# see country code lists here :
# https://www.nationsonline.org/oneworld/country_code_list.htm or https://www.iban.com/country-codes
# Use as many or as few depending on your specific needs

## Go Into SSH shell and enter : # nano /usr/local/etc/stubby/stubby.yml

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
idle_timeout: 9000
listen_addresses:
- 127.0.0.1@8053
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
round_robin_upstreams: 1
tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt"

upstream_recursive_servers:
### IPV4 Servers ###
### DNS Privacy DOT Test Servers ###
## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD )
- address_data: 185.49.141.37
tls_auth_name: "getdnsapi.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
## 2 - The Surfnet/Sinodun DNS TLS Server #3 A+ ( NLD )
- address_data: 145.100.185.18
tls_port: 853
tls_auth_name: "dnsovertls3.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
## 3 - The The Surfnet/Sinodun DNS TLS Server A ( NLD )
- address_data: 145.100.185.15
tls_auth_name: "dnsovertls.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
## 4 - The The Surfnet/Sinodun DNS TLS Server #1 A ( NLD )
- address_data: 145.100.185.16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
## 5 - The dns.cmrg.net DNS TLS Server A+ ( CAN )
- address_data: 199.58.81.218
tls_auth_name: "dns.cmrg.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
## 6 - The BlahDNS Japan DNS TLS Server A+ ( JPN )
- address_data: 45.32.55.94
tls_auth_name: "dot-jp.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: gIoiNFxX1Nw+7/pVsmUKBU941bMBYjEYuB2T9drULOM=
## 7 - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU )
- address_data: 159.69.198.101
tls_auth_name: "dot-de.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: YZeyeJf/suAR2fMHLc9RDPkcQi/e8EEnzk5Y1N90QQE=
## 8 - The BlahDNS Finland DNS TLS Server A+ ( FIN )
- address_data: 95.216.212.177
tls_auth_name: "dot-fi.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: PID8ufrN/lfloA6y/C+mpR8MT53GG6GkAd8k+RmgTwc=
## 9 - The BlahDNS Singapore DNS TLS Server A+ ( SGP )
- address_data: 139.180.141.57
tls_auth_name: "dot-sg.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: iENlCR6FD7l71PESwzzBUGVgJ5MtJykG2F1fV1RyV4A=
## 10 - The dns.neutopia.org DNS TLS Server A+ ( FRA )
- address_data: 89.234.186.112
tls_auth_name: "dns.neutopia.org"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
## 11 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT )
- address_data: 146.255.56.98
tls_auth_name: "dot1.applied-privacy.net"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: iPoeezj2bJ8n0ZgK7HWPy5g0E7nNB8ugiXGZOHslVMs=
## 12 - The Secure DNS Project by PumpleX DNS TLS Server #1 A+ ( GBR )
- address_data: 51.38.83.141
tls_auth_name: "dns.oszx.co"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: uWtC2lljtQnMVcmKS8mt7sWHuS5mFJ9TWdBDv4ti830=
# 13 - The dismail.de DNS TLS Server #1 A+ ( DEU )
- address_data: 80.241.218.68
tls_port: 853
tls_auth_name: "fdns1.dismail.de"
tls_pubkey_pinset:
- digest: "sha256"
value: MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU=
## 14 - The dismail.de DNS TLS Server #2 A+ ( USA )
- address_data: 159.69.114.157
tls_port: 853
tls_auth_name: "fdns2.dismail.de"
tls_pubkey_pinset:
- digest: "sha256"
value: yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w=
## 15 - The Lorraine Data Network DNS TLS Server A+ ( FRA )
- address_data: 80.67.188.188
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=
## This certificate is currently expired which
## does not pose any concerns in SPKI mode
## (in practice with Stubby)
## Source : https://ldn-fai.net/serveur-dns-recursif-ouvert/
# 16 - The ibksturm.synology.me DNS TLS Server A+ ( CHE )
- address_data: 85.5.93.230
tls_auth_name: "ibksturm.synology.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: npNOnBcLbvZWZgdmcuFaEqYJbaGjBlHMf9DknDoIkgg=
## 17 - The dns.flatuslifir.is DNS TLS Server A+ ( ISL )
- address_data: 46.239.223.80
tls_auth_name: "dns.flatuslifir.is"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: YdmlL2GSokMgH/t506AaHtdfhoW+WAPVwv4dAWGXYMs=
### Publicly Available DOT Test Servers ###
## 18 - The ContainerPI.com - CPI DNS TLS Server A+ ( JPN )
- address_data: 45.77.180.10
tls_auth_name: "dns.containerpi.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 0fDCu9NeTLXKniGX7Hqjq4PLqXV7kvxv04lAWs/dOHY=
## 19 - The FEROZ SALAM DNS TLS Server A+ ( GBR )
- address_data: 46.101.66.244
tls_auth_name: "doh.li"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: E3//wtQoI+p2eDg0+zEejPX3kHowMAUiLwGG6sGckFo=
## 20 - The Andrews & Arnold DNS TLS Server #1 A+ ( GBR )
- address_data: 217.169.20.23
tls_auth_name: "dns.aa.net.uk"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: N1HkO1CiKQiPYEoFjMMU/mgZc7PMPaVE016y5w8+hUg=
## 21 - The Andrews & Arnold DNS TLS Server #2 A+ ( GBR )
- address_data: 217.169.20.22
tls_auth_name: "dns.aa.net.uk"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Rq21Y/YgMvw00ZzFGsiJKTEz0u9BBecPl0ns9oploKE=
## 22 - The dns.seby.io - Vultr DNS TLS Server A+ ( AUS )
- address_data: 45.76.113.31
tls_auth_name: "dot.seby.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM=
## 23 - The dns.seby.io - OVH DNS TLS Server A+ ( AUS )
- address_data: 139.99.222.72
tls_auth_name: "dot.seby.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: y8hXAlkRxglOPlYivo/S/E1EfNFoU9f/Uf4dQcXiHhg=
## 24 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE )
- address_data: 185.95.218.43
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 831vfDRFtFD6GNs592KLJtGWy1174q+L9GrgLTiLEZo=
## 25 - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE )
- address_data: 185.95.218.42
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: amK6e4lPnP+3bOVdh8unyfcLBsCNyPfvHAws+hXCrX4=
## 26 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA )
- address_data: 168.235.81.167
tls_auth_name: "dns-nyc.aaflalo.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: +J+sm9pbtEYYrcm45xqRqsOKmFuwTFdfrct/n5N5Pzo=
## 27 - The Privacy-First DNS TLS Server #1 A+ ( JPN )
- address_data: 172.104.93.80
tls_auth_name: "jp.tiar.app"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: VVZwjDE4AgVuuGDxr3kja+u/0uw2LBoVeO5TH0tfTfU=
## 28 - The Privacy-First DNS TLS Server #2 A+ ( SGP Hosted In USA )
- address_data: 174.138.29.175
tls_auth_name: "dot.tiar.app"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: zI+rGvaSUWXd0uhG1w8ZgR2ZZCAVzfaLPgEg1R+ucfl=
## 29 - The ibuki.cgnat.net DNS TLS Server A+ ( USA )
- address_data: 35.198.2.76
tls_auth_name: "ibuki.cgnat.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: v1FqNAlDF1cvui9S6E1zGYOOiCON4JepZPbBeNqkAK0=
## 30 - The PI-DNS.COM West USA DNS TLS Server A+ ( USA )
- address_data: 45.67.219.208
tls_auth_name: "dot.westus.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: UqbpjW5q+T28xsDG0/QAlklvT39U5h+EtZ9l0/POwaw=
## 31 - The PI-DNS.COM DNS TLS East USA Server A+ ( USA )
- address_data: 185.213.26.187
tls_auth_name: "dot.eastus.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: OupxDACOoLzFnGNfDLsv+Y1KOU/94kfV9wWnpP1+19g=
## 32 - The PI-DNS.COM Central Europe DNS TLS Server A+ ( DEU )
- address_data: 88.198.91.187
tls_auth_name: "dot.centraleu.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: a5xHUXhJT/rl7c9F1qNJafxosDRFNFA+qlLvE8WN56M=
## 33 - The PI-DNS.COM North Europe DNS TLS Server A+ ( FIN )
- address_data: 95.216.181.228
tls_auth_name: "dot.northeu.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: uPFdDaPL7tML0mdZg23LiXyC5AWp+wS+mRsxbeXpK8k=
## 34 - The PI-DNS.COM East Australia DNS TLS Server A+ ( AUS )
- address_data: 45.63.30.163
tls_auth_name: "dot.eastau.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: wTfoz9ckLNEh8Z5+Z+87gLWV/OjNLXCBq1XYnLvmXDk=
## 35 - The PI-DNS.COM East Asia DNS TLS Server A+ ( USA )
- address_data: 66.42.33.135
tls_auth_name: "dot.eastas.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: yZvYIR4ivuMRoAD/P8RBcc5TC31BRmcnVJGULFZ4Ows=
## 36 - The Snopyta DNS TLS Server A+ ( FIN )
- address_data: 95.216.24.230
tls_auth_name: "fi.dot.dns.snopyta.org"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: CgI1BzAYzsdcueKIbt682Gu+QEN2z9KDMCLdD192FSA=
## 37 - The NixNet Uncensored Las Vegas DNS TLS Server A+ ( USA )
## - or use ( tls_auth_name: "adblock.lv1.dns.nixnet.xyz" )
- address_data: 209.141.34.95
tls_auth_name: "uncensored.lv1.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: d4gBa/F8dM8cWcCpisAzVTp0SGKAEdfsM/2gHe/xJlk=
## 38 - The NixNet Uncensored New York DNS TLS Server A+ ( USA )
## - or use ( tls_auth_name: "adblock.ny1.dns.nixnet.xyz" )
- address_data: 199.195.251.84
tls_auth_name: "uncensored.ny1.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: g1jYIvb7hZn98EN0dZszrwdqZTE7so7j6Kb8tvuZQDc=
## 39 - The NixNet Uncensored Luxembourg DNS TLS Server A+ ( LUX )
## - or use ( tls_auth_name: "adblock.lux1.dns.nixnet.xyz" )
- address_data: 104.244.78.231
tls_auth_name: "uncensored.lux1.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 2Lx5gMhMV5DAfJKQcEJ+bL5RKFqgcPV/4gveSCMV6ps=
## 40 - The Lelux.fi DNS TLS Server A+ ( FRA Hosted In GBR )
- address_data: 51.158.147.50
tls_auth_name: "resolver-eu.lelux.fi"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: J9bGpxSju+xN7J9vu4W7+U6jzT1BpwoTCKMeqwf80u8=
## 41 - The Lightning Wire Labs DNS TLS Server A+ ( DEU )
- address_data: 81.3.27.54
tls_auth_name: "recursor01.dns.lightningwirelabs.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 8jveGZnOPVo3ZEpqP373s58WRH802JRT6s7iG1JEMwY=
## 42 - The dnsforge.de DNS TLS Server #1 A+ ( DEU )
- address_data: 176.9.1.117
tls_auth_name: "dnsforge.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: m51QwAhzNDSa3G7c1Y6eOEsskzp6ySzeOqy0LKcptDw=
## 43 - The dnsforge.de DNS TLS Server #2 A+ ( DEU )
- address_data: 176.9.93.198
tls_auth_name: "dnsforge.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: m51QwAhzNDSa3G7c1Y6eOEsskzp6ySzeOqy0LKcptDw=
# 44 - The Freifunk München DNS TLS Server A+ ( DEU )
- address_data: 195.30.94.28
tls_auth_name: "doh.ffmuc.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: xDA3eGNf/X3vu9frKPawOAnVFIjIqjp9KxR5nd4ZrQQ=
## 45 - The CIRA Canadian Shield DNS TLS Servers A+ ( CAN )
- address_data: 149.112.121.10
tls_auth_name: "private.canadianshield.cira.ca"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: sXmZXPsnkbQMw68THpV0Tgh9zCe12TtXIinSTf7lkkw=
- address_data: 149.112.122.10
tls_auth_name: "private.canadianshield.cira.ca"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: sXmZXPsnkbQMw68THpV0Tgh9zCe12TtXIinSTf7lkkw=
# 46 - The dns.dnshome.de DNS TLS Server #1 A+ ( DEU )
- address_data: 185.233.106.232
tls_auth_name: "dns.dnshome.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: q5AkxgnWVCVjCUNUKl3aIBpGTfXF5GahE0RcncwbZoc=
- address_data: 185.233.107.4
tls_auth_name: "dns.dnshome.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: q5AkxgnWVCVjCUNUKl3aIBpGTfXF5GahE0RcncwbZoc=
## 47 - The Usable Privacy DNS TLS Server A+ ( DEU / AUT )
- address_data: 149.154.153.153
tls_auth_name: "adfree.usableprivacy.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: apo4E7JrhTTLL08Y3JLq68Gp6yG1TgHKtwaQKnhqWFs=
## 48 - The DeCloudUs DNS TLS Server A+ ( DEU )
- address_data: 176.9.199.152
tls_auth_name: "dot.decloudus.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: CIeKIadXRDK1slGmnnQzvC38rKBbcGaSyXMPG6leHJA=
## 49 - The Hurricane Electric DNS TLS Server A+ ( USA )
- address_data: 74.82.42.42
tls_auth_name: "ordns.he.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: G9pQNrYB98Wll0AmBF/GsMMn6gaDbXDnInV1je1MaPo=
## 50 - The Stéphane Bortzmeyer DNS TLS Server A+ ( FRA )
- address_data: 193.70.85.11
tls_auth_name: "dot.bortzmeyer.fr"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: eHAFsxc9HJW8QlJB6kDlR0tkTwD97X/TXYc1AzFkTFY=
## 51 - The LibreDNS DNS TLS Server #1 A+ ( IND )
- address_data: 116.202.176.26
tls_auth_name: "dot.libredns.gr"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: V0Y0pvWkAwOPkNSPxDyZd/vJ2bo40ylADWJFu/ubPlM=
## 52 - The LibreDNS DNS TLS Server #2 A+ ( IND )
- address_data: 116.202.176.26
tls_auth_name: "dot.libredns.gr"
tls_port: 854
tls_pubkey_pinset:
- digest: "sha256"
value: V0Y0pvWkAwOPkNSPxDyZd/vJ2bo40ylADWJFu/ubPlM=
### Anycast Publicly Available DOT Test Servers ###
## 53 - The DNSlify DNS TLS Servers A+ ( Anycast )
- address_data: 185.235.81.1
tls_auth_name: "doh.dnslify.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: w5AEEaNvoBOl4+QeDIuRaaL6ku+nZfrhZdB2f0lSITM=
- address_data: 185.235.81.2
tls_auth_name: "doh.dnslify.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: w5AEEaNvoBOl4+QeDIuRaaL6ku+nZfrhZdB2f0lSITM=
### DNS Privacy Anycast DOT Public Resolvers ###
## 54 - The DNS.SB DNS TLS Servers A+ ( Anycast )
- address_data: 185.222.222.222
tls_auth_name: "dns.sb"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
- address_data: 185.184.222.222
tls_auth_name: "dns.sb"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
## 55 - The DNSPod DNS TLS Server #1 A+ ( CHN )
- address_data: 162.14.21.178
tls_port: 853
tls_auth_name: "dns.pub"
tls_pubkey_pinset:
- digest: "sha256"
value: Q1JRqG379NbZYD6KcA+jl8co9wuQNhg/YmN4dLImQpM=
## 56 - The DNSPod DNS TLS Server #2 A+ ( CHN )
- address_data: 162.14.21.56
tls_port: 853
tls_auth_name: "doh.pub"
tls_pubkey_pinset:
- digest: "sha256"
value: Q1JRqG379NbZYD6KcA+jl8co9wuQNhg/YmN4dLImQpM=

# Set the acceptable ciphers for DNS over TLS. With OpenSSL 1.1.1 this list is
# for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the
#tls_ciphersuites option. This option can also be given per upstream.
tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"
# Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required
# for this option. This option can also be given per upstream.
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
# Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_min_version: GETDNS_TLS1_2
# Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_max_version: GETDNS_TLS1_3

Save and Exit

Configure Stubby To Implement TLSv1.3 For OPNsense 20.1 And Above

Add the entry ( found directly above ) to the bottom of your stubby.yml
configuration file ( aka /usr/local/etc/stubby/stubby.yml ) -
make sure to skip a line after last entry before appending these settings:

Starting with OPNsense 20.1-RC1 in order for TLSv1.3 protocol to work properly
( read at all ) in your Stubby instance, OpenSSL 1.1.1 must be active and configured
in the kernel. OPNsense 20.1-RC1 and above does provide OpenSSL 1.1.1 support.
When you have OpenSSL 1.1.1 with TLSv1.3 support simply add the section above in order to set
Stubby to implement TLS1.3. The operative lines necessary are these two specifically
found at the bottom of the stubby.yml file above:

tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
tls_max_version: GETDNS_TLS1_3

See below for TLS1.3 Support Check SSH Commands -

openssl s_client -connect 46.101.66.244:853

OR :

openssl s_client -connect 45.32.55.94:443

Read Out Will Be Verified By These Lines Below:

Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_CHACHA20_POLY1305_SHA256

OR :

Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384

Depending on Configuration on Tested DOT Server

Note: You will not get a readout indicating that the selected Tested DOT Server utilizes
TLS1.3. This is due to the fact that OPNsense 20.1 does not fully utilize OpenSSL 1.1.1 -
When you run command # openssl version - you will see that OPNsense 20.1 still runs on
OpenSSL 1.02 - This is slated to be fixed on the next major OPNsense release.

Lastly, you can and should take advantage of this new DNS OVER TLS provider.
You need to sign up and use configured settings in order to use it.
NextDNS is a free service - ANYCAST and pretty much cutting edge.
ANYCAST speeds up your DNS - Here it is:
NextDNS https://my.nextdns.io/signup

or feel free to use and test
NextDNS " Try it now for free " Feature
go to : https://nextdns.io/

I also strongly encourage you to subscribe to blockerDNS found here : https://blockerdns.com/
This new DOH / DNS OVER TLS provider is the fastest I have run across. blockerDNS is run by
Tambe Barsbay a seasoned, thorough and extremely proficient tech practitioner.
blockerDNS is based in the U.S. and its infrastructure is hosted on Google Cloud Platform
and DigitalOcean. You can view blockerDNS subscription options here : https://blockerdns.com/tryit -
Most significantly, Tambe stands by his claim that he offers " Instant support by phone or email ".
Overall blockerDNS is a great DNSPRIVACY DNS Service. Tip : The Mobile $0.99 per month option should
suffice for most home users. Links : https://tambeb.com/ https://blockerdns.com/blog
https://blockerdns.com/support https://blockerdns.com/overview

4 - In order to have OPNsense use default start up script ( /usr/local/etc/rc.d/stubby.sh ) at boot time you will have to create a boot time start up script for it in /etc/rc.conf.d/. Not to prolong this - do the following :

# touch /etc/rc.conf.d/stubby - create the needed new file
# nano /etc/rc.conf.d/stubby - in the new file enter the following two lines:

stubby_enable="YES"
stubby_bootup_run="/usr/local/etc/rc.d/stubby.sh"

Save and exit / then make the file executable - once again - works for me : # chmod 744 /etc/rc.conf.d/stubby # chmod a+x /etc/rc.conf.d/stubby

5- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS.
Go To Services > UNBOUND > GENERAL SETTINGS

UNDER UNBOUND GENERAL SETTINGS
Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES

Under Custom options enter the following :
server:
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 192.168.7.11@8053 ## ( Your One Main LAN Address )
## END OF ENTRY

## Note : do-not-query-localhost: no
## this entry is necessarily removed
## from this UNBOUND configuration
## Disabling DNS Queries From Localhost ( 127.0.0.1 )

Outgoing Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES

Make Sure to NOT CHECK - DO NOT CHECK - the box for DNS Query Forwarding. Save and Apply Settings

Next -Under System > Settings > General Settings

Set the first DNS Server to Your One Main LAN Address ( 192.168.7.11 ) with no gateway selected /

Make sure that DNS server option

A - Allow DNS server list to be overridden by DHCP/PPP on WAN - Is Not I repeat - Is Not Checked !

and DNS server option

B - Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Checked - I repeat - Is Checked !

- Save and Apply Settings

C'est Fini C'est Ci Bon C'est Magnifique

Reboot your router just to sure. Lastly, you can check your DNS at GRC DNS Nameserver Spoofability Test - DNSLeak.com - or any such service. Your results will render the DNS PRIVACY Name Servers which you selected in your stubby.yml configuration file. You are now running DNS OVER TLS with GETDNS plus STUBBY ( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server.

Note: Starting with Unbound 1.7.2 qname minimisation is enabled by default.
However, I still add these settings manually.
These settings are entered under Unbound " Custom Options":
qname-minimisation: yes
qname-minimisation-strict: yes
harden-below-nxdomain: yes

Use either or both of these two methods to verify QNAME Minimisation
A - Run command : drill txt qnamemintest.internet.nl
and / or
B - Run command: dig txt qnamemintest.internet.nl +short and / or dig -t txt qnamemintest.internet.nl ( for more complete readout including DNSSEC results ).
AD = Authenticated Data (for DNSSEC only; indicates that the data was authenticated)
The results in any of these scenarios will show either:
"HOORAY - QNAME minimisation is enabled on your resolver

!”
or “NO - QNAME minimisation is NOT enabled on your resolver

.”
Reference https://discourse.pi-hole.net/t/unbound-and-qname-minimisation/10038/4
You will and should get HOORAY ! - if you used the name servers listed in this guide for your Stubby configuration.

VERY IMPORTANT TIP:
Please note that right at the top of the main DNS Privacy Test Servers Homepage ( https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ) It Ominously Declares:
DoT servers
The following servers are experimental DNS-over-TLS servers.
Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified. Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!!
For these reasons it is most important to check and verify your SPKI pin(s) for TLS authentication manually yourself from time to time. There are sure fire methods to make sure that you are using the correct value for any upstream nameserver ( aka tls_pubkey_pinset value ) - Go to https://blahdns.com/ and scroll down to the section to the yellow section entitled What is DNS OVER TLS click on it and it will open up.
When you do it will state some general information, but what you want to pay attention to is this section:
How to get SPKI
Most Simple and Direct Method:
gnutls-cli --print-cert -p 853 159.69.198.101 | grep "pin-sha256" | head -1
And / Or With Adjustment For SSL Port and Address Being Tested
gnutls-cli --print-cert -p 443 159.69.198.101 | grep "pin-sha256" | head -1 - where you must pkg install gnutls
OR
echo | openssl s_client -connect '185.49.141.37:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable.

https://www.dnsleaktest.com/ https://www.perfect-privacy.com/dns-leaktest https://cryptoip.info/dns-leak-test
https://www.grc.com/dns/dns.htm https://www.vpninsights.com/dns-leak-test and last but not least

https://cmdns.dev.dns-oarc.net/ for a thorough in depth DNS Test https://bash.ws/dnsleak/test/

Now all you need to do is run is a properly configured VPN Service. By doing so, running DNS over TLS with Stubby and GetDns will keep your VPN provider from spying on your encrypted DNS look ups - and also your DNS providers both the ISP ( replaced by encrypted Stubby ) and your Encrypted TLS DNS Service Provider will see your IP as the one from your encrypted tunneled VPN provider.
I am convinced this setup is the right strategy for both security and privacy. I think it to be the best practice for all those most serious about multi-layered cyber security.

Tutorials and FAQs / Re: HOW TO WIREGUARD OPNsense CLIENT DEAD SIMPLE

« on: February 13, 2020, 05:35:15 am »

Dear unmake,
Glad to be of assistance. I hope that you are well and enjoy your setup. I was able to get this some by doing some good old fashioned homework.

Peace,
directnupe

Tutorials and FAQs / Stubby Fails To Boot on OPNsense 19.7.9 - Solved !!!

« on: January 15, 2020, 07:51:28 pm »

Dear OPNsense DNS OVER TLS Users,

I was in error in reporting that this server was not working properly - that being dns-nyc.aaflalo.me aka dns-gcp.aaflalo.me -

I configured the server incorrectly which caused the error in Stubby being unable to boot correctly. The correct configuration is below :

## 19 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA )
- address_data: 168.235.81.167
tls_auth_name: "dns-nyc.aaflalo.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 39DtR8cTs4rBfMnUxuAngI6XUc1HTeZVziSbSC56MIM=

You will find the correctly configured server added back to my tutorial ( s )

Peace and God Bless,

directnupe

General Discussion / Stubby Fails To Boot on OPNsense 19.7.9 - Solved !!!

« on: January 15, 2020, 11:25:40 am »

Dear OPNsense DNS OVER TLS Users,
I was in error in reporting that this server was not working properly - that being dns-nyc.aaflalo.me aka dns-gcp.aaflalo.me - I configured the server incorrectly which caused the error in Stubby being unable to boot correctly. The correct configuration is below :

## 19 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA )
- address_data: 168.235.81.167
tls_auth_name: "dns-nyc.aaflalo.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 39DtR8cTs4rBfMnUxuAngI6XUc1HTeZVziSbSC56MIM=

You will find the correctly configured server added back to my tutorial ( s )

Peace and God Bless,

directnupe

Pages: [1] 2 3 4