OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of directnupe »
  • Show Posts »
  • Topics
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

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
  • Topics
  • Attachments

Topics - directnupe

Pages: [1] 2
1
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.


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

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

4
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

5
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

6
General Discussion / Logs Re: Stuuby Fails To Boot on OPNsense 19.7.9
« on: January 12, 2020, 09:34:00 am »
See here for solution to reported issue detailed below:

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

Dear francoand OPNsense Community,
Hello - this e-mail is in direct reply to your questions of a few days ago - those
specifically being :

What's the problem? / What is happening?

Well I hope that you are doing well. I have not heard from you in a few days
regarding the issue I have been having in being UNABLE to get Stubby to start
on OPNsense 19.7.9_1 - I set up OPNsense 19.7.9_1 on VMware Workstation 15.5.1,
and I was able to replicate the error which is responsible for Stubby failing to start.
This same error occurs on fresh install of OPNsense 19.7.9 on real hardware.
While OPNsense boots up - what appears on the screen are the contents of the
" /usr/local/etc/stubby/stubby.yml " file.
The message after stubby fails is to boot is below :

"Generic Error " could not parse config file " /usr/local/etc/stubby/stubby.yml "
Generic Error " /usr/local/etc/rc.d/stubby.sh " : Warning failed to start stubby


So, as I said in my earlier correspondence - I believe that that the issue lies within the
start up script. Perhaps, most importantly there needs to be a proper start script to
be written and placed in /etc/rc.conf.d/stubby location. To remind you this is what I have placed
within /etc/rc.conf.d/stubby file currently - see below :

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


Oddly enough, the network shows that there is an internet connection even though
I am unable to browse the internet. So, I hope this helps in getting to the bottom
of this bug which prevents proper functioning of DOT ( getdns and stubby ) on
OPNsense 19.7.9_1. There may have been a change made as to how to implement and
produce start up scripts on OPNsense starting with OPNsense 19.7.9 - if so
this change was not announced in the release notes. I will ask this of you now Franco.
Also, I am asking which chmod command ( s )  do you suggest using to make both files
/usr/local/etc/rc.d/stubby.sh and /etc/rc.conf.d/stubby executable ?

Peace and God Bless,

directnupe

Tutorial showing My SetUp Instructions:

https://forum.opnsense.org/index.php?PHPSESSID=k6ivse7g94849ga6nk9r8kg9g5&topic=13487.0

7
General Discussion / Need Assistance With GETDNS
« on: January 10, 2020, 02:03:03 am »
Dear franco and any who can assist -
Hello and I hope that you have been well. I am writing to you because I am having a slight issue with GETDNS and STUBBY - particularly this problem happens after I upgraded OPNsense to 19.7.9 ( HardenedBSD derivative ). The only issue I can possibly think of is that UNBOUND was recently upgraded to Unbound 1.9.6 -
In full disclosure I installed GETDNS and STUBBY on fresh VM and everything worked well and as expected.
I followed and wrote this guide :

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

Maybe the issue is with the custom /etc/rc.conf.d/stubby start up script needed
by OPNsense as I see that on REAL HARDWARE - the start up script does not
activate properly at boot time.  Anyway, I hope to find the answer on this - the OPNsense Forum.

Thanks and God Bless,

directnupe

8
Tutorials and FAQs / OPNSENSE DNS OVER TLS UPDATED NOW ! DEAD SIMPLE
« on: July 15, 2019, 07:06:36 pm »
Dear Community,
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 -


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

All of these name servers listed above DO NOT log ! repeat DO NOT log ! your DNS queries. In full disclosure some name servers claim to log traffic volume only. See here for details : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers and look under " Logging " column.

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.

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


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.

UNBOUND GENERAL SETTINGS
Network Interfaces =  Select ALL !

Under Custom options enter the following :
server:
do-not-query-localhost: no
forward-zone:
 name: "."    # Allow all DNS queries
 forward-addr: 127.0.0.1@8053

## END OF ENTRY

Outgoing Network Interfaces = Select ALL !

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 127.0.0.1   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 Not  - I repeat - Is Not Checked !

I now only run  127.0.0.1  ( Localhost ) configured as the only DNS SERVER on my WAN interface. If others were added to WAN, when I ran dig or drill commands /etc/resolv.conf allowed those addresses to be queried. I  only want to use Stubby yml Name Servers for DNS TLS , so this was the determinative factor in my reasoning and decision.


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

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.
           
Special thanks to all who helped me with this project.

Thank you all and God Bless Always In Peace,

directnupe

9
Tutorials and FAQs / HOW TO OpenVPN OPNsense CLIENT DEAD SIMPLE
« on: July 12, 2019, 10:08:29 pm »
Dear Community,
As is my wont as of late along with my personal inclinations and indulgences - here we go with the intro: I know you got it - lyrics to sing along : https://genius.com/Bobby-byrd-i-know-you-got-soul-lyrics and video : https://www.youtube.com/watch?v=-aY4x5l2QzA and Bonus : Take This with you as as we stroll along : https://genius.com/Hank-ballard-from-the-love-side-lyrics and video : https://www.youtube.com/watch?v=zKKcArCApx0 - Hello and here is the tutorial which details exactly how to get the great Hardened BSD based Distro OPNsense up and running with TORGUARD OpenVPN Client. OPNsense found here: https://opnsense.org/about/features/ and downloads found here : https://opnsense.org/download/

A - To begin you need to get your OpenVPN configuration files from the TORGUARD website. To do so login your TORGUARD account then go to Tools ( along the top of Login Page ) from drop Down Menu click on OpenVPN Config Generator. On this page that opens up - select in order - VPN Server Hostname/IP, VPN Protocol, VPN Port, VPN Cipher, OpenVPN Build, and whether or not you want to require TLS 1.2 as a minimum. After entering your choices, click on green " Generate Config " Box and download and save the file as we will use this later on in this process to configure OpenVPN settings on OPNsense FireWall.

B -Open the downloaded file ( it normally has same random number - mine is 96 in this example ). The first piece you need from this file is the CA ( certificate authority ). TORGUARD has just updated their certificates and are also in the process of enabling IPV6 support. Things just keep getting better with TORGUARD. There are actually two certificates in file - along with a tls-auth key. Let me back up for a minute - I chose NJ server UDP protocol - port 1195 - sha256 - aes-256-gcm - Build OpenVPN 2.4 and above plus checked box for TLS 1.2 - Your file may have different options depending on how you choose to connect to TORGUARD Server.

C - Now - to proceed - the CA you want ( in this case ) is the first one listed. Here is a direct link to the CA in case you prefer to grab it by this method : https://torguard.net/downloads/ca.txt - After you have this certificate log into your OPNsense Firewall - you will be presented with the " Lobby: Dashboard " page.  You can always get back to this page by clicking on " OPNsense Logo " at the uppermost  left corner of page. This is where you find " The OPNsense  Menu Settings  " which is from where we will configure TORGUARD OpenVPN Client. I will be using the .ovpn file and server I mentioned  earlier for the purposes of this tutorial going forward.

1 -  Begin by entering the ca in the appropriate field. In order to this, first Click on > System. A sub-menu will will be revealed - look for for the entry labeled " Trust ". Click on " Trust " - from there another sub-menu pops up - In that sub-menu Click on " Authorities " so that we can add the TORGUARD-CA to our firewall. You will now be on a landing page entitled " System: Trust: Authorities ".

Follow the steps below:

Click on ( + ) Add in the uppermost right corner of this page.
Follow these instructions:

Method: Import an existing Certificate
Description: TORGUARD
Certificate data: ( enter ( copy and paste ) certificate data content between <ca> and </ca>  from the CA mentioned above)

Click Save . ( Do not alter / enter anything else here - leave at defaults )

Now we need to configure OPNsense TORGUARD OpenVPN Client . Click on " OPNsense Logo " at the top of the left uppermost corner of the OPNsense Web Gui. . This action refreshes the Web Gui. which brings us back to the full Menu on the furthest most left column of the OPNsense Web Gui. Remember this as you can always get back to the full Menu by this method.

2 - Click on " VPN " in the left side vertical  Menu. From the pop-up sub-menu Click on " OpenVpn ".  From that pop-up sub-menu Click on " Clients ".  When you click on " clients " you will be presented with the " VPN: OpenVPN: Clients " Landing page. In order to proceed,

Click on ( + ) Add in the uppermost right corner of this page.
Follow these instructions:

Once on this page-  enter these are settings:

Disabled: Unchecked

Description: TORGUARD-NJ

Server mode: Peer to Peer ( SSL/TLS)

Protocol: UDP

Device mode: tun

Interface: WAN

Remote server: nj.east.usa.torguardvpnaccess.com  Port: 1195

Select remote server at random : Unchecked

Retry DNS resolution: Checked
(  Infinitely resolve remote server )

Proxy host or address: Blank

Proxy port: Blank

Proxy Authentication: none

Local port: Blank

User Authentication Settings:
User name/pass: ( from your TORGUARD Account )
Username: enter TORGUARD user name from Manual setup > userpass.txt file ( found on first line )
Password: enter TORGUARD password from Manual setup > userpass.txt file ( found on second line )

Renegotiate time : Blank

TLS Authentication: Leave this checked ( Uncheck box directly below it  then enter tls-auth key from TORGUARD )

Automatically generate a shared TLS authentication key. ( Uncheck this box first and then enter tls-auth key from
OpenVPN Config you generated and downloaded at the very beginning )

Peer Certificate Authority: TORGUARD ( name will be the " Descriptive name " you gave CA in Step 1 )

Client Certificate: None ( Username and Password required)

Encryption Algorithm: AES-256-GCM (256 bit key, 128 bit block)

Auth digest algorithm: SHA256 (256-bit)

Hardware Crypto: No Crypto Hardware acceleration

 IPv4 Tunnel Network : Blank

 IPv6 Tunnel Network : Blank

 IPv4 Remote Network : Blank

IPv6 Remote Network : Blank

Limit outgoing bandwidth : Blank

Compression: No Preference

Type-of-Service : Blank

Disable IPv6: Checked

Don't pull routes: Blank

Don't add/remove routes : Blank

Advanced configuration:

persist-key
persist-tun
remote-cert-tls server
reneg-sec 0
auth-retry interact
compress
auth-nocache
script-security 2
mute-replay-warnings
ncp-disable
key-direction 1
setenv CLIENT_CERT 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"


Verbosity level: 3 ( recommended )

Click Save.

You are redirected to VPN: OpenVPN: Clients Landing page and you should see a "green arrow" by "UDP nj.east.usa.torguardvpnaccess.com:1195 " in this example. Once you see this arrow, you will see that you are still in the OpenVPN pop-up sub-menu. Now, click on " Connection Status " in the OpenVPN pop-up sub-menu. This takes you to the VPN: OpenVPN: Connection Status Landing page. You should check under " Status " and make sure that it indicates that you tunnel is " up ".

3 - We now need to add a Hybrid Firewall Rule in order to get OPNsense TORGUARD OpenVPN fully up, running and completed.
We do this as follows. Once again, Click on " OPNsense Logo " at the op of the left uppermost corner of the OPNsense Web Gui - this action refreshes the Web Gui. which brings us back to the full Menu on the furthest most left column of the OPNsense Web Gui.
Follow these instructions:

A- Click on Firewall ( once again a pop-up sub-menu appears )
B - On that sub-menu click on NAT ( once again a pop-up sub-menu appears )
C - From that sub-menu click on  Outbound  ( you will now be presented with the Firewall: NAT: Outbound Landing page )

Once on the Firewall: NAT: Outbound Landing page, place a dot in the Hybrid outbound NAT rule generation
(automatically generated rules are applied after manual rules) radio button.Click Save ( which is located at the top of the page under the " Mode " section.

After clicking save, DO NOT ! - Repeat Do Not  Click Apply ! at this time. Instead- Click on ( + ) Add in the uppermost right corner of this page.  you will presented with the " Edit Advanced Outbound NAT entry " Landing page. Change the " Interface " setting from Wan to " OpenVPN " from the drop down menu.  Also , for Description : enter ( Made For TORGUARD ). Do not touch or change anything else whatsoever on this page.

Click Save -and you will be redirected to the Firewall: NAT: Outbound Landing page. You will see at the very top of the page it says " The NAT configuration has been changed.You must apply the changes in order for them to take effect. " So, Click on Apply Changes at the top of the page. Done with Firewall Rules for OPNsense TORGUARD OpenVPN.

Once again, Click on " OPNsense Logo " at the top of the left uppermost corner of the OPNsense Web Gui - this action refreshes the Web Gui. which brings us back to the full Menu on the furthest most left column of the OPNsense Web Gui.
Follow these instructions:'

Click on " VPN " in the left side vertical  Menu. From the pop-up sub-menu Click on " OpenVPN ".

A -  Now, click on " Connection Status " in the OpenVPN pop-up sub-menu.  you still should be up and running
B - From the same OpenVPN pop-up sub-menu - click on " Log File " and you should see that you are connected.

Good News ! I erroneously reported earlier that your WAN would not reboot without disabling OpenVPN Client using the Hybrid FireWall detailed in this tutorial. Actually, I was testing the setup on a an OPNsense VMware Work Station Machine. I can now emphatically state and assure you that your WAN will reboot if you use this setup ( along with Hybrid FireWall Rule ) on a real physical hardware installation. I disable all properties on the WAN interface when using Virtual Machines ( an old habit ) EXCEPT for VMware Bridge Protocol. This may be the problem when I deploy OPNsense on VMware Virtual Machine. I will test back and report back later. The good thing about VMware is that you can take snapshots, so you can always go back if you make an error. However, the BOTTOM LINE is that you can implement this guide on a hardware installation AS IS ! without any issues on OPNsense reboot. I will write up an updated tutorial for DNS OVER TLS WITH GETDNS+STUBBY on OPNsense. Since version OPNsense 18.7 - you may install stubby and getdns on OPNsense by  simply issuing command # pkg install getdns  - I am running DNS OVER TLS with OpenVPN now - and it works beautifully.
   
Lastly, in order to check that your are connected to TORGUARD - go to : https://torguard.net/whats-my-ip.php . At the very top of the page on the upper left hand side - click on " Check Now " and down under " Your Current Info " you will see your TORGUARD ROUTED OpenVPN IP Address - next to it you will see this : IP Address: 23.226.128.162 (Protected) - the key is you are now " Protected " which means that you are now successfully connected via TORGUARD OPNsense OpenVPN CLIENT. This setup will work with virtually any commercial OpenVPN Service Provider - trust me; I have tested a few others in addition to TORGUARD as outlined here in this tutorial. Remember that you may have to modify settings depending on your personal configuration and / or the features ( cryptography and so on ) that your commercial OpenVPN Service Provider supports and deploys.

Peace & Universal Love

10
Tutorials and FAQs / HOW TO WIREGUARD OPNsense CLIENT DEAD SIMPLE
« on: July 11, 2019, 08:56:35 pm »
Dear Community,
And I quote " Jimi ": I see that we meet again hmmm " see here: https://youtu.be/gFAQWjdCO8o and for the purpose as stated by the leader of The Family Stone " I Want To Take You Higher - see here : https://www.youtube.com/watch?v=1fQvlN8Aizw&pbjreload=101 Now after the intro - let's get down to business. This tutorial guide details dead simple GUARANTEED method(s) to get WIREGUARD Client up and running on OPNsense Firewall. I will explore the one I prefer first. Some of you may remember my work with GETDNS and STUBBY. Please read Mimugmail's comments ( the developer and maintainer of os-wireguard-devel plugin ) below in the first reply to this tutorial. He was kind enough to inform me of a few points so no one does extra work. Specifically, Mimugmail details methods for easier OPNsense ports installation and / or easier method to install WireGuard and WireGuard-Go packages. This installation is for commercial WireGuard Clients ONLY ! - where creation of keys and how to exchange them is not needed. The keys are generated and managed by your WireGuard VPN service provider - in my case - TorGuard.

1 - As per Mimugmail's  advice you can choose to install WireGuard either through ports or pkg install method. From his reply : You can install wireguard just via # pkg install wireguard && pkg install wireguard-go. The pkg versions are always the latest which were available at the time of the release. The version you mention here is already in the ports tree but the pkg will be in the next minor release. To speed this up you could also do on your opnsense installation: # opnsense-code ports && cd /usr/ports/net/wireguard && make install - As I wanted the latest package ( I did not care to wait for pkg update on OPNsense and I do not like installing the entire OPNsense Ports collection on my OPNsnese Instance ) - I did the following and it worked out great.

2 -  First install the necessary packages which are in the OPNsense repository by default with the command : # pkg install wireguard && pkg install wireguard-go - As Mimugmail points out, this will install latest versions of these packages. Ready to get this going and up and running then follow steps below.

3 - To begin you need to get your WIREGUARD configuration files from the TORGUARD website. To do so login your TORGUARD account then go to Tools ( along the top of Login Page ) from drop Down Menu click on Enable WIREGUARD Access. You will then be in your TorGuard Account Area. You will see this message along the top : Below is a list of WireGuard VPN Servers, Please click enable in front of the servers you like to connect to, and use the returned keys shown to connect. Currently, TORGUARD offers WIREGUARD Servers in USA - New York ( quite actually situated in Clifton, New Jersey ), Asia - Singapore and Europe - UK. Click on your preferred Server - Enable WIREGUARD. This will result in a green box below the now grayed out box - which states now Disable WIREGUARD- naturally leave your server enabled as you want to connect to the now enabled server. Next, Download Config file as the box allows you to do now that you have enabled your WIREGUARD Server. You will also see in the adjoining box the following :

Location VPN Server Keys Manage
USA - New York 1 159.xx.xxx.xx:xxx Server Public key: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
Your Private Key: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
Your Address: 10.xx.x.xxx/24


4 - Now I used this guide as the template for my manual installation of WIREGUARD on OPNsense see here : https://genneko.github.io/playing-with-bsd/networking/freebsd-wireguard-quicklook/ I will make this simple for you step by step. You may sing and / or hum along as we proceed.
A- First - configure WireGuard Client. TorGuard, AzireVPN, VPN.ac, Mullvad, IVPN, are commercial VPN providers which offer LIVE ! WireGuard Services now. I use TorGuard here is a sample file. Keys are dummies - only used for illustrative purposes in this tutorial- Use your real WireGuard configuration file here: Create file by command line - # nano /usr/local/etc/wireguard/wg0.conf - and enter the configuration file below ( copy and paste ) - substitute your real one. Save and Close. Done with this file.

# TorGuard WireGuard Config
[Interface]
PrivateKey = cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
ListenPort = 51820
DNS = 104.223.91.210
Address = 10.xx.x.xxx/24

[Peer]
PublicKey = 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
AllowedIPs = 0.0.0.0/0
Endpoint = 159.xx.xx.xxx:xxx
PersistentKeepalive = 25


B - Secondly, run command via SSH # wg-quick up wg0 ( wireguard-go is in package and  this action creates wireguard interface ) You may also run # wireguard-go wg0 to create wg0 but I prefer the first method mentioned here.

5 - Configure WireGuard Service with rc.d - for automatic startup/shutdown of the tunnel. In order to achieve this there’s already an rc.d script /usr/local/etc/rc.d/wireguard which came with the wireguard package. You need to issue this command :  # mv /usr/local/etc/rc.d/wireguard /usr/local/etc/rc.d/wireguard.sh then enter the file - # nano /usr/local/etc/rc.d/wireguard.sh Then go to bottom of file - lines 46 and 47 - change : ${wireguard_enable="NO"} to : ${wireguard_enable="YES"} and then add wg0 on line 47
: ${wireguard_interfaces=""} to : ${wireguard_interfaces="wg0"} ( wgZero ) - Save and Close - Make it executable, I run two commands - it works for me: # chmod a+x /usr/local/etc/rc.d/wireguard.sh # chmod 744 /usr/local/etc/rc.d/wireguard.sh - Done with this file.

6 - In order to have OPNsense use default start up script ( /usr/local/etc/rc.d/wireguard.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 :  # nano /etc/rc.conf.d/wireguard - in the new file enter the following two lines:
wireguard_enable="YES"
wireguard_bootup_run="/usr/local/etc/rc.d/wireguard.sh"
Save and Close - Make it executable- # chmod a+x /etc/rc.conf.d/wireguard # chmod 744 /etc/rc.conf.d/wireguard  / Done with this file.

7 - Now head to OPNsense WEBGUI in order to configure Wireguard Interface ( created earlier ) and FireWall Rule. First, on Left Side WebGui Column - go to Interfaces > Assignments -you will see wg0 interface - click (+) add button /symbol. Once the wg0 interface is listed as OPT ( 1 - 2 depending on your setup ) - Click underneath it - - enter checks in " Prevent interface removal' and " Enabled " - and enter description - I call mine " WIRE " - DO NOTHING ELSE HERE ! Save and Apply - Done with this phase.
Second - Firewall Rule - on Left Side WebGui Column - go to Firewall > NAT > Outbound > Once on this Landing Page put a Dot in radio button Hybrid outbound NAT rule generation - Click on Save - Do Not - Repeat Do Not Click Save and Apply At This Time - Instead Click on Add (+) Button on right side top of page - on the page which opens change Interface from WAN in drop down menu to your Wireguard ( wg0 ) Interface - in my case " WIRE " as I labeled it in the description of the interface I added earlier. Next - Change Source Address to " Lan net " and Translation/target to Interface address. Enter " Description -e.g. " Made For Wire "  now Click " Save " at bottom of page. You will be taken back to Firewall:Nat:Outbound Landing Page - Click on " Apply Changes " in right upper hand corner - Done with Firewall Rule for Lan. Repeat Firewall Rule Operation for all of your other Lan Interface Subnets if you choose to do so.

Your WireGuard Client is now installed and ready - you may enter command #
/usr/local/etc/rc.d/wireguard.sh restart
in order to start it up.  You may also reboot your OPNsense Router. Lastly, issue command  # wg show which prints out your WireGuard Connection statistics and configuration. I will install wireguard via # pkg install wireguard && pkg install wireguard-go as my go to method in the future.

Peace and Grace Be Unto All God's Creation

11
Tutorials and FAQs / Utmost Security For Those Who Deploy Stubby GETDNS
« on: April 20, 2019, 07:05:11 pm »
How Maintain Online Optimal Security - DNS OVER TLS Servers' SPKI pin(s) Maintenance and UpKeep -

See VERY IMPORTANT UPDATE: at end of this post for best DNS Privacy Test Servers configuration for STUBBY.

ForeThought: If you have figured out how to keep your DNS OVER TLS servers' SPKI pin(s) up to date and secure then skip to the last section where there is an excellent website : https://www.immuniweb.com/ssl/?id=Su8SeUQ4 for running an in depth SSL Security Test for all the servers you chose to deploy on your network.
My Dear Community,
There has been some understandable consternation and occasional grumblings concerning the hassles and difficulties inherent in having
to update and authenticate SPKI pin(s) when running DNS OVER TLS ( DNS Privacy Test Servers ). Towards making this process somewhat more
manageable and easier, I will share with you here some of the methods I employ towards achieving this goal.
First - I have found there are times where listed DNS Privacy Test Servers change their server IP's and / or hostnames from the ones listed  found here: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ) on the official page for this project. A few are horribly outdated. In order to avoid falling into this pitfall, I suggest that you do the following periodically.

A - Enter this command from SSH - dig +short dot-jp.blahdns.com ( for example ). This will return the current IP address of the server.
In this case 108.61.201.119 - For instance I use a DNS OVER TLS server not mentioned on the DNS Privacy Test Server page  - doh.defaultroutes.de - by running dig +short doh.defaultroutes.de - I confirmed the server address as 5.45.107.88. By the way the maintainer of this server mistakenly posted the SPKI pin for his server as the main Let's Encrypt Certificate - not the first one in the hierarchy. See below after I ran command - kdig -d @5.45.107.88 +tls-ca +tls-host=doh.defaultroutes.de example.com - the prinout read:

;; DEBUG:  #1, CN=doh.defaultroutes.de
;; DEBUG:      SHA-256 PIN: zYnx/ptyLlxHp9RQ5cHXbe2HJLXyZUT3A/lbyhd0B/M=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.

You see the first certificate is the correct one. While # 2 belongs to Let's Encrypt ( YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg= ) and is on all the certificates they issue and is valid for the next 697 days - you do the math. He in error listed the wrong PIN.
   
You may also issue the host command - host dot-jp.blahdns.com - which returns dot-jp.blahdns.com has address 108.61.201.119 and dot-jp.blahdns.com has IPv6 address 2001:19f0:7001:1ded:5400:1ff:fe90:945b
You may also use nslookup command  which works both ways - nslookup dot-jp.blahdns.com returns both the IPv4 and IPV6 server addresses.
nslookup 108.61.201.119 this returned with an answer for the server being jp1.blahdns.com - this error is why you need to run more than method to validate your findings for your settings.
I chose BlahDNS because not too long ago they changed both their servers' IP and hostnames. In addition their SPKI pin(s) have been updated ( changed ). Many ( not all ) of these DNS Privacy Test Server providers use Let's Encrypt Certificates and as many of you well know these must be renewed every three months. I will address this as we continue along.
Lastly, if needs be for any reason try Googling the server hostname or IP address to see if either has been modified.

Secondly - Now let's move on to see if are DNS OVER TLS servers' SPKI pin(s) are verified as being current ( not expired ) and trusted.
A - The easiest and most straightforward method of attempting to do this is to issue this command: gnutls-cli --print-cert -p 443 108.61.201.119 - where 443 is the port I chose to connect to the dot-jp.blahdns.com DNS TLS server. If I selected to connect over port 853 the I would have issued - gnutls-cli --print-cert -p 853 108.61.201.119 . BlahDNS permits both ports 443 and 853 for TLS  - see here for real time status and configuration of DNS Privacy Test Servers : https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/ You must install
gnutls-utils in order to run the commands. The problem here is that at times the output will falsely state that the certificate is not trusted. However - if you look along the top the printout will tell you much of this needed information.

 - subject `CN=dot-jp.blahdns.com', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x04dc4acf35d3bc6a62c79b553835e66351ac, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-04-10 19:13:11 UTC', expires `2019-07-09 19:13:11 UTC', pin-sha256="B0mMSct7Bbz4E7Lk6BwXuVzdxA1KuYtDs8pw7uaPmB4="

The certificate is B0mMSct7Bbz4E7Lk6BwXuVzdxA1KuYtDs8pw7uaPmB4= and is good from 2019-04-10 19 until 2019-07-09 19. Run kdig below in order to see if the certificate is truly trusted.

B - The second method is to install knot-dig ( OpenWrt ) or Knot2 ( FreeBsd ) ( you need to be able to run kdig command ). keeping with our example: kdig -d @108.61.201.119 +tls-ca +tls-host=dot-jp.blahdns.com example.com - this methods prints the CN ( Certificate Name ) and SHA-256 PIN: B0mMSct7Bbz4E7Lk6BwXuVzdxA1KuYtDs8pw7uaPmB4= ( aka SPKI pin ) for this server. Also here we see from the printout:

;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.

C - The third method for getting DNS OVER TLS servers' SPKI pin(s) will give you the pin- but virtually nothing else. Issue command as follows: echo | openssl s_client -connect '108.61.201.119:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64 - The print out reads - B0mMSct7Bbz4E7Lk6BwXuVzdxA1KuYtDs8pw7uaPmB4= which is the correct certificate. However, you can not tell if it is expired or trusted. For example, Surfnet ( which is getdns ) has several servers. dnsovertls3.sinodun.com ( 145.100.185.18 ) currently has an expired certificate. When I run - echo | openssl s_client -connect '145.100.185.18:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64 - The printed out gives me the correct certificate - 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= - However the certificate is expired. Running gnutls-cli --print-cert -p 853 145.100.185.18 - provides verification of expiration below:

- Certificate[0] info:
 - subject `CN=dnsovertls3.sinodun.com', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x030566ee19f2ef98451faa2322093fb000b3, RSA key 4096 bits, signed using RSA-SHA256, activated `2018-11-19 11:15:34 UTC', expires `2019-02-17. The certificate was good from 2018-11-19 until 2019-02-17. You can once again check real time status here: https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/

Running kdig -d @145.100.185.18 +tls-ca +tls-host=dnsovertls3.sinodun.com example.com - The readout is below which confirms expiration:
;; DEBUG: TLS, The certificate is NOT trusted. The certificate chain uses expired certificate.

So you see you must combine methods listed above to be truly secure and encrypted when running DNS Privacy Test Servers which essentially depend and rely on proper DNS OVER TLS servers' SPKI pin(s) being up to date and trusted.
Finally the Bonus:
As I wandered over the internet in search of security - I came across this website : ImmuniWeb SSL Security Test found here:
https://www.immuniweb.com/ssl/?id=Su8SeUQ4 Once on the website, you may test your remote DNS OVER TLS Servers. At the top of the page - simply enter the server hostname and port that you are using to connect to the remote server. For example I would enter -
dot-jp.blahdns.com:443 in keeping with the example I have been using throughout this guide. This site will resent you with a rating of the server and its' features. It will also list the certificate - when it was activated - when is the expiration date and encryption protocols and so much more. By the way, dot-jp.blahdns.com earns an A+ ratings. DNS is the backbone of your network - stay safe and secure out there
while you and your loved ones peruse the world of cyber connectivity. With dot-jp.blahdns.com:443 I encountered errors getting the correct certificate information. When I entered dot-jp.blahdns.com alone - everything went fine. You may have to play around with the entries. This is why it is best to have multiple tools and methods to cross check your certificates aka DNS OVER TLS Servers' SPKI pin(s) - hostnames and IP addresses. For instance - I know from two of these methods - one being this website the other using gnutls-utils - that the certificate for DNS TLS SERVER doh.defaultroutes.de ( 5.45.107.88 ) will expire in four days on 2019-04-24.

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:

nano /usr/local/etc/stubby/stubby.yml

resolution_type: GETDNS_RESOLUTION_STUB
round_robin_upstreams: 1
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 60000
listen_addresses:
  - 127.0.0.1@8053
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
upstream_recursive_servers:
# IPV4 Servers
### DNS Privacy Test Servers ###
## The Surfnet/Sinodun DNS TLS Server
  - address_data: 145.100.185.18
    tls_port: 853
    tls_auth_name: "dnsovertls3.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
# The securedns.eu DNS TLS Server  dot.securedns.eu
  - address_data: 146.185.167.43
    tls_auth_name: "ads-dot.securedns.eu"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
#The BlahDNS German DNS TLS Server
  - address_data: 159.69.198.101
    tls_auth_name: "dot-de.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: GsfF6a28usi59J/pUUtqbyfmmyKE7+7OfzdLXzUt/Aw=
#The BlahDNS Japan DNS TLS Server
  - address_data: 108.61.201.119
    tls_auth_name: "dot-jp.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: B0mMSct7Bbz4E7Lk6BwXuVzdxA1KuYtDs8pw7uaPmB4=
#The DNS Warden DNS TLS Primary Server
  - address_data: 116.203.70.156
    tls_auth_name: "dot1.dnswarden.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: deCWLScS/hqOKvzPDNr9JZdoBYsrWM7AWQ56biseGxA=
#The DNS Warden DNS TLS Secondary Server
  - address_data: 116.203.35.255
    tls_auth_name: "dot2.dnswarden.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: deCWLScS/hqOKvzPDNr9JZdoBYsrWM7AWQ56biseGxA=
#The Primary appliedprivacy.net DNS TLS Server
  - address_data: 37.252.185.232
    tls_auth_name: "dot1.appliedprivacy.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: ScYkwTIhR1AZGwAsy9Fgn+ET70+t8HR8giYq9abl7tA=
#The ibksturm DNS TLS Server
  - address_data: 217.162.206.220
    tls_auth_name: "ibksturm.synology.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: v9DZ6wtFZcs26wzq6lwHSlcV6o0Nvw/9pLiBarQJfQE=
#The dns.seby.io - Vultr DNS TLS Server
  - address_data: 45.76.113.31
    tls_auth_name: "dot.seby.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: xTjAOypMRG8ef7ZnQPk1TAku3xvtdQBPH+H3dCQyqDs=
#The Secure DNS Project by PumpleX DNS TLS Server
  - address_data: 51.38.83.141
    tls_auth_name: "dns.oszx.co"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: P/Auj1pm8MiUpeIxGcrEuMJOQV+pgPY0MR4awpclvT4=
#The edns.233py.com DNS TLS Server
  - address_data: 47.101.136.37
    tls_auth_name: "dns.233py.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: Aqo3emoFTNuVG85U26NnGJmjlTuUCm9H5cySw0HUYas=
#The Rubyfish Internet Tech DNS TLS Server
  - address_data: 47.96.179.163
    tls_port: 853
    tls_auth_name: "uw-dns.rubyfish.cn"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo=
### Anycast DNS Privacy Public Resolvers ###
#Quad9 'secure' DNS TLS Secondary Server
  - address_data: 149.112.112.112
    tls_auth_name: "dns.quad9.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg=

Save and Exit - Then reboot your Router for changes to take effect


Peace,

directnupe

References : https://blahdns.com/  https://dns.seby.io/

12
Tutorials and FAQs / SOLVED - GETDNS AND STUBBY W/ OPNSENSE 18.7.6 and UNBOUND 1.8.1
« on: October 27, 2018, 11:57:29 am »
Dear Community -

ALWAYS READ ENTIRE GUIDE FIRST BEFORE BEGINNING FOR BEST RESULTS

Some folks are dreading that upgrading to Opnsense 18.7.6 which ships with UNBOUND 1.8.1 breaks GETDNS and STUBBY. It ain't necessarily so ! Here are the solutions :

SECTION A

For Opnsense Ports Installation of GETDNS and STUBBY
1- If you installed GETDNS and STUBBY using Opnsense Ports - see this post :

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


The KEY is to remove GETDNS and STUBBY and all of the configuration files BEFORE YOU UPGRADE !

2 - Then upgrade to Opnsense 18.7.6 which will install UNBOUND 1.8.1

3 - Now re-install the upgraded GETDNS STUBBY port - which is now getdns-1.4.2_1 - this will compile being built against UNBOUND 1.8.1 - this is why the port was upgraded - that being to work with UNBOUND 1.8.1 -   getdns-1.4.2 was for UNBOUND 1.7.3 and - well - you get the picture if not check the screenshot below and / or go here: https://www.freshports.org/dns/getdns/ Note: Pay particular attention to this entry:

18 Sep 2018 18:24:05
Original commit files touched by this commit  1.4.2_1
Revision:480056
dns/unbound: update to 1.8.0
Bump PORTREVISION on to consumers due to library major version change


For instance I have a PfSense 2.4.4 Edge Router set up and it uses UNBOUND 1.7.3 and getdns 1.4.2_1 will break UNBOUND - as getdns 1.4.2 is what it needs. getdns 1.4.2_1 has different library requirements which are not suitable for UNBOUND 1.7.3 - so DNS resolution fails. This why you need to upgrade getdns on Opnsense 18.7.6 as it ships with UNBOUND 1.8.1.

4 - After your upgrade your port installation to getdns-1.4.2_1  All you need to do is refer to the original post here once again: https://forum.opnsense.org/index.php?topic=8611.0 - begin with Step 7 and follow each step from there and you will be up and running with getdns-1.4.2_1 and UNBOUND 1.8.1 on OpnSense 18.7.6

END SECTION A

SECTION B
For those who use STAND ALONE DNS OVER TLS STUBBY GETDNS PACKAGE
1 - It is necessary to reconfigure Unbound to stop using Stubby for DNS resolution. Go to System > Settings > General > and Check
     option - A - Allow DNS server list to be overridden by DHCP/PPP on WAN ( Click Save ) . Then go to Services > Unbound DNS > General  and then remove  contents of Custom Options Box:
server:
do-not-query-localhost: no
forward-zone:
 name: "."    # Allow all DNS queries
 forward-addr: 127.0.0.1@8053
Save and apply

2- After this you must delete the GETDNS package from Opnsense BEFORE YOU UPGRADE to 18.7.6
First - issue command - pkg delete getdns
You do that  ( from command line )  then follow these commands to remove configuration files.
Remove the following files by issuing these commands: # rm /usr/local/etc/rc.d/stubby.sh
# rm /usr/local/etc/stubby/stubby.yml and   
# rm /etc/rc.conf.d/stubby

3- Now upgrade to OpnSense 18.7.6 along with UNBOUND 1.8.1
Now all you need to do now is build and install  your new package getdns-1.4.2_1.txz
You do that by following the guide here - https://forum.opnsense.org/index.php?topic=8759.0
As Opnsense Tools installs FREEBSD synced ports on your FREEBSD Build Server - you will also get
getdns-1.4.2_1 - which is designed to work with UNBOUND 1.8.1
After you have built and have your getdns-1.4.2_1.txz package on your FREEBSD BUILD SERVER- go to Step 8 on this page once again : https://forum.opnsense.org/index.php?topic=8759.0

END SECTION B

SPECIAL CIRCUMSTANCES:
If you already have an existing FREEBSD Build Server and an outdated getdns port on it then you must  remove that  getdns port before building a new one. In order to accomplish that task see here : https://forum.opnsense.org/index.php?topic=8748.0 and follow and complete Step 2 Commands A & B . Now , since Opnsense Tools is already installed on your existing FREEBSD BUILD SERVER you need to update your ports collection. You do that by following these two  steps:  A - cd /usr/tools and B - make update - It is that simple. After the ports collection and everything is updated, you proceed thusly:
1 -  Go to this page : https://forum.opnsense.org/index.php?topic=8759.0 and complete procedures Step 6 and Step 7
2 - After creating your getdns-1.4.2_1.txz package on your FREEBSD BUILD SERVER simply go to Section B above in this tutorial and follow Steps 1, 2, and 3** in order to get your OpnSense Box up and running with getdns-1.4.2_1 and UNBOUND 1.8.1 on OpnSense 18.7.6

**( Obviously you can skip creating another getdns-1.4.2_1.txz package in Section B Step 3 as you have already done so by completing Item Number 1 above earlier on in this SPECIAL CIRCUMSTANCES section. This means that after you have upgraded your OpNsense Box to 18.7.6; you simply start and complete all tasks beginning with Step 8 here on this page : https://forum.opnsense.org/index.php?topic=8759.0  

END SPECIAL CIRCUMSTANCES

The two major things to remember are to to either de-install the GetDns port or delete the GETDNS  package PRIOR  to upgrading to Opnsense 18.7.6

Then upgrade port or build and re-install upgraded package depending on which method you first used to deploy GETDNS and STUBBY on your OpnSense box.

I hope this helps and I have done this myself and it is GUARANTEED to work!

Peace,

directnupe


Parting Thoughts:
For those who in the future may worry about GETDNS and STUBBY ever being being broken due to an UNBOUND DNS version being updated or upgraded, let me say this. You were not paying attention when I told you all from the very beginning that :

For all the doubters and naysayers concerning GETDNS and STUBBY - they are developed by NLnet Labs - the same folks who bring us Unbound, NSD, OPENDNSSEC and now GETDNS ( and STUBBY ) see here: https://www.nlnetlabs.nl/   https://www.nlnetlabs.nl/projects/getdns/

So, as NLnet Labs develops both UNBOUND and GETDNS ( along with STUBBY ) I am sure that they will do their best to make sure that both of these work well together.  If you notice GETDNS 1.4.2_1 has been out since mid September 2018 as has UNBOUND 1.8.0 The main issue and concern is when is the Distro that are using going to integrate and update these packages. For example, OpenWrt is on Unbound 1.8.2 and GETDNS 1.4.2_2 - while on Pfsense it's Unbound 1.7.3 and GETDNS 1.4.2
See here for further info: https://repology.org/metapackage/getdns/versions - even for FREEBSD  - it lists the Maintainer as zi@freebsd.org which is correct but lists GETDNS version as 1.4.2 - which is incorrect. We know that the current version for FREEBSD ports is GETDNS 1.4.2_1 - The major point is that NLnet Labs  is running " The Whole GETDNS STUBBY / UNBOUND Show " - so that is a good thing that one developer is handling all components needed for DNS OVER TLS ( aka DNS Privacy Project ).

Notice that this Commit was Submitted by jaap@NLnetLabs.nll (maintainer) in order to fix GETDNS so that it will work with new dns/unbound: update to 1.8.0 - which proves that NLnetLabs.nl is actively involved with development and maintenance of UNBOUND GETDNS and STUBBY

See here for FREEBSD GETDNS COMMIT FOR UNBOUND 1.8.1:


13
Tutorials and FAQs / DNS OVER TLS ABSOLUTE BEST CONFIGURATION FOR STUBBY IPV4 AND/OR IPV6
« on: September 12, 2018, 12:39:04 pm »
This tutorial speaks for itself

Supplement for Topics: https://forum.opnsense.org/index.php?topic=8579.0 https://forum.opnsense.org/index.php?topic=8759.0 and https://forum.opnsense.org/index.php?topic=8611.0

These are the best DNS PRIVACY NAME SERVERS for the detailed reasons listed below.

Edit your /usr/local/etc/stubby/stubby.yml - SSH and enter nano /usr/local/etc/stubby/stubby.yml - Use this Stubby configuration below:

#This link below for Stubby with Unbound Resolver :
#See here for how to configure Stubby:
#https://github.com/getdnsapi/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: 60000 # keep-alive for 1 min, for better performance

listen_addresses:
  - 127.0.0.1@8053   ## Stubby / Unbound ## Default Address/Port

round_robin_upstreams: 1

upstream_recursive_servers:
# IPV4 Servers
# The getdnsapi.net Server
  - address_data: 185.49.141.37
    tls_port: 853
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
# The Fondation RESTENA Server
  - address_data: 158.64.1.29
    tls_auth_name: "kaitain.restena.lu"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4=
### Test servers ###
## Surfnet/Sinodun Servers
  - address_data: 145.100.185.17
    tls_port: 853
    tls_auth_name: "dnsovertls2.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg=
# The securedns.eu Server
  - address_data: 146.185.167.43
    tls_auth_name: "dot.securedns.eu"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
# The dns.cmrg.net Server
  - address_data: 199.58.81.218
    tls_port: 443
    tls_auth_name: "dns.cmrg.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
# DNSPRIVACY.at Primary DNS TLS Server
  - address_data: 94.130.110.185
    tls_port: 853
    tls_auth_name: "ns1.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY=
# DNSPRIVACY.at Secondary DNS TLS Server
  - address_data: 94.130.110.178
    tls_port: 853
    tls_auth_name: "ns2.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg=
# The dns.neutopia.org Server
  - address_data: 89.234.186.112
    tls_port: 443
    tls_auth_name: "dns.neutopia.org"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
### Anycast services ###
#Tenta ICANN DNS TLS Primary Server
  - address_data: 99.192.182.200
    tls_auth_name: "iana.tenta.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0=

All of these name servers listed above DO NOT log ! repeat DO NOT log ! your DNS queries. In full disclosure some name servers claim to log traffic volume only. See here for details : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers and look under " Logging " column.

DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy - Run Test After Completing Full Setup. These name servers listed above help to consistently ensure QNAME Minimisation functions as designed within UNBOUND ( The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. )

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.

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


Configure your Unbound DNS Server to use Stubby for DNS Over TLS.

UNBOUND GENERAL SETTINGS
Network Interfaces = WAN LAN ( all of your LAN interfaces if you have more than one ) And You Must Select Localhost - repeat - You Must Select Localhost !

Under Custom options enter the following :
server:
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8053

Outgoing Network Interfaces = Localhost

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 127.0.0.1 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 Not - I repeat - Is Not Checked !

Optionally, along with 127.0.0.1 enter Tenta nameservers 99.192.182.200 and 99.192.182.100 under System > General Setup > DNS Server Settings > DNS Servers. Things Will Work Fine and as Intended. Your DNS will still resolve using the upstream name servers you selected in stubby.yml - I have found that it is best to use Tenta name servers as " custom DNS servers " for the System. I chose Tenta DNS because their name servers support both emerging DNS privacy standards - DNS-over-TLS, and DNS-over-HTTPS, which both provide last mile encryption to keep your DNS queries private and free from tampering. Tenta DNS also is the only AnyCast DOT service which includes built-in BGP integration, offering single engine convenience for DNS Anycasting with QNAME minimisation enabled on its' name servers by default. Main benefits of Tenta DNS as the backbone name servers on OpnSense:
A - Stop ISPs from spying on your browser history. DNS-over-TLS adds a layer of encryption over your DNS requests, keeping your ISP from seeing which websites you visit.

B - Stay private online. Tenta DNS logs a counter instead of queries so your data stays private. No one, not even Tenta, has access to your browsing data. These are the folks that developed and support the Tenta Browser see here: https://github.com/tenta-browser/tenta-dns and read About Tenta section at the very bottom of the page.
https://tenta.com/dns-setup-guides

Enjoy,

directnupe

14
Tutorials and FAQs / New Native Unbound DNS-Over-TLS Feature Starting With UNBOUND 1.7.1
« on: July 18, 2018, 10:28:02 pm »
Manually installing an openssl package from FreeBSD is asking for trouble. You'll have two instances of OpenSSL on the system, and that won't change the fact that Unbound is compiled against the base OpenSSL.
There isn't much we can do about this except to wait for OpenSSL 1.1.x to go in FreeBSD base, or try to convince Unbound devs to find a way to validate it without using a function only available in OpenSSL 1.1.x.



Hello All,
This will have to wait until OpenSSL 1.1.x is included in OpnSense or Unbound devs to find a way to validate it without using a function only available in OpenSSL 1.1.x
First, read this quote from Daniel Aleksandersen - the author of the first article referenced in this post entitled
" Actually secure DNS over TLS in Unbound ".

You’ll find quite a few blog posts and tutorials on how to configure encrypted DNS over TLS forwarding in Unbound. I’ve yet to find a single one that actually sets up TLS securely with certificate domain validation, however. Without TLS certificate domain validation your DNS can still be intercepted, monitored, or manipulated by a man-in-the-middle attacker with nothing more than a self-signed certificate. Here is how you set it up more securely.

I am the guy - directnupe - who wrote the guides - https://forum.opnsense.org/index.php?topic=8579.0
and https://forum.opnsense.org/index.php?topic=8759.0

You also can leave out GETDNS and STUBBY for DNS OVER TLS. This works on Unbound 1.7.1 and above. Opnsense (if you are current)runs Unbound 1.7.1 and above.

For DNS-Over-TLS support to Opnsense with Unbound without GETDNS and STUBBY -
see these articles - https://www.ctrl.blog/entry/unbound-tls-forwarding and https://www.monperrus.net/martin/randomization-encryption-dns-requests
In Opnsense the ca-certificates package is installed from the security/ca_root_nss package on FreeBSD. The final install path of that package is /etc/ssl/cert.pem .
The full path of /ca_root_nss is /usr/local/share/certs/ca-root-nss.crt. You can check that  this symlink exists on your system by running this command:
ln -s /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem - you should get return - " File exists "
So actually as the title of the article says in order to " Actually secure DNS over TLS in Unbound "
you should configure Unbound thusly:

UNBOUND GENERAL SETTINGS
Network Interfaces =   WAN LAN ( all of your LAN interfaces if you have more than one ) And You Must Select  Localhost - repeat -  You Must Select  Localhost !

Next go to UNBOUND GENERAL SETTINGS > Custom Options and enter:

server:
access-control: 127.0.0.0/8 allow # install unbound-control
interface: 127.0.0.1
minimal-responses: yes
cache-max-ttl: 14400
cache-min-ttl: 900
do-tcp: yes
hide-identity: yes
hide-version: yes
minimal-responses: yes
prefetch: yes
qname-minimisation: yes
rrset-roundrobin: yes
use-caps-for-id: yes
verbosity: 1
tls-cert-bundle: "/etc/ssl/cert.pem" # For Opnsense/FreeBsd

forward-zone:
name: "." # Allow all DNS queries

forward-addr: 145.100.185.15@443#dnsovertls.sinodun.com
forward-addr: 145.100.185.16@443#dnsovertls1.sinodun.com
forward-addr: 94.130.110.185@853#ns1.dnsprivacy.at
forward-addr: 185.49.141.37@853#getdnsapi.net
forward-addr: 199.58.81.218@443#dns.cmrg.net
forward-addr: 94.130.110.178@853#ns2.dnsprivacy.at
forward-ssl-upstream: yes

Outgoing Network Interfaces  =  WAN

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 127.0.0.1   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 Not  - I repeat - Is Not Checked !

Optionally, I entered 127.0.0.1 along with  Freenom World DNS Servers ( 80.80.80.80 and 80.80.81.81 )  under System > General Setup > DNS Server Settings > DNS Servers. Things Will Work Fine and as Intended. I have found that is best to use these DNS addresses for your System. http://www.freenom.world/en/index.html?lang=en

 -  Save and Apply Settings

I use GetDns Stubby and Unbound - so this is not how I employ DNS-Over-TLS ( see first 2 links above if you wish to take a look at that option )

Peace and God Bless,

directnupe

15
Tutorials and FAQs / SOLVED ( From The DNS Privacy Project ) DNS OVER TLS GETDNS+STUBBY PACKAGE
« on: May 24, 2018, 08:24:27 pm »
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

This Guide/Tutorial Is Deprecated Except For QNAME Minimisation and VERY IMPORTANT TIP Sections Below for informational purposes. Please Go to https://forum.opnsense.org/index.php?topic=13487.0 for New Updated Guide for DNS OVER TLS on OPNsense. The stubby.yml configuration file below is properly configured along with being up to date with the best DNS PRIVACY SERVERS.

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


Before you begin, check for all updates and upgrades.

3- After you have installed Freebsd 11 - you need to follow these steps here : https://www.tecmint.com/things-to-do-after-installing-freebsd/
A - The main things I did here ( from the link above ) were to  1. Update FreeBSD System / 2. Install Editors and Bash / 3. Secure SSH on FreeBSD ( you need this to make the rest of this process much easier for you ) / 7. Configure FreeBSD Static IP ( you really should do this while installing and the initial configuartion of Freebsd ) / 9. Manage FreeBSD Services ( very important in order to start programs at boot ).

4 - The method to install and upgrade ports and more is a neat, nifty and clever little utility which Opnsense offers aptly entitled "OPNsense release engineering toolkit". The page and instructions are here: https://github.com/opnsense/tools .I did find that it will easily install and upgrade my ( and your ) Opnsense Ports collection - which are totally synced with FreeBsd Ports. So here we go once again.

5  - While still on FreeBsd Build Server, install the " OPNsense release engineering toolkit " in order to install and upgrade your Opnsense Ports collection and then make your getdns-1.4.2.txz package.
     See here: https://github.com/opnsense/tools - the process is pretty straightforward.
A - issue command # pkg install git - ( see https://www.techsupportpk.com/2016/11/how-to-install-and-configure-git-on.html ) go to " Configuring Git " Section
B - issue command # cd /usr
C - issue command # git clone https://github.com/opnsense/tools
D - issue command # cd tools
E - issue command # make update - ( this is where the magic happens as this command will install and upgrade your ports collection ). Simply, answer " yes " or continue if any prompts ask you for input. As I said earlier this toolkit is capable of many other operations. However, those are beyond the scope of this tutorial.

6 -   Your Opnsense ports are now installed, completely up to date and synced with FreeBsd ports. While still on FreeBsd Build Server, you now need to install GETDNS and Stubby from your ports collection by issuing the following commands:
A -  # cd /usr/ports/dns/getdns/
B - # make config -   After entering the " make config " command you will be presented with the Options Screen - select them all except SAFESTACK. After selecting options, press enter OK or whatever to accept the options you just selected. You will now be back in ports directory for getdns port:
  # /usr/ports/dns/getdns/
Now issue command:  # make install clean
Let the installation run until it is done. After the installation completes, reenter the /root directory -
command : #cd /root   -  or start new SSH session in order to make your getdns-1.4.2.txz  package. It is a benefit to be able to take snapshots while running VmWare - I would suggest taking several snapshots during this process - now is a good time to do so as well.

7 -   While still on FreeBsd Build Server, you are ready to build your Opnsense getdns-1.4.2.txz  package. Do the following:
A -  # cd /usr/ports/dns/getdns/  it is important to enter this directory !
B - Once inside the /usr/ports/dns/getdns directory - simply issue the following the commands in order to build your Opnsense getdns-1.4.2.txz  package - the commands are:     1#  make clean  2#  make package -  once this is finished you will have your package.

8 - Now you are ready to export your getdns-1.4.2.txz package from your FreeBSD (build) server and import / install it to your Opnsense  box. WinSCP ( SCP protocol )  into your FreeBSD (build) server. Go into your /usr/ports/dns/getdns directory. Within the directory look for a folder labeled " work "  then look for sub directory labeled " pkg "  when you open that directory you will find your Opnsense getdns-1.4.2.txz package. Transfer (drag and drop) that package to a local folder on your desktop - I am on Windows 7.

9 - Now fire up your Opnsense box. I have done this so I can save you a few potential headaches as you must do  the following before installing Getdns and Stubby on Opnsense. This package has dependencies some of  which are not available in the Opnsense repos.  So do the following first in order to satisfy the packages' need for these dependencies:
Install these necessary dependencies to Opnsense before installing getdns-1.4.2.txz package
A-  #  pkg install libev
B - #  pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libidn-1.34.txz
C - #  pkg install libuv

10 -  WinSCP ( SFTP protocol ) into your Opnsense box and transfer (drag and drop) the getdns-1.4.2.txz package from the local directory you exported it to earlier ( in this case on my Windows 7 machine ) into the /home directory of your Opnsense Firewall. You are now ready to install the package with the following ssh commands: #  cd /home and then issue the all important command  # pkg add getdns-1.4.2.txz ( if for any reason later you need to re-install this package you may do so by issuing command: # cd /home and # pkg add -f getdns-1.4.2.txz - You can remove package from /home directory after everything is up and running by # cd /home and# rm getdns-1.4.2.txz -

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

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

13 - 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
My config file for Stubby yml: you can choose other resolvers from here (https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ). Here is a list of all DNS Privacy Servers in the raw. Add ( tls_port: 853 ) after ( - address_data: ) entry:
https://github.com/getdnsapi/stubby/blob/release/0.2.3/stubby.yml.example
See here for how to configure Stubby: https://github.com/getdnsapi/stubby
I prefer to run these DNS TLS SERVERS.
## Begin Sample /usr/local/etc/stubby/stubby.yml file configuration:
# 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).
## All DNS Privacy Servers Below Tested and Updated On November 3 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


## End of Sample File  /

 Save and Exit

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

Add this entry ( found directly below ) 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:

# 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


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

All of these name servers listed above DO NOT log ! repeat DO NOT log ! your DNS queries. In full disclosure some name servers claim to log traffic volume only. See here for details : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers and look under " Logging " column.

DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy - Run Test After Completing Full Setup
These name servers listed above help to consistently ensure QNAME Minimisation functions as designed within UNBOUND ( The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. )

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.

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


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

15 - Now you must configure your  Unbound DNS Server to use Stubby for DNS Over TLS.

UNBOUND GENERAL SETTINGS
Network Interfaces =   WAN LAN ( all of your LAN interfaces if you have more than one ) And You Must Select  Localhost - repeat -  You Must Select  Localhost !

Under Custom options enter the following :
server:
do-not-query-localhost: no
forward-zone:
 name: "."    # Allow all DNS queries
 forward-addr: 127.0.0.1@8053

## END OF ENTRY

Outgoing Network Interfaces  =  Localhost

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 127.0.0.1   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 Not  - I repeat - Is Not Checked !

I now only run  127.0.0.1  ( Localhost ) configured as the only DNS SERVER on my WAN interface. If others were added to WAN, when I ran dig or drill commands /etc/resolv.conf allowed those addresses to be queried. I  only want to use Stubby yml Name Servers for DNS TLS , so this was the determinative factor in my reasoning and decision.

-  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 Spoofability Test - DNS Leak - 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.

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://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.

Special thanks to all who helped me with this project.
Thank you all and God Bless Always In Peace,
directnupe

Pages: [1] 2
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2