Jump to content
TorGuard

Search the Community

Showing results for tags 'encryption'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • The Lounge
    • General Stuff
    • Member Tutorials
    • TorGuard Reviews
  • TorGuard Software Releases
    • Network Status
    • TorGuard Client Releases
    • Android Client Releases
    • iOS App Releases
    • Chrome Extension Releases
    • Firefox Extension Releases
    • Edge Extension Releases
  • TorGuard VPN Support
    • VPN Questions and General Support
    • VPN Windows Support
    • VPN Mac Support
    • VPN Linux Support
    • VPN Router Support
    • iOS VPN Support
    • Android VPN Support
  • TorGuard Proxy Support
    • Proxy Questions and General Support
    • Firefox Extension Support
    • Chrome Extension Support

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Found 25 results

  1. Look A Here - Look A Here - Well, I am back one more again - spinning those hits that get you thumping and pumping for the tasks ( s ) ahead. You all know " The Time Honored Intro " - https://www.youtube.com/watch?v=xg5IRsPs5E8 and https://www.youtube.com/watch?v=2u-n__lHhWU sing along - https://genius.com/Led-zeppelin-good-times-bad-times-lyricshttps://www.youtube.com/watch?v=h1vKOchATXs - dig the vibe https://genius.com/Boogie-down-productions-my-philosophy-lyrics - and the original heart throb as a Surprise Bonus - https://www.youtube.com/watch?v=pc_F3PaYgl0 Now, that I have satisfied the full spectrum in time and space of " The Beats " needed here we go with pfSense AdGuardHome. See here for basic guide : pfSense AdGuardHome - Now this guide is designed for AdGuardHome on pfSense; however, I am going to modify it so that it is much simpler for you to master. 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 pfSense UNBOUND. However, if you prefer to use your LAN for AdGuardHome DNS as described in tutorial by all means just follow the original guide. 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 pfSense 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. # 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. 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 pfSense by the end of this guide / tutorial. Step 4 - After installation scripts runs, you should be seeing something like below. 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. Go to Services > DNS Resolver > General Settings > Display Custom Options > Custom options In the Box For " Custom options " enter the following below : server: do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] forward-addr: ::[email protected] Then Go To System > General Setup > DNS Server Settings > DNS Servers and enter the following below for DNS Servers : A - 127.0.0.1 B - ::1 both without any gateway and C - Remove ( Do Not ) Check " DNS Server Override " " Allow DNS server list to be overridden by DHCP/PPP on WAN " Option D - Leave Option " DNS Resolution Behavior " at Default Setting 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 pfSense AdGuardHome. Follow these steps below : 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 : #!/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: # chmod 755 /usr/local/etc/rc.d/adguardhome.sh E - In order to have pfSense 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 : # 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 : # 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 web_session_ttl: 720 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: 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 - 1.0.0.2 - 2606:4700:4700::1112 - 2606:4700:4700::1002 all_servers: true Enter the following below for filters : 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 : a - # /usr/local/etc/rc.d/adguardhome.sh restart b - # /usr/local/etc/rc.d/unbound onestart Note : The best practice is to reboot your pfSense after configuring AdGuardHome via AdGuardHome.yaml . 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 The target directory for ACME certificates is actually under /cf/config/acme/. Just browse to directory through Diagnostics > Edit File > Browse > The open /cf - then open /conf - open up /acme - just open these two files below and copy and paste them into appropriate boxes in the AdGuardHome WEB GUI. These are the files you will need to copy and paste below : freedom.babybaby.mywire.org/fullchain.cer freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key In order to log into AdGuardHome WEB GUI when it is encrypted you must move pfSense 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 ) : 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 pfSsense Encrypted WEBGUI at : 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. 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 : https://freedom.babybaby.mywire.org:443 - with Encryption Enabled you will see " green padlock " when logging in / your certificate pulls double duty Here Is What You Get After Install : 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. 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. 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. 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 : # 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 : server: do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] forward-addr: ::[email protected] 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 : 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 : #!/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" Make it executable - I run this command - it works for me: # 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 : # 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 : # 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 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: 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 : 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 : a - # /usr/local/etc/rc.d/adguardhome.sh restart b - # /usr/local/etc/rc.d/unbound onestart Note : The best practice is to reboot your OPNense after configuring AdGuardHome via AdGuardHome.yaml . 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 : /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 AdGuardHome WEB GUI when it is encrypted 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 ) : 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 : 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. 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 : https://freedom.babybaby.mywire.org:443 - with Encryption Enabled you will see " green padlock " when logging in / your certificate pulls double duty Here Is What You Get After Install : 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.
  3. Now, I am going to take you to " back in the day " hearkening the good ole' times of yore - maybe some will remember " The Blue Lights In The Basement " we pay tribute in the time honored tradition of the " Intro " ( yes - it is mandatory ) showcasing these classics -- https://www.youtube.com/watch?v=ZY7fZ95XfMY and the lyrics to sing and hum along - https://www.lyricsfreak.com/l/linda+jones/for+your+precious+love+spoken_21111123.html and on a lighter note ( no pun intended ) - free yourself - https://www.youtube.com/watch?v=K9F5xcpjDMU - and keep the feeling - https://genius.com/Black-sheep-the-choice-is-yours-lyrics Surprise Bonus - https://www.youtube.com/watch?v=WjI3pzhXO14 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 ". Attention : From OG Poster ( brokenpipe ) !!!! It is possible to install AdguardHome under /opt/, but this directory can grow. Old binaries are moved as backup after an update. blocklists can become relatively large. It is better to move AdGuardHome to a USB stick. So it will survive future OpenWRT updates !!!! That Means Setup Exroot for your AdGuardHome Install If At All Possible Here is a great deal on 4gb USB 3.0 Drives - Made and Shipped In The Good Ole' USA : USB KEYCHAIN KEY DRIVE 3.0 4 GB YO ! : I strongly suggest that you watch this video before you begin. Although lengthy - it is very informative and worthwhile. Van Tech Corner OpenWRT AdGuard Home Video 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 OpenWRT by the end of this guide / tutorial. The setup uses UNBOUND. There is already a guide / tutorial incorporating DNSMASQ with AdGuard Home found here : OpenWrt AdGuard Home 101 ( DNSMASQ ) Many have stated " you don't need UNBOUND ". I answer that with " Well, I don't need custom made Armani suits or a Ferrari either. You see where I'm going with this ? 1 - First you will need to get the appropriate AdGuard Home package for your router's architecture. For example, I have WRT3200ACM, WRT32x, Wrt1900ACS V2, WRT1200AC, and NightHawk R7800. All of these have ARMv7 processors. You should find out your architecture before proceeding. Now there is a script on AdGuard Home - found here - https://github.com/AdguardTeam/AdGuardHome. However, I have never been able to get the automatic download and install script to work properly. So, I manually download and install AdGuard Home on OpenWRT, because this method is GUARANTEED ! to work. In order to find your router's Architecture - go to Luci > Status > Overview then under System - on the third line down underneath Model ( indicating your router ) You will find your router's Architecture - for the router I am currently running for example these are the entries below : Model Netgear Nighthawk X4S R7800 Architecture ARMv7 Processor rev 0 (v7l) Target Platform ipq806x/generic You can also enter command below : # cat /proc/cpuinfo or you can install hwinfo / opkg update && opkg install hwinfo and issue command below : # hwinfo ### this will render all the specs for your router - look at the beginning of readout for CPU First, Install These Packages To Get Started - The Main One Needed is sudo - otherwise you will not be able to install AdGuardHome successfully - as always # opkg update opkg update ; opkg install ca-certificates ca-bundle sudo libustream-mbedtls libustream-openssl libwolfssl libustream-wolfssl luci-ssl px5g-wolfssl wpad-basic-wolfssl luasocket curl libevent2-7 haveged unzip ip-full curl wget libmbedtls12 tar tcpdump-mini then run # opkg update again - and then install packages for UNBOUND as indicated below : opkg update ; opkg install unbound-daemon unbound-control unbound-control-setup luci-i18n-unbound-en luci-app-unbound unbound-anchor unbound-host unbound-checkconf NOTE : When running DNS OVER TLS ( my setup ) - You first must stop and disable odhcpd. This setup depends on DNS functionality. odhcpd conflicts with dnsmasq for dhcp hence also DOT. The commands are as below : # /etc/init.d/odhcpd stop # /etc/init.d/odhcpd disable 2 - There are two channels to download AdGuard Home - Beta and Edge. The consensus on the thread - found here : [HowTo] Running Adguard Home on OpenWrt - is to run Edge. As I mentioned earlier, make sure that you download the correct AdGuard Home package for your router's processor. In my case that is the following link - https://static.adguard.com/adguardhome/edge/AdGuardHome_linux_armv7.tar.gz - notice that edge is named in the link. A - Just copy and paste your correct link in your browser from this section of AdGuard Home - after downloading - you will have AdGuardHome_linux_armv7.tar.gz on your desktop. Create a folder to extract the archive into - and use WinRAR, 7Zip, PeaZip or some such file archiver to unzip AdGuardHome_linux_armv7.tar.gz ( remember to choose the proper package for your router ). You will now have a decompressed folder named " AdGuardHome " . 3 - Now we are going to use WINSCP, but first we need to create the default proper directory for AdGuard Home installation. Go into SSH shell - enter commands : A - # mkdir -p /opt/ B - After creating directory, fire up WINSCP - open /opt/ directory on the right side of the application - then Drag & Drop the AdGuardHome decompressed folder from the directory you had it in on your desktop. If you know how to use SCP on OpenWRT ( Linux ) you may use that method here as well. After closing WINSCP - then issue this command C - # chmod 755 /opt/AdGuardHome/AdGuardHome ## and then enter next command for installation of AdGuardHome D - # /opt/AdGuardHome/AdGuardHome -s install You should be seeing something like below. 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.11.130:3000 4 - Pick out your LAN interface so that you can perform initial configuration of AdGuardHome . Now first 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 Van Tech Corner OpenWRT AdGuardHome A - Choose LAN Address For Web Interface - Port 8080 / Choose Localhost ( 127.0.0.1 ) For DNS - Change to Port 5353 B - enter commands below ( again adjust for your actual LAN IP Address ) : ( a ) # uci add_list [email protected][-1].server='/pool.ntp.org/129.6.15.30' ## --- Your router date & time must be correct in order to have sucessful tls init ( b ) # uci add_list [email protected][-1].server='127.0.0.1#5353' # UNBOUND IPV4 ( c ) # uci add_list [email protected][-1].server='::1#5353' # UNBOUND IPV6 ( d ) # uci add_list [email protected][-1].server='192.168.11.130#8080' # Port used for Web Interface - use your actual LAN IP ( e ) # uci set [email protected][-1].noresolv=1 # Use only servers listed here in this file ( f ) # uci commit && reload_config Note : Go into nano /etc/config/dhcp and modify file as detailed below : ### option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto' Make sure you disable (apply "###" in front) of entry above in order to ignore ISP Supplied DNS Servers 5 - Configure Unbound - My WORKING CONFIG /etc/unbound/unbound_srv.conf ( Adjust For Your Router ) see here: https://nlnetlabs.nl/documentation/unbound/howto-optimise/ cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF # Use the root servers key for DNSSEC tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt # use all CPUs num-threads: 2 # more outgoing connections # depends on number of cores: 1024/cores - 50 outgoing-range: 120 num-queries-per-thread: 30 max-udp-size: 3072 # power of 2 close to num-threads key-cache-slabs: 1 # more cache memory, rrset=msg*2 msg-buffer-size: 8192 msg-cache-size: 100k msg-cache-slabs: 1 num-queries-per-thread: 30 rrset-cache-size: 100k rrset-cache-slabs: 1 infra-cache-slabs: 1 # Larger socket buffer. OS may need config. so-rcvbuf: 4m so-sndbuf: 4m hide-identity: yes hide-version: yes hide-trustanchor: yes harden-glue: yes harden-dnssec-stripped: yes harden-below-nxdomain: yes serve-expired: yes serve-expired-ttl: 3600 neg-cache-size: 10k aggressive-nsec: yes so-reuseport: yes unwanted-reply-threshold: 10000 target-fetch-policy: "2 1 0 0 0 0" val-clean-additional: yes ip-ratelimit: 300 ip-ratelimit-factor: 10 outgoing-num-tcp: 1 incoming-num-tcp: 1 infra-cache-numhosts: 200 minimal-responses: yes rrset-roundrobin: yes use-caps-for-id: no do-ip6: yes do-ip4: yes do-tcp: yes do-udp: yes prefetch: yes prefetch-key: yes qname-minimisation: yes qname-minimisation-strict: yes cache-min-ttl: 3600 cache-max-ttl: 14400 deny-any: yes edns-buffer-size: 1232 UNBOUND_SERVER_CONF then enter these two commands below : # uci set '[email protected][0].query_minimize=1' # uci commit 6- Configure Unbound To Use AdGuardHome enter the following below : cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF server: do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] forward-addr: ::[email protected] UNBOUND_FORWARD_CONF 7 - Enter these commands below - # Move dnsmasq to port 53535 where it will still serve local DNS from DHCP # Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535 ( a ) # uci set '[email protected][0].port=53535' # Configure dnsmasq to send a DNS Server DHCP option with its LAN IP # since it does not do this by default when port is configured. ( b ) # uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)" ( c ) # uci set '[email protected][0].dhcp_link=dnsmasq' # Save & Apply (will restart dnsmasq, DNS unreachable until unbound is up) ( d ) # uci commit && reload_config # Restart (or start) unbound (System -> Startup -> unbound -> Restart) - or ( e ) # /etc/init.d/unbound enable - then ( f ) # /etc/init.d/unbound start 8 - Disable Sending DNS Requests to ISP Provided DNS Servers 8 - Disable Sending DNS Requests to ISP Provided DNS Servers ( a ) # uci set network.wan.peerdns='0' ( b ) # uci set network.wan.dns='127.0.0.1' ( c ) # uci set network.wan6.peerdns='0' ( d ) # uci set network.wan6.dns='::1' ( e ) #uci commit && reload_config 9 - nano /etc/config/unbound - Configure Main UNBOUND FILE config unbound 'ub_main' option add_extra_dns '0' option add_local_fqdn '1' option add_wan_fqdn '1' option dhcp4_slaac6 '0' option dns64 '0' option dns64_prefix '64:ff9b::/96' option domain 'your.domain.here' option domain_type 'transparent' option edns_size '1232' option extended_stats '1' option hide_binddata '1' option interface_auto '1' option extended_luci '1' option luci_expanded '1' option listen_port '53' option localservice '1' option manual_conf '0' option num_threads '2' option protocol 'mixed' option query_minimize '1' option query_min_strict '1' option rate_limit '0' option rebind_localhost '0' option rebind_protection '1' option recursion 'aggressive' option resource 'medium' option root_age '9' option ttl_min '120' option unbound_control '1' option validator '1' option validator_ntp '1' option verbosity '1' list trigger_interface 'lan' list trigger_interface 'wan' option query_minimize '1' list domain_insecure '3.us.pool.ntp.org' list domain_insecure 'your.domain.here' option dhcp_link 'dnsmasq' 10 - Run these three commands to complete UNBOUND ( a ) # unbound-checkconf ( b ) # unbound-control-setup ( c ) # unbound-anchor -a "/etc/unbound/root.key" 11 - 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: ( f ) # nano /opt/AdGuardHome/AdGuardHome.yaml web_session_ttl: 720 dns: bind_hosts: - 127.0.0.1 - ::1 port: 5353 B - We will edit the sections listed below ( a ) upstream_dns: ( b ) bootstrap_dns: ( c ) all_servers: 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 Above I used Cloudflare with Malware Blocking DNS using Encryption- if you preferCloudflare Plain DNS then it is : bootstrap_dns: - 1.1.1.1 - 1.0.0.1 - 2606:4700:4700::1111 - 2606:4700:4700::1001 all_servers: true and for Cloudflare Plain DOT Servers using Encryption - where you enter your own valid SSL certificates chain for your domain : bootstrap_dns: - 1.1.1.1:853 - 1.0.0.1:853 - 2606:4700:4700::1111:853 - 2606:4700:4700::1001:853 all_servers: true C - Enter the following below for filters : 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: [] D - From Original Post [HowTo] Running Adguard Home on OpenWrt Adguard Home Regex: Those are really good regex rules which already block 50% of all ads/trackers/bots etc. You have to add the to http://192.168.11.130:8080/#custom_rules ( as per this example - use your actual LAN IP ) https://github.com/mmotti/adguard-home-filters/blob/master/regex.txt Configure Via /opt/AdGuardHome/AdGuardHome.yaml : nano /opt/AdGuardHome/AdGuardHome.yaml user_rules: - https://github.com/mmotti/adguard-home-filters/blob/master/regex.txt dhcp: After configuring AdGuardHome via AdGuardHome.yaml one or both of the commands below : a - # /etc/init.d/AdGuardHome restart b - # /etc/init.d/dnsmasq restart 12- 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 from my tutorial : Dynu OpenWRT 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 my tutorial above you can issue yourself a LetsEncrypt Certificate cost free. Cross referencing my tutorial above your certificate and key would be the following below : a - /root/.acme.sh/freedom.babybaby.mywire.org/fullchain.cer b - /root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key You have the option to " set the path " ( use a & b above ) or copy and paste them into the appropriate boxes found at the bottom of Encryption settings page. You must move Luci to different port than 443 see commands below : c - # nano /etc/config/uhttpd list listen_https '0.0.0.0:1443' list listen_https '[::]:1443' You may now log into Encrypted AdGuardHome WEB GUI - this option is available by entering the following ( from example above ) : https://freedom.babybaby.mywire.org:443 - with Encryption Enabled you will see " green padlock " when logging in / your certificate pulls double duty. Since you moved OpenWRT Admin Port to Port 1443 you may still log into your Luci Encrypted WEBGUI at : https://freedom.babybaby.mywire.org:1443 How To Upgrade Your AdGuardHome Install : Some claim that you can upgrade from AdGuardHome WEBGUI - it has never worked for me while running OpenWRT. No need to fear - here is how to upgrade when new EDGE Version pops up. Hopefully, if you initially Setup Exroot for your AdGuardHome Install ( that means on a USB Stick ) then all you have to do is grab the new installation by doing exactly what you did when you first installed AdGuardHome. With Exroot - you do not have to worry about any space issues - this is why we recommend Exroot to begin with. 1 - Download the correct AdGuard Home package for your router's processor. 2 - Create a folder to extract the archive into - and use WinRAR, 7Zip, PeaZip or some such file archiver to unzip AdGuardHome_linux_your_router.tar.gz 3 - You will now have a decompressed folder named " AdGuardHome " . 4 - Then issue this command below : # /etc/init.d/AdGuardHome stop 5 - Fire up WINSCP - open /opt/ directory on the right side of the application - then Drag & Drop the AdGuardHome decompressed folder from the directory you had it in on your desktop. If you know how to use SCP on OpenWRT ( Linux ) you may use that method here as well. 6 - After you drag and drop new AdGuardHome into the /opt/ directory ( overwriting the old installation ) - then enter these commands : a - # /etc/init.d/AdGuardHome restart b - # /etc/init.d/dnsmasq restart You have now upgraded your AdGuardHome Install on OpenWRT. Peace Stay Safe and God Bless All Always 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. Special thanks to mercygroundabyss for his devotion to this project, his time and patience for all with inquiries, and most of all his kindness and thoroughness in demeanor and practice. 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 : Themes & Skins for "adguard" I use - XENORCHISM 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. As per this example, Full Domain Name in " Customize Settings " Box see below : freedom.babybaby.mywire.org You may then access AdGuardHome WEBGUI on port 443 - here is example from above : https://freedom.babybaby.mywire.org:443 - with Encryption Enabled you will see " green padlock " when logging in / your certificate pulls double duty Here Is What You Get After Install :
  4. Back here one more again - but as you well know, before we can get to the " get-go " - we must indulge ourselves with the time honored tradition of " The Intro " - check out a Soul Classic - https://www.youtube.com/watch?v=9UTqdGZt2_4 and as always lyrics - https://genius.com/Linda-jones-hypnotized-lyrics - and to keep the Groove flowing at the outset - Bounce - https://www.youtube.com/watch?v=CdvITn5cAVc - for the lyrical - https://genius.com/Martha-reeves-and-the-vandellas-dancing-in-the-street-lyrics / OK - now that the foundation has been laid - let us proceed. 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 ". Attention : From OG Poster ( brokenpipe ) !!!! It is possible to install AdguardHome under /opt/, but this directory can grow. Old binaries are moved as backup after an update. blocklists can become relatively large. It is better to move AdGuardHome to a USB stick. So it will survive future OpenWRT updates !!!! That Means Setup Exroot for your AdGuardHome Install If At All Possible Here is a great deal on 4gb USB 3.0 Drives - Made and Shipped In The Good Ole' USA : USB KEYCHAIN KEY DRIVE 3.0 4 GB YO ! : I strongly suggest that you watch this video before you begin. Although lengthy - it is very informative and worthwhile. 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 OpenWRT by the end of this guide / tutorial. The setup uses DNSMASQ. I will write up a guide / tutorial incorporating Unbound with AdGuard Home in a soon to be released tutorial. 1 - First you will need to get the appropriate AdGuard Home package for your router's architecture. For example, I have WRT3200ACM, WRT32x, Wrt1900ACS V2, WRT1200AC, and NightHawk R7800. All of these have ARMv7 processors. You should find out your architecture before proceeding. Now there is a script on AdGuard Home - found here - https://github.com/AdguardTeam/AdGuardHome. However, I have never been able to get the automatic download and install script to work properly. So, I manually download and install AdGuard Home on OpenWRT, because this method is GUARANTEED ! to work. In order to find your router's Architecture - go to Luci > Status > Overview then under System - on the third line down underneath Model ( indicating your router ) You will find your router's Architecture - for the router I am currently running for example these are the entries below : Model Netgear Nighthawk X4S R7800 Architecture ARMv7 Processor rev 0 (v7l) Target Platform ipq806x/generic You can also enter command below : # cat /proc/cpuinfo or you can install hwinfo / opkg update && opkg install hwinfo and issue command below : # hwinfo ### this will render all the specs for your router - look at the beginning of readout for CPU 2 - There are two channels to download AdGuard Home - Beta and Edge. The consensus on the thread - found here: [HowTo] Running Adguard Home on OpenWrt is to run Edge. As I mentioned earlier, make sure that you download the correct AdGuard Home package for your router's processor. In my case that is the following link - https://static.adguard.com/adguardhome/edge/AdGuardHome_linux_armv7.tar.gz - notice that edge is named in the link. A - Just copy and paste your correct link in your browser from this section of AdGuard Home - after downloading - you will have AdGuardHome_linux_armv7.tar.gz on your desktop. Create a folder - and use WinRAR, 7Zip, PeaZip or some such file archiver to unzip AdGuardHome_linux_armv7.tar.gz ( remember to choose the proper package for your router ). You will now have a decompressed folder named " AdGuardHome " . AdguardTeam / AdGuardHome GitHub Home Page Downloads First, Install These Packages To Get Started - The Main One Needed is sudo - otherwise you will not be able to install AdGuardHome successfully - as always # opkg update opkg update ; opkg install ca-certificates ca-bundle sudo libustream-mbedtls libustream-openssl libwolfssl libustream-wolfssl luci-ssl px5g-wolfssl wpad-basic-wolfssl luasocket curl libevent2-7 haveged unzip ip-full curl wget libmbedtls12 tar tcpdump-mini bind-tools 3 - Now we are going to use WINSCP, but first we need to create the default proper directory for AdGuard Home installation. Go into SSH shell - enter command : A - # mkdir -p /opt/ B - After creating directory, fire up WINSCP - open /opt/ directory on the right side of the application - then Drag & Drop the AdGuardHome decompressed folder from the directory you had it in on your desktop. If you know how to use SCP on OpenWRT ( Linux ) you may use that method here as well. After closing WINSCP - then issue this command C - # chmod 755 /opt/AdGuardHome/AdGuardHome ## and then enter next command for installation of AdGuardHome D - # /opt/AdGuardHome/AdGuardHome -s install You should be seeing something like below. 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.11.130:3000 Major Revision To This Guide / Tutorial Rationale For Major Revision To This Guide / Tutorial Read Post # 24 in this thread from mercygroundabyss below : By using AGH on Port 5353 this routing behavior is put into effect : Because you are double looking up ( DNS queries - with AGH on Port 5353 ). By making AGH the primary DNS ( meaning AGH on Port 53 ) AGH looks upstream for whatever provider you set AGH up with (and uses encrypted DNS and DNSSEC), and ( AGH ) looks downstream to DNSMASQ for internal DHCP addresses. By having DNSMASQ on port 53 and AGH on port 5353 you introduce another hop to DNS and repeat effort. Also it doubles the load on your router and increases memory use as DNSMASQ forks for every request. Once again forgive the error and let's move on. E - After installing AdGuardHome, and Prior to Configuring AdGuardHome via WEBGUI we must FIRST set up our router properly for AdGuardHome with DNSMASQ on port 5353 . In order to do so, enter these commands below via SSH : Modified From Mercygroundabyss AGH Installation Script found here : https://tinyurl.com/2p8n9yt8 ## First Move DNSMASQ To Port 5353 - As always you must substitute your actual ## LAN IP Address where you see the one used in this example - i.e. 192.168.11.130 1 - uci set [email protected][0].cachesize='1000' 2 - uci set [email protected][0].noresolv='1' 3 - uci add_list [email protected][-1].server='192.168.11.130' ## Substitute Your Actual LAN IP Address 4 - uci set [email protected][0].port='5353' 5 - uci set [email protected][0].rebind_protection='0' 6 - uci -q delete dhcp.lan.dhcp_option 7 - uci -q delete dhcp.lan.dns 8 - uci add_list dhcp.lan.dhcp_option='6,192.168.11.130' ## DHCP option 6: which DNS (Domain Name Server) ##to include in the IP configuration for name resolution 9 - uci add_list dhcp.lan.dhcp_option='3,192.168.11.130' ##DHCP option 3: default router or last resort gateway for this interface 10 - uci add_list dhcp.lan.dns='::1' #IPv6 Announced DNS 11 - uci set dhcp.lan.leasetime='24h' #24hr DHCP Leases 12 - uci set [email protected][0].dnsforwardmax=1024 ## Stop your network from crashing due to exceeding DNS Queries Limit # Configure DNS provider 13 - uci -q delete network.wan.dns 14 - uci set network.wan.dns='1.1.1.1 1.0.0.1' ## Set WAN IPV4 DNS to Cloudflare # Configure IPv6 DNS provider 15 - uci -q delete network.wan6.dns 16 - uci set network.wan6.dns='2606:4700:4700::1111 2606:4700:4700::1001' ## Set WAN IPV6 DNS to Cloudflare # Disable peer ISP DNS 17 - uci set network.wan.peerdns="0" 18 - uci set network.wan6.peerdns="0" ## Save Changes 19 - uci commit dhcp 20 - uci commit network # Restart Network + DNSMASQ Service to Reflect Changes 21 - /etc/init.d/network restart 22 - /etc/init.d/dnsmasq restart F - Now - we can configure AdGuardHome via WEBGUI. Enter LAN IP Address in your browser in this example it is http://192.168.11.130:3000 as depicted on my initial installation of AGH as shown above. You must choose your LAN Address For Web Interface - Port 8080 - and then Choose LAN Address For DNS - and Leave LAN on Default DNS Port 53 H - Configure AdGuardHome via AdGuardHome.yaml for DNSMASQ We will edit the sections listed below ( a ) upstream_dns: ( b ) bootstrap_dns: ( c ) all_servers: and ( d ) filters: ( e ) dns: ( bind_hosts: EDIT : From mercygroundabyss : Only other gotcha is to manually edit the interfaces (because they will bind to the WAN side for DNS as well - I really should PR that) so manually editing the yaml file once it is up is needed. Enter the command below and edit file as detailed here : # nano /opt/AdGuardHome/AdGuardHome.yaml 1 - Enter the following below ( these entries cover dns: ( bind_hosts: ), upstream_dns, bootstrap_dns and sets AdGuardHome DNS in parallel mode ) web_session_ttl: 720 dns: bind_hosts: - 127.0.0.1 - 192.168.11.130 # enter your LAN IP ADDRESS HERE - ::1 port: 53 upstream_dns: - 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 - 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://fdns1.dismail.de - tls://dns.neutopia.org - tls://dns.digitale-gesellschaft.ch upstream_dns_file: "" bootstrap_dns: - 1.1.1.2 - 1.0.0.2 - 2606:4700:4700::1112 - 2606:4700:4700::1002 all_servers: true If you use Encryption - where you enter your own valid SSL certificates chain for your domain then for bootstrap_dns: entry you may enter something like this below for DOT Bootstrap DNS : 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 Cloudflare Alternative DNS SERVERS Two Flavors: 1.1.1.2 (No Malware) & 1.1.1.3 (No Malware or Adult Content See Here Below : 1.1.1.1 for Families Above Malware Blocking DNS - if you prefer Cloudflare Plain DNS then it is : bootstrap_dns: - 1.1.1.1 - 1.0.0.1 - 2606:4700:4700::1111 - 2606:4700:4700::1001 all_servers: true and for Cloudflare Plain DOT Servers using Encryption - where you enter your own valid SSL certificates chain for your domain bootstrap_dns: - 1.1.1.1:853 - 1.0.0.1:853 - 2606:4700:4700::1111:853 - 2606:4700:4700::1001:853 all_servers: true 2 - Enter the following below for filters 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: [] 3 - From Original Post [HowTo] Running Adguard Home on OpenWrt Adguard Home Regex: Those are really good regex rules which already block 50% of all ads/trackers/bots etc. You have to add the to http://192.168.11.130:8080/#custom_rules ( as per this example - use your actual LAN IP ) https://github.com/mmotti/adguard-home-filters/blob/master/regex.txt Configure Via /opt/AdGuardHome/AdGuardHome.yaml : nano /opt/AdGuardHome/AdGuardHome.yaml user_rules: - https://github.com/mmotti/adguard-home-filters/blob/master/regex.txt dhcp: Special thanks to Mercygroundabyss once again for this information below : The following settings allows AGH to pull client info from OpenWRT's DNSMASQ . Configure Reverse DNS on AGH /opt/AdGuardHome/AdGuardHome.yaml settings for this feature : resolve_clients: true use_private_ptr_resolvers: true local_ptr_upstreams: - 127.0.0.1:5353 After configuring AdGuardHome via AdGuardHome.yaml one or both of the commands below : a - # /etc/init.d/AdGuardHome restart b - # /etc/init.d/dnsmasq restart I - If encryption is enabled, 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 ( 1 ) - enable Encryption - check the Box ( 2 ) - Fill in full server name such as this example - freedom.babybaby.mywire.org from my tutorial below : ( 3 ) Certificates Dynu OpenWRT ACME LET’S ENCRYPT 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 my tutorial above you can issue yourself a LetsEncrypt Certificate cost free.Cross referencing my tutorial above your certificate and key would be the following below : Dynu OpenWRT ACME LET’S ENCRYPT a - /root/.acme.sh/freedom.babybaby.mywire.org/fullchain.cer b - /root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key You have the option to " set the path " ( use a & b above ) or copy and paste them into the appropriate boxes found at the bottom of Encryption settings page. You must move Luci to different port than 443 see commands below : c - # nano /etc/config/uhttpd list listen_https '0.0.0.0:1443' list listen_https '[::]:1443' You may now log into Encrypted AdGuardHome WEB GUI - this option is available by entering the following ( from example above ) : https://freedom.babybaby.mywire.org:443 - with Encryption Enabled you will see " green padlock " when logging in / your certificate pulls double duty. Since you moved OpenWRT Admin Port to Port 1443 you may still log into your Luci Encrypted WEBGUI at : https://freedom.babybaby.mywire.org:1443 In order to get DNSSEC working with AdGuardHome do the following below : Go into AdGuardHome WEBGUI - then Settings > scroll down to DNS server configuration Enable EDNS client subnet and Enable DNSSEC. This is all that is required. Make sure that Upstream DNS Servers in your /opt/AdGuardHome/AdGuardHome.yaml file - ( and /or AdGuardHome WEBGUI ) support DNSSSEC. This is because AdGuardHome piggybacks on configured DNS Servers for DNSSEC Validation. You can test DNSSEC on AdGuardHome by issuing command: ## you need bind-tools installed to run this command dig dnssectest.sidn.nl +dnssec +multi @127.0.0.1 So long as you see in the ;; flags: section the ad; entry = ( meaning Authenticated Data ) you are all set and good to go. See example of AdGuardHome ( proxy-dnssec ) DNSSEC in action below : If you see next to flags: section the ad; entry then you are good to go see below : I was going to tackle Unbound on AdGuardHome here but I think that is best covered in a separate guide. How To Upgrade Your AdGuardHome Install : Some claim that you can upgrade from AdGuardHome WEBGUI - it has never worked for me while running OpenWRT. No need to fear - here is how to upgrade when new EDGE Version pops up. Hopefully, if you initially Setup Exroot for your AdGuardHome Install ( that means on a USB Stick ) then all you have to do is grab the new installation by doing exactly what you did when you first installed AdGuardHome. With Exroot - you do not have to worry about any space issues - this is why we recommend Exroot to begin with. 1 - Download the correct AdGuard Home package for your router's processor. 2 - Create a folder to extract the archive into - and use WinRAR, 7Zip, PeaZip or some such file archiver to unzip AdGuardHome_linux_your_router.tar.gz 3 - You will now have a decompressed folder named " AdGuardHome " . 4 - Then issue this command below : # /etc/init.d/AdGuardHome stop 5 - Fire up WINSCP - open /opt/ directory on the right side of the application - then Drag & Drop the AdGuardHome decompressed folder from the directory you had it in on your desktop. If you know how to use SCP on OpenWRT ( Linux ) you may use that method here as well. 6 - After you drag and drop new AdGuardHome into the /opt/ directory ( overwriting the old installation ) - then enter these commands : a - # /etc/init.d/AdGuardHome restart b - # /etc/init.d/dnsmasq restart You have now upgraded your AdGuardHome Install on OpenWRT. I was going to tackle Unbound on AdGuardHome here but I think that is best covered in a separate guide. Peace Stay Safe and God Bless All Always 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. Special thanks to mercygroundabyss for his devotion to this project, his time and patience for all with inquiries, and most of all his kindness and thoroughness in demeanor and practice. 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 : Themes & Skins for "adguard" I use - XENORCHISM 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. As per this example, Full Domain Name in " Customize Settings " Box see below : freedom.babybaby.mywire.org You may then access AdGuardHome WEBGUI on port 443 - here is example from above : https://freedom.babybaby.mywire.org:443 - with Encryption Enabled you will see " green padlock " when logging in / your certificate pulls double duty Here Is What You Get After Install :
  5. First as all of you just ought to know by now - before we begin - " The Into " - remember to - https://www.youtube.com/watch?v=gnsqvz9iIlA and the lyrics to sing along https://genius.com/Dj-kool-let-me-clear-my-throat-live-lyrics while I take you back and forth https://www.youtube.com/watch?v=krTLRQOOFAw - once again naturally - the lyrics to sing / hum along https://genius.com/Audio-two-top-billin-lyrics Now that the obligatory prerequisites have been satisfied. Let's begin the tutorial. Dynu is far superior to DuckDns - I find that Dynu works first time and every time -- most reliable Cost-Free DDNS Service out there IMHO. OpenWRT DYNU ACME LET'S ENCRYPT - first we have to install DYNU DDNS service before we get down to issuing our certificates. In order to do this - let's get started. 1 - Go to https://www.dynu.com/en-US/ControlPanel/CreateAccount - and create an account - the page is self explanatory. You also have the option to sign up with your Google or Twitter account. Once you have verified your account - Log into your account. Go to > DDNS Services > Click " ADD " > Option 1: Use Our Domain Name From the Drop Down Menu choose a " Top Level " Dynu Domain ( for this example I choose mywire.org ) - enter a hostname - I chose babybaby - click green " ADD " button below - Done. My Dynu domain is now - babybaby.mywire.org Note : some of the domains marked " Members Only are not free - and you must pay for. Now - let's install and configure DDNS. The username is - apple75 and the password is - lebron23 for this fictional account. once you have established your Dynu domain - click on symbol next to " Search " to the right at the top of the page - the click on " API Credentials " - then go to " OAuth2 " - you will see " Client ID: " and " Secret: " - go along that Boxed Column to the right - click on the Binoculars symbol to view these codes - copy and save them for later. Here are my fictional examples below : Client ID: 4cd64505-a7db-4871-8f06-5e61f997d961 Secret: 636g5TbWd3dc43f6b3VV4a444U62af 2 - Set up your router for Dynu DDNS and Let's Encrypt - A- Go to System > Hostname ( enter name of your choice - I am using " freedom " here ) then Network > DHCP and DNS > Local domain ( here enter your Dynu domain which you created earlier - babybaby.mywire.org ( for this example ). Your full domain ( for Let's Encrypt Certificate ) is now - freedom.babybaby.mywire.org . Now, let's set up Dynu DDNS and ACME Let's Encrypt. 3 - Install DDNS and ACME later on - now - first as always - opkg update - then follow below : Dynu DDNS A - opkg update ; opkg install socat ncat luci-app-acme luci-i18n-acme-en acme-dnsapi acme coreutils-stat ddns-scripts luci-app-ddns luci-i18n-ddns-en luci-app-uhttpd uhttpd tcpdump-mini bind-tools drill knot-host bind-host knot-dig haveged B - Dynu DDNS - Dynu DDNS SCRIPT SECTION: I use a script to update Dynu DDNS service. See here : https://www.bytebang.at/Blog/Find+public+IP+address+for+OpenWRT+via+Script# - I have modified the script so it works more reliably. To implement this script, please follow these instructions below: touch /usr/lib/ddns/getPublicIp.sh nano /usr/lib/ddns/getPublicIp.sh enter this script below in the new file : ( url includes Dynu hostname and account password found above ) ## make sure to use Dynu domain only #!/bin/sh # sample script for detecting the public IP wget -q -O - "https://api.dynu.com/nic/update?hostname=babybaby.mywire.org&password=lebron23" then make it executable = chmod 755 /usr/lib/ddns/getPublicIp.sh C - Setup Dynu DDNS Config File - ## Replace The IPV4 Configuration Section With The Contents Below: nano /etc/config/ddns config service 'dynu' option enabled '1' option domain 'babybaby.mywire.org' option username 'apple75' option use_https '1' option cacert '/etc/ssl/certs/ca-certificates.crt' option use_logfile '1' option check_interval '10' option check_unit 'minutes' option force_interval '24' option force_unit 'hours' option ip_source 'script' option retry_interval '60' option retry_unit 'seconds' option ip_script '/usr/lib/ddns/./getPublicIp.sh' option update_url 'https://api.dynu.com/nic/update?hostname=babybaby.mywire.org&password=lebron23' option password 'lebron23' option interface 'WAN' option use_bind_network 'WAN' option force_dnstcp '1' option force_ipversion '1' option service_name 'dynu.com' option lookup_host 'babybaby.mywire.org' Now Start DDNS : run commands ( a -e ) in order as listed below : ( a ) # sh ( b ) # . /usr/lib/ddns/dynamic_dns_functions.sh # note the leading period ( c ) # start_daemon_for_all_ddns_sections "wan" ( d ) # exit ## Very Important To Exit we can now test the script by running the command ( e ) # /usr/lib/ddns/dynamic_dns_updater.sh dynu You may then go to Services > Dynamic DNS > Services and make sure the DDNS Client is running and updated. If not - then do the following as outlined below : ( 1 ) # /usr/lib/ddns/./getPublicIp.sh ( 2) # /etc/init.d/ddns restart # then ( 3 ) go to System > Startup > Restart Your DNS Resolver ( dnsmasq / unbound ) - then restart DDNS Note : In order to issue / renew Let's Encrypt Certificates - disable your VPN ( if running ) - and make sure Port 80 is free / open / unblocked. 4- Now - ACME / Let's Encrypt - A - The packages are already installed. You now need to issue this command below in order to issue your Let's Encrypt Certificate for the full Domain Name which we set up at the beginning - freedom.babybaby.mywire.org - Note - that this includes the hostname which we added on our router. Our Dynu " API Credentials " Fake API Credentials from above - Client ID: 4cd64505-a7db-4871-8f06-5e61f997d961 Secret: 636g5TbWd3dc43f6b3VV4a444U62af see here for ACME on OpenWRT https://github.com/acmesh-official/acme.sh/wiki/How-to-run-on-OpenWRT and here : https://github.com/acmesh-official/acme.sh/wiki/dnsapi scroll down to Section 24. Use Dynu API Issue this command below : # Dynu_ClientId="4cd64505-a7db-4871-8f06-5e61f997d961" Dynu_Secret="636g5TbWd3dc43f6b3VV4a444U62af" /usr/lib/acme/acme.sh --insecure --issue -d freedom.babybaby.mywire.org --keylength 4096 --dns dns_dynu The issuance takes 20 seconds to complete after acme challenge ; when finished You can locate the certificate and key files in /root/.acme.sh/ directory, and then in the uHTTPd settings point the certificate and key path to them respectively This means that the two main files you need are found here : /root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.cer /root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key B - Notice that I set login port is to " 10445 " Now edit /etc/config/uhttpd file thusly as demonstrated below: nano /etc/config/uhttpd config uhttpd 'main' list listen_http '0.0.0.0:80' list listen_http '[::]:80' list listen_https '0.0.0.0:10445' # changed port to 10445 list listen_https '[::]:10445' # changed port to 10445 option redirect_https '1' option home '/www' option max_requests '3' option max_connections '100' option cert '/root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.cer' option key '/root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key' option cgi_prefix '/cgi-bin' list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua' option script_timeout '60' option network_timeout '30' option http_keepalive '20' option tcp_keepalive '1' option ubus_prefix '/ubus' option rfc1918_filter '0' config cert 'defaults' option days '730' option bits '4096' option country 'US' option state 'Texas' option location 'Austin' option commonname 'OpenWrt' ### then issue this command : chmod 400 /root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key At this point DO NOT !! - I REPEAT DO NOT !! - DO NOT RESTART " uhttpd " for any reason whatsoever. Instead clear your browser - close - clean cookies and all that good stuff. Actually after clearing your web browser it is best to reboot your router in order to make sure to that you can login to your router with your new valid certificate. After reboot, open your browser and login with - https://freedom.babybaby.mywire.org:10445 as per this example. You should not be prompted by " insecure warning " any longer - and the green padlock will appear in the address bar. Click on it and see the certificate details if you wish. 5 - NEXT CONFIGURE ACME FOR AUTOMATIC RENEWAL edit /etc/config/acme as below: nano /etc/config/acme config acme option state_dir '/root/.acme.sh/' option account_email '[email protected]' ## Fake E-mail Too option debug '1' config cert 'example' option keylength '4096' option update_uhttpd '1' option enabled '1' option webroot '/www' list domains 'freedom.babybaby.mywire.org' # full router domain for Let's Encrypt option use_staging '0' option dns 'acme.sh --insecure --issue --dns dns_dynu -d freedom.babybaby.mywire.org' # full router domain here too list credentials 'export Dynu_ClientId="4cd64505-a7db-4871-8f06-5e61f997d961"' list credentials 'export Dynu_Secret="636g5TbWd3dc43f6b3VV4a444U62af"' ### Use API Credentials which you used to issue Let's Encrypt Certificate Then issue this command : # /etc/init.d/acme enable - at this point it is best to reboot your router - I have found that if you restart ACME at this point via command line you may unintentionally reissue your Let's Encrypt Certificate - so as I said, REBOOT YOUR ROUTER ! 6 - BONUS : In order to preserve your Let's Encrypt Certificates - use WINSCP and go into default directory. In this case open directory : /root/.acme.sh/freedom.babybaby.mywire.org/ on the right side of the window. You will see all the certificates and associated files. Save them to a folder on your desktop USB or what have you in case you need to upgrade or install new OpenWrt - for instance, HNYMAN ( R7800 ) puts out new SnapShots every 3- 4 days and Divested-WRT ( WRT Series ) puts out new builds every 4 - 5 days. As you know, Let's Encrypt Certificates are good for 90 days and you do not want to abuse this free service. You can reuse them via WINSCP - make sure to create and install them to proper directory on new install as follows- issue command: # mkdir -p /root/.acme.sh/freedom.babybaby.mywire.org/ Then WINSCP the saved Let's Encrypt Files from your previous storage desktop directory or USB into this newly created router directory. That is after you setup Dynu DDNS - installed necessary ACME packages. Do Not create a new certificate as you have a valid certificate which you have saved already. Do not forget this command either: chmod 400 /root/.acme.sh/freedom.babybaby.mywire.org/freedom.babybaby.mywire.org.key Once Again As Stated Above : At this point DO NOT !! - I REPEAT DO NOT !! - DO NOT RESTART " uhttpd " for any reason whatsoever. Instead clear your browser - close - clean cookies and all that good stuff. Actually after clearing your web browser it is best to reboot your router in order to make sure to that you can login to your router with your new valid certificate. After reboot, open your browser and login with - https://freedom.babybaby.mywire.org:10445 as per this example. You should not be prompted by " insecure warning " any longer - and the green padlock will appear in the address bar. Click on it and see the certificate details if you wish. Remember all of this was done using " fictional " hostname, local domain - Dynu API Credentials and so on for illustration purposes only ; however, it does illustrate how to get you going. I find Dynu very easy to implement and manage. I also use Dynu on pfSense and OPNsense. As I said, Let's Encrypt Certificates are valid for 90 days - you may renew after 60 days. You can find your exact expiration date for your certificate by click on the " green padlock " on your router's encrypted login page - https://freedom.babybaby.mywire.org:10445 - In order to renew your OpenWRT Dynu registered Let's Encrypt Certificate do the following A - Setup your DDNS as detailed above ( Step 3 in this tutorial above ) B - WINSCP your current certificates as detailed above C - Setup Let's Encrypt ( Steps 4 & 5 ) above D - Make sure that your VPN is off / disabled - and DDNS address is updated and current E - then issue the command below in order to renew your certificate - # Dynu_ClientId="4cd64505-a7db-4871-8f06-5e61f997d961" Dynu_Secret="636g5TbWd3dc43f6b3VV4a444U62af" /usr/lib/acme/acme.sh --insecure --issue -d freedom.babybaby.mywire.org --keylength 4096 --dns dns_dynu --force --renew You only use the " --force --renew " option on previously issued Let's Encrypt Certificate - otherwise you will receive an error. Peace Stay Safe and Healthy and God Bless All Always
  6. 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: - [email protected] - 0::[email protected] 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: [email protected] forward-addr: 0::[email protected] ################################################## *** 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 !!! XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 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 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 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.
  7. Dear Community, First you all know the drill by now - " The Intro " - a true legend Jackie to all - https://www.youtube.com/watch?v=sBa81YSyshk and the lyrics as always - https://genius.com/Jackie-wilson-baby-workout-lyrics - just for fun - https://www.youtube.com/watch?v=iNLXxDMxe18 - https://genius.com/Chris-montez-lets-dance-lyrics / Surprise Bonus : https://www.youtube.com/watch?v=sIH6s1thcWQ Now with that out of the way. Let's get down to business. I am one of the many who have tried to get WireGuard up and running on pfSense 2.5.2 . Well, I am very pleased to announce that you have come to the right place if you want rock solid WireGuard on pfSense ( finally ). Forget about anything else you may have heard about how to achieve this goal - this is the most simple, direct and effective method you will find. I know - pfsense has WireGuard built in as a package - and there is pfSense-pkg-WireGuard maintained by theonemcdonald. Personally I do not find any of these solutions to be as efficient as the one I will detail here. So - here we go. OK - Here go - let's get down to the business at hand. The first thing we must do is install all the necessary packages for this to work properly. Now you need to know that when you try to view the packages on the FreeBSD servers by way of their url - for example , https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/ - you will get the 403 Forbidden message. There is a remedy / workaround that will allow you to check out exactly what are the most recent package versions for you to install. Go to https://pkgs.org/ - once there - you will see a search box in the upper right hand corner. Just enter the package you wish to find there - then go down to FreeBSD 12 ( the distributions are listed alphabetically - next click on FreeBSD amd64 ( the distro pfSense 2.5.2 is based on ) - finally, go down to the Download section and copy your download url found next to the Binary Package section. 1 - All of the packages that you will need to install are found in the FreeBSD repository. Just install these packages in the order as listed below: A - # pkg add https://mirrors.xtom.nl/freebsd-pkg/FreeBSD%3A12%3Aamd64/quarterly/All/wireguard-kmod-0.0.20211105.pkg B - # pkg add https://mirrors.xtom.nl/freebsd-pkg/FreeBSD%3A12%3Aamd64/quarterly/All/bash-5.1.12.pkg C - # pkg add https://mirrors.xtom.nl/freebsd-pkg/FreeBSD%3A12%3Aamd64/quarterly/All/bash-completion-2.11_1%2C2.pkg D - # pkg add https://mirrors.xtom.nl/freebsd-pkg/FreeBSD%3A12%3Aamd64/quarterly/All/wireguard-tools-1.0.20210914_1.pkg E - # pkg add https://mirrors.xtom.nl/freebsd-pkg/FreeBSD%3A12%3Aamd64/quarterly/All/wireguard-go-0.0.20211016%2C1.pkg F - # pkg add https://mirrors.xtom.nl/freebsd-pkg/FreeBSD%3A12%3Aamd64/quarterly/All/wireguard-2%2C1.pkg 2 - 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 ). Then select " Config Generator " from the drop down menu. From the top line " VPN Tunnel type: " select WireGuard. Go to the next line - " VPN Server Hostname/IP: " choose your desired location. Enter your TorGuard Username and Password. You also have the option to enter your own Local Private-Key and Local Public-Key if you elect to do so. When all of the fields are complete - click on the " Generate Config " box. Download the file to your desired location. Open the numbered config file with a text editor. Your Config file will be like this - see below : ## all the information below is invalid and fictitious for obvious reasons - use your actual file and valid entries to ensure connection. # TorGuard WireGuard Config [Interface] PrivateKey = 0LyqOOa31kblp0mViH+TfwmBT8PIfWXuT9OUa7cvVmo= ListenPort = 51820 DNS = 1.1.1.1 Address = 100.96.0.141/24 [Peer] PublicKey = fmmIzVG3JL1tjDjTIBpE+C5WQbLGCHsdIqQVodQ7yPM= AllowedIPs = 0.0.0.0/0 Endpoint = 23.10.187.115:1443 PersistentKeepalive = 25 3 - Now I used this guide as the template for my manual installation of WIREGUARD on pfSense 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 SSH and issue the commands below- A - # touch /usr/local/etc/wireguard/tunwg0.conf B - # nano /usr/local/etc/wireguard/tunwg0.conf - then enter the contents of your previously downloaded TorGuard WireGuard Config as detailed above. Save and Close. Done with this file. 4 - B - Run command via SSH A - # wg-quick up tunwg0 ( wireguard-go is in package and this action creates wireguard interface ) " tunwg0 " ( tunwgZero ) must be the name of the WireGuard interface otherwise you will have issues You may also run # wireguard-go tunwg0 to create tunwg0 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 : A - # mv /usr/local/etc/rc.d/wireguard /usr/local/etc/rc.d/wireguard.sh / then enter the file - B - # 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 tunwg0 on line 47 : ${wireguard_interfaces=""} to : ${wireguard_interfaces="tunwg0"} ( tunwgZero ) - Save and Close - Make it executable, I run this command - it works for me: C - # chmod 755 /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 it helps to create a boot time start up script for it in /etc/rc.conf.d/. Not to prolong this - do the following : A - # 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 (tunwg0) B - # chmod 755 /etc/rc.conf.d/wireguard / Done with this file. 7 - A - Now head to pfSense WEBGUI in order to configure Wireguard Interface ( created earlier ) and FireWall Rule. First, go along top menu - go to Interfaces > Assignments -choose tunwg0 interface from drop down menu. Click on the + Add Button. The selection will be listed as opt1, opt2 are some similar name depending on the number of your pre-configured lan interfaces. Click underneath opt2 ( in my case ) - then when the page opens up - Enable the new interface. Name the new interface - in my case " WIRE " . DO NOTHING ELSE HERE ! Save and Apply - Done with this phase. B - Second - Firewall Rule - 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 Square with Up Arrow (underneath Mappings ). On the page which opens change Interface from WAN in drop down menu to your Wireguard ( tunwg0 ) Interface which you created and labeled previously - in this example " WIRE " . Next - Change " Address Family " to IPV4 - " Protocol " to " Any " - " Source " to " Any " - " Destination " to " Any " " Translation Address " to " Interface Address " - Lastly enter "Description " in my case " Made For Wire " now Click " Save " at bottom of page. Finally click " Save and Apply " at the top of the page. Your WireGuard Client is now installed and ready - you must enter command # /usr/local/etc/rc.d/wireguard.sh restart in order to start it up. Lastly, issue command # wg show which prints out your WireGuard Connection statistics and configuration. Sample output for wg show below: interface: tunwg0 public key: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA= private key: (hidden) listening port: 51820 peer: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4= endpoint: 159.x.xxx.xxx:xxx allowed ips: 0.0.0.0/0 latest handshake: 1 minute, 46 seconds ago transfer: 3.35 MiB received, 859.23 KiB sent persistent keepalive: every 25 seconds This solution is guaranteed to ensure that WireGuard interface ( tunwg0 ) the ability to survive a reboot When you reboot or reestablish connection - go to Status > Filter Reload - then press Reload Filter Radio Button to get yourself up and running once again.
  8. Dear Community, First you all know the drill by now - " The Intro " - as a peace loving man and in light of the turbulent times we all must endure - here we go without no further ado - Kool and The Gang / https://www.youtube.com/watch?v=JgxWC3iZh7A and the lyrics if you care to sing along - https://genius.com/Kool-and-the-gang-love-and-understanding-lyrics and one of my favorites - The Chambers Brothers - https://www.youtube.com/watch?v=BvCH-6kOAGs - lyrics here : https://genius.com/The-chambers-brothers-love-peace-and-happiness-lyrics This is a new updated guide designed to assist you in installing DNS Privacy DNS OVER TLS on pfSense 2.5.2 . Please disregard and do not use any guides and / or tutorials which predate this one. The setup features getdns and Stubby forwarded to and integrated with Unbound. You may refer to my earlier guide / tutorial here for additional information regarding the benefits of DNS Privacy DNS OVER TLS - see link here - https://bit.ly/3p0AGwX OK - Here go - let's get down to the business at hand. The first thing we must do is install all the necessary packages for this to work properly. Now you need to know that when you try to view the packages on the FreeBSD servers by way of their url - for example , https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/ - you will get the 403 Forbidden message. There is a remedy / workaround that will allow you to check out exactly what are the most recent package versions for you to install. Go to https://pkgs.org/ - once there - you will see a search box in the upper right hand corner. Just enter the package you wish to find there - then go down to FreeBSD 12 ( the distributions are listed alphabetically - next click on FreeBSD amd64 ( the distro pfSense 2.5.2 is based on ) - finally, go down to the Download section and copy your download url found next to the Binary Package section. 1 - There are four dependency packages required before actually installing the getdns package. Two are available in the pfSense package repositories and two from the FreeBSD repository. Lastly the getdns package itself is also in the FreeBSD repository. So to begin enter these commands below in the order : A # pkg install libuv B # pkg install libyaml ( both of these will install from native pfSense 2.5.2 box ) . The following packages must be installed from FreeBSD. C # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/libev-4.33,1.txz D # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/libidn-1.35.txz Now - here is where this guide diverges from its' predecessors. There is a new specific iteration of Unbound which pfSense 2.5.2 has installed. The package is called - unbound112-1.12.0_1 . Now if you attempt to add getdns-1.5.2_4.txz package via pkg add url method - see below : ( # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/getdns-1.5.2_4.txz ) ### this will not work ! the installation will fail and complain that " missing dependency Unbound " is the reason. so here is the solution to that dilemma below : enter the following command E # fetch https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/getdns-1.5.2_4.txz From there you can enter command # ls -a / and you will see that getdns-1.5.2_4.txz package is now in your root directory. Next just enter the command F # pkg install getdns-1.5.2_4.txz follow the prompts answering " yes " to any all. By the way, once this package is successfully installed it must remain in your root directory otherwise DNS OVER TLS will stop working if you remove it for any reason. Now you may proceed as in the usual fashion. 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 755 /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 - Now you must configure Stubby to resolve DNS OVER TLS - A -# nano /usr/local/etc/stubby/stubby.yml ################################################################################ ######################## 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: - [email protected] - 0::[email protected] 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 all. However, these are more than enough to get you started. 4 - In order to have pfSense 2.5.2 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 5- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS. Go to Services > DNS RESOLVER > General Settings > Display Custom Options In the Custom options Box - enter the following below : server: do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] forward-addr: 0::[email protected] Save and Apply 6 - Next -Under System > General Setup > DNS Server Settings A - Set the first DNS Server to 127.0.0.1 add no other DNS Servers here B - DNS Server Override - make sure this is unchecked C - DNS Resolution Behavior Use local DNS (127.0.0.1), fall back to remote DNS SERVERS (Default) 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.
  9. This Is An Updated Guide - February 26, 2021 Dear Community, As always - the intro - https://www.youtube.com/watch?v=6q_Fyv_znkw and lyrics to sing along - https://genius.com/Sly-and-the-family-stone-stand-lyrics Hello and I hope that all are both safe and well. Here I am going to write a new tutorial for OpenWRT Snapshots. Some of you may remember my tutorial below : ( From The DNS Privacy Project ) DNS-OVER-TLS on OpenWrt/LEDE FEATURING UNBOUND GETDNS and STUBBY The main reason for this updated guide for implementing DNS-OVER-TLS on OpenWrt FEATURING UNBOUND GETDNS and STUBBY is due to Unbound 1.13.0-1. Eric Luehrsen - the maintainer for Unbound package on OpenWRT explains the issue here: Need Help With UNBOUND Setup on Snapshots - #30 by directnupe - Basically, in his words: As far as the PEM files, it seems Unbound has a defect with respect to the published behavior. They should be loaded before chroot. That is they are in (real root) /etc/unbound but somewhere in the mess unbound-control is trying /chroot.../etc/unbound. Enable unbound-control only localhost without encryption and it should work. This guide was updated and works on OpenWRT Snapshots, upcoming 21.02 and kernel versions 5.10 in other words this works with Unbound-daemon - 1.13.1-1 ( current version ). As a Bonus - Videos detailing all of this are here - DNSPRIVACY FOR ALL REDEUX The setup video illustrates and details how to install and configure unbound, stubby and getdns along with native dnsmasq to achieve DNS OVER TLS on OpenWRT. So let's get started. Just follow the steps and you can look at the videos as you read this set up guide. Here is the OpenWRT stubby page :https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md When running DNS OVER TLS ( my setup ) - I first had to stop and disable odhcpd This setup depends on DNS functionality. odhcpd conflicts with dnsmasq for dhcp hence also DOT. The commands are as below : /etc/init.d/odhcpd stop /etc/init.d/odhcpd disable Step # 1 - opkg update && opkg install wget nano ca-bundle ca-certificates ( these are prerequisites - especially ca-bundle ) Step # 2 - opkg update ; opkg install unbound-daemon unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host stubby getdns unbound-checkconf odhcpd ( this installs unbound and stubby dependencies ) Step # 3 - By default, configuration of stubby is integrated with the OpenWRT UCI system using the file /etc/config/stubby. We wish to configure stubby using the /etc/stubby/stubby.yml file. We need to set option manual '1' in /etc/config/stubby and all other settings in /etc/config/stubby will be ignored. See below for correct entry ( nano /etc/config/stubby 😞 config stubby 'global' option manual '1' Step # 4 - Configure stubby.yml - enter nano /etc/stubby/stubby.yml see how below : Please use as many or as few upstream servers as you deem necessary or desired for our needs. I have shown file to use both IPV4 and IPV6 servers. All servers support TLSv1.3 protocol. Pick those closet to you geographically and so forth. # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 10000 listen_addresses: - [email protected] - 0::[email protected] dns_transport_list: - GETDNS_TRANSPORT_TLS tls_connection_retries: 5 tls_backoff_time: 300 timeout: 1000 limit_outstanding_queries: 100 tls_ca_file: "/etc/ssl/certs/ca-certificates.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 Servers #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= ## xx - 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= ## xx - 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= ## 3 - 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= ## 4 - 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: G69vD32lVULKRAA1Mey0aY5HqCtixfcFj6d7YfZXcXQ= ## xx - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU ) - address_data: 78.46.244.143 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: MYAdUawDyym0aCys3RM7wjnGt6/VPkXRSnUynBVCZ0M= ## xx - 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= ## xx - 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= ## xx - The BlahDNS Switzerland DNS TLS Server A+ ( CHE ) - address_data: 45.90.57.121 tls_auth_name: "dot-ch.blahdns.com" tls_port: 4443 tls_pubkey_pinset: - digest: "sha256" value: 0i6NHVbpWtZUAxlyKkIPo3xwYQPdwcDYMmZmOvQSBd8= ## 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 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: wi251KSU9HwFOjL3cgG+vxxyrQl0FyP5aBkBcqs4dow= ## 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: l58wGW4rA4vpqbwyQkBK+TC8nWT7ESkMnn1aG3ehbFc= ## 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: 89.217.74.236 tls_auth_name: "ibksturm.synology.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: ST64ZkZeik0+6/e9gCs+dGB5r4lEMWcgxg58eBhQGDY= ## 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: bCliMm8V6PPPhy3qOG45fkJhqJZ/H7HQH3GF3RHP2sg= ### Publicly Available DOT Test Servers ### ## 12 - 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= ## 13 - 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: TP3QdfiIGmReSKJ3XW+T+yQ+xy5KMNtcTt6TJ+MMynI= ## 14 - 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: ynHdh6Gn21nGQDVYEz0eYp8rktzwbAmSJgncIEk4yTI= ## 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: 3sSy32B+XnIOKckcW9vT06D0+XUgW3CSno+p1k3vp9Y= ## 15 - 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: y8hXAlkRxglOPlYivo/S/E1EfNFoU9f/Uf4dQcXiHhg= ## 16 - 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: A0Te9x7eWRcFvhbIVMSuJJV6tr4ABUnGEKBm+FyaknQ= ## xx - 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: XToXSSeTAIsKEZ4+KjhlWla0LtOFwI90J5nnOAY6dcE= ## 17 - 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: s2bFv4zDfIc+7wIMA59QTImqx9uzko6TQVfXAz8JLto= ## 18 - 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: UV439TTY3wPh+k2bKJmvHrU3gcz4bDYd6S0poXN7bZU= ## xx - 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: YhPROg0ogwGqlsQAehkkxQk8lMUNUVJiR04c/rO2Pdo= ## 19 - The ibuki.cgnat.net DNS TLS Server A+ ( USA ) - address_data: 168.138.243.216 tls_auth_name: "ibuki.cgnat.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: UVKs87p2i+i+6cTOsfmZWHpononMhaZ1/TaOUCCdEYA= ## 20 - The AhaDNS.com Netherlands DNS TLS Server A+ ( NLD ) - address_data: 5.2.75.75 - address_data: 2a04:52c0:101:75::75 tls_auth_name: "dot.nl.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: vhyny5bRLcdUo8nT8yYPU3Ba3n59tw/p9ZdM7CdB7XA= ## xx - The AhaDNS.com India DNS TLS Server A+ ( IND ) - address_data: 45.79.120.233 tls_auth_name: "dot.in.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: I2d/sF4W9UzEJDacfEioGpjzfdKfA9vScD27fL+X7y4= ## xx - The AhaDNS.com Los Angeles DNS TLS Server A+ ( USA ) - address_data: 45.67.219.208 - address_data: 2a04:bdc7:100:70::70 tls_auth_name: "dot.la.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: I8+ilcgZbzlDJibVX+ao3N4CaN71oi/67kARvAvkF68= ## xx - The AhaDNS.com New York DNS TLS Server A+ ( USA ) - address_data: 185.213.26.187 tls_auth_name: "dot.ny.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: KFnD8W9moK59GXrouEF2PRnD3TI5dwNerLGz2fVGUg4= ## xx - The AhaDNS.com Poland DNS TLS Server A+ ( IND ) - address_data: 45.132.75.16 - address_data: 2a0e:dc0:7:d::d tls_auth_name: "dot.pl.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: k+2Qzo5pl+70VXixFeBNRswWwdwAu/hC6gNdFytr2Bw= ## xx - The AhaDNS.com Italy DNS TLS Server A+ ( IND ) - address_data: 45.91.95.12 - address_data: 2a0e:dc0:8:12::12 tls_auth_name: "dot.it.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: XOAIkTcSr/sm3w8JalaSP9apN7visaVWJ7Ak6SnwFBg= ## xx - The AhaDNS.com Spain DNS TLS Server A+ ( IND ) - address_data: 45.132.74.167 - address_data: 2a0e:dc0:9:17::17 tls_auth_name: "dot.es.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: MfhmtxPms+ZsB7v5iLdmGgoIYCDkxs55DTiY1p/+OcU= ## xx - The AhaDNS.com Norway DNS TLS Server A+ ( IND ) - address_data: 185.175.56.133 - address_data: 2a0d:5600:30:28::28 tls_auth_name: "dot.no.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P++7ZdWm1d+diD5Qt9PV7SFQDCrZK/jH8mo9G1xF8nc= ## xx - The AhaDNS.com Chicago DNS TLS Server A+ ( IND ) - address_data: 193.29.62.196 - address_data: 2605:4840:3:c4::c4 tls_auth_name: "dot.chi.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: UF0rIyP2tkD8NG4FEZ/NDFu16vkXVNV4Jg4yml5oRfk= ## xx - The AhaDNS.com Australia DNS TLS Server A+ ( IND ) - address_data: 103.73.64.132 - address_data: 2406:ef80:100:11::11 tls_auth_name: "dot.au.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: WULSbPGl4Jckg99ATU12Hp+aVdLz5H3ltu9g5cBU9q4= ## 21 - 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: PNeoThB4S+lf+p/ZkXZZqjWmUn13lu809xuDgBZ+xp8= ## 22 - 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: Cv0Ap5Pf5+ZP0JxsBIm5xsnNmIK0YameM8QDWg4VKR0= ## 23 - 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: sYtspi4dALWTVbMppLGpjFDQvCEZeuabtXyoGo/Q3ng= ## 24 - 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= ## xx - 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= ## 25 - The Freifunk München DNS TLS Server A+ ( DEU ) - address_data: 5.1.66.255 tls_auth_name: "doh.ffmuc.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: BkjoiHvX67yHa/G2NNPi5G4WAN5Wh3fjIO3CRPqPYJA= - address_data: 185.150.99.255 tls_auth_name: "doh.ffmuc.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P77Y2o4+q8v3l8Qq7M8fre0S0buvRG5gYKhM94YJEHU= ## 26 - 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= ## 27 - 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= ## 28 - 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= ## 29 - 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= ## 30 - 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= ## xx - 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= ## 31 - The LavaDNS-US-1 DNS TLS Server A+ ( USA ) - address_data: 79.110.170.43 tls_auth_name: "us1.dns.lavate.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: W0y9+3Qy77HrkCYLNSg0oY2J7aIqwC5GbPEP6pBTfws= ## xx - The LavaDNS-EU-1 DNS TLS Server A+ ( FIN ) - address_data: 95.217.25.217 tls_auth_name: "eu1.dns.lavate.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: WSQmsUvZJRZ5EcIyZdtqt1UsB1KEeAX8+cFy/v7AiCk= ## 32 - The yepdns.com DNS TLS Server #1 A+ ( USA ) - address_data: 94.237.68.80 tls_port: 853 tls_auth_name: "sg.yepdns.com" tls_pubkey_pinset: - digest: "sha256" value: m+Gh4LlejsfHgD3yOg4QIUc2VcfP9ukrq7AR0WQd7q0= ## 33 - The Faelix DNS TLS Server #1 A+ ( LTU ) - address_data: 185.134.196.54 tls_auth_name: "rdns.faelix.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g= ## xx - The Faelix DNS TLS Server #2 A+ ( LTU ) - address_data: 185.134.196.55 tls_auth_name: "rdns.faelix.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g= ## xx - The Faelix DNS TLS Server #3 A+ ( LTU ) - address_data: 46.227.200.55 tls_auth_name: "rdns.faelix.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g= ## xx - The Faelix DNS TLS Server #4 A+ ( LTU ) - address_data: 46.227.200.54 tls_auth_name: "rdns.faelix.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g= ## 34 - The Arapurayil's DNS TLS Server #1 A+ ( USA ) - address_data: 3.7.176.123 tls_port: 853 tls_auth_name: "dns.arapurayil.com" tls_pubkey_pinset: - digest: "sha256" value: fod+JGyXcnJBDOrt1Iq14abGcxgNjh2zFVOO8saHnBM= ## 35 - The Brahma World DNS TLS Server A+ ( USA ) - address_data: 94.237.80.211 tls_port: 853 tls_auth_name: "dns.brahma.world" tls_pubkey_pinset: - digest: "sha256" value: gJR4ekQiIPT5+ug7Rzxr+9O9sKLkTgKS8Lam5EXncEU= ## 36 - The Uncensored DNS TLS Server #1 A+ ( DNK ) - address_data: 91.239.100.100 tls_auth_name: "anycast.censurfridns.dk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 6eW98h0+xxuaGQkgNalEU5e/hbgKyUoydpPMY6xcKyY= ## xx - The Uncensored DNS TLS Server #2 A+ ( DNK ) - address_data: 89.233.43.71 tls_auth_name: "unicast.censurfridns.dk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: INSZEZpDoWKiavosV2/xVT8O83vk/RRwS+LTiL+IpHs= ## 37 - The Digitalcourage e.V. DNS TLS Server A+ ( DEU ) - address_data: 46.182.19.48 tls_auth_name: "dns2.digitalcourage.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: v7rm6OtQQD3x/wbsdHDZjiDg+utMZvnoX3jq3Vi8tGU= ## 38 - The Usable Privacy DNS DNS TLS Server A+ ( CHE ) - address_data: 149.154.153.153 tls_auth_name: "adfree.usableprivacy.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: SQjhS4EtweDmR5+NMLGMVXxYP8ZwGVa1YDSoM8N5wiU= ## 39 - The Hostux DNS TLS Server A+ ( LUX ) - address_data: 185.26.126.37 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= - address_data: 185.26.126.14 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= ## 40 - The dns.therifleman.name DNS TLS Servers A+ ( USA ) - address_data: 172.104.206.174 tls_auth_name: "dns.therifleman.name" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: mZJECUWOKQW4SAvZSgM3LRalJQDUCxtImKW0KO/+ijU= ### Anycast Publicly Available DOT Test Servers ### ## 41 - The DNSlify DNS TLS Servers A+ ( Anycast ) - address_data: 185.235.81.1 tls_auth_name: "a.ns.dnslify.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QZKcLeM+e5+3DYMrpNYv/iRMtNbRtvN8dCmWbBZFT68= - address_data: 185.235.81.2 tls_auth_name: "b.ns.dnslify.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QZKcLeM+e5+3DYMrpNYv/iRMtNbRtvN8dCmWbBZFT68= ### DNS Privacy Anycast DOT Public Resolvers ### ## 42 - 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= ## 43 - The DNSPod DNS TLS Server #1 A+ ( Anycast ) - address_data: 162.14.21.178 tls_port: 853 tls_auth_name: "dns.pub" tls_pubkey_pinset: - digest: "sha256" value: Q1JRqG379NbZYD6KcA+jl8co9wuQNhg/YmN4dLImQpM= ## xx - The DNSPod DNS TLS Server #2 A+ ( Anycast ) - address_data: 162.14.21.56 tls_port: 853 tls_auth_name: "doh.pub" tls_pubkey_pinset: - digest: "sha256" value: Q1JRqG379NbZYD6KcA+jl8co9wuQNhg/YmN4dLImQpM= ####### Servers that listen on port 443 (IPv4 and IPv6) ####### ### Test servers ### ## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD ) - address_data: 2a04:b900:0:100::38 tls_auth_name: "getdnsapi.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= ## xx - The The Surfnet/Sinodun DNS TLS Server #1 A ( NLD ) - 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= - 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= ## 2 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 2a02:1b8:10:234::2 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: wi251KSU9HwFOjL3cgG+vxxyrQl0FyP5aBkBcqs4dow= ## 3 - The AhaDNS.com New York DNS TLS Server A+ ( USA ) - address_data: 2a0d:5600:33:3::3 tls_auth_name: "dot.ny.ahadns.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: KFnD8W9moK59GXrouEF2PRnD3TI5dwNerLGz2fVGUg4= # 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 Step # 5 - This step tells Stubby to forward all DNS requests to Unbound : cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF server: do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] forward-addr: 0::[email protected] UNBOUND_FORWARD_CONF Step # 6 - Now, you just need to move the existing dnsmasq server aside, so Unbound can answer your devices DNS queries. Issue commands (a) through (e) as detailed below : # Move dnsmasq to port 53535 where it will still serve local DNS from DHCP # Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535 ( a ) uci set '[email protected][0].port=53535' # Configure dnsmasq to send a DNS Server DHCP option with its LAN IP # since it does not do this by default when port is configured. ( b ) uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)" ( c ) uci set '[email protected][0].dhcp_link=dnsmasq' # Save & Apply (will restart dnsmasq, DNS unreachable until unbound is up) (d ) uci commit # Restart (or start) unbound (System -> Startup -> unbound -> Restart) ( e ) /etc/init.d/unbound restart Step # 7 - Set dnsmasq to send DNS requests to stubby Since dnsmasq now responds to LAN DNS requests on port 53535 of the OpenWRT device, all that is required is to have dnsmasq forward those requests to stubby which is listening on port 5453 of the OpenWRT device. To achieve this, we need to set the server option in the dnsmasq configuration in the /etc/config/dhcp file to '127.0.0.1#5453'. We also need to tell dnsmasq not to use resolvers found in /etc/resolv.conf by setting the dnsmasq option noresolv to 1 in the same file. This can be achieved by editing the /etc/config/dhcp file directly or executing the following commands - ( a ) - ( e ) at the command line: ( a ) - uci add_list [email protected][-1].server='/pool.ntp.org/129.6.15.30' ( b ) - uci add_list [email protected][-1].server='127.0.0.1#5453' ( c ) - uci add_list [email protected][-1].server='0::1#5453' ( d ) - uci set [email protected][-1].noresolv=1 ( e ) - uci commit && reload_config Step # 8 - Disable sending DNS requests to ISP provided DNS servers ( a ) - uci set network.wan.peerdns='0' ( b ) - uci set network.wan.dns='127.0.0.1' ( c ) - uci set network.wan6.peerdns='0' ( d ) - uci set network.wan6.dns='0::1' ( e ) - uci commit && reload_config Step # 9 - Shrink Dnsmasq cache as we use Unbound and increase forwards Issue commands ( a ) - ( c ) below : ( a ) - uci set [email protected][0].cachesize=50 ( b ) - uci set [email protected][0].dnsforwardmax=250 ( c ) - uci commit dhcp && reload_config Step # 10 - ( Optional ) - Edit Startup Services nano /etc/rc.local - and enter the following below : # Put your custom commands here that should be executed once # the system init finished. By default this file does nothing. /usr/sbin/ntpd -n -q -N -p 129.6.15.30 # Wait until Internet connection is available for i in {1..60}; do ping -c1 -W1 185.49.141.37 &> /dev/null && break; done # Restart DNS Privacy Daemon - Stubby as it requires a successful #time sync for its encryption to work/ /etc/init.d/network restart /etc/init.d/firewall restart /etc/init.d/unbound restart /etc/init.d/stubby restart /usr/sbin/ntpd -n -q -N -p 129.6.15.30 exit 0 Step # 11 - Configure Unbound via configuration file - replace contents of file with the following - see below : nano /etc/config/unbound config unbound 'ub_main' option add_extra_dns '0' option add_local_fqdn '1' option add_wan_fqdn '0' option dhcp4_slaac6 '0' option dns64 '0' option dns64_prefix '64:ff9b::/96' option domain 'mydomain.com' ## enter your actual domain here option domain_type 'transparent' option edns_size '1232' option extended_stats '1' option hide_binddata '1' option interface_auto '1' option extended_luci '1' option luci_expanded '1' option listen_port '53' option localservice '1' option manual_conf '0' option num_threads '2' option protocol 'mixed' option query_minimize '1' option query_min_strict '1' option rate_limit '0' option rebind_localhost '0' option rebind_protection '1' option recursion 'aggressive' option resource 'medium' option root_age '9' option ttl_min '120' option unbound_control '1' option validator '1' option validator_ntp '1' option verbosity '1' list trigger_interface 'lan' list trigger_interface 'wan' option query_minimize '1' list domain_insecure '3.us.pool.ntp.org' list domain_insecure 'mydomain.com' ## enter your actual domain here option dhcp_link 'dnsmasq' Step # 12 - Manually edit /etc/config/dhcp - go into nano /etc/config/dhcp and do the following below : A - ## --- Make sure you disable (apply "#" in front) this entry to ignore ISP's supplied DNS done by doing as detailed directly below: # option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto' B - ## --- Your router date & time must be correct in order to have successful tls initiation done by doing as detailed directly below: list server '/pool.ntp.org/129.6.15.30' ( Make sure this entry was added in Step # 7 via uci ) Step # 13 - Check your Unbound Configuration - enter command # unbound-checkconf Checks unbound config file syntax and other errors. Step # 14 - Setup Unbound Files For Unbound Control - enter command # unbound-control-setup Generates self-signed certification and private keys for both server and client. Step # 15 - Enable and Update DNSSEC - enter command # unbound-anchor -a "/etc/unbound/root.key" Performs the configuration or update of the root trust anchor for DNSSEC validation. Step # 16 - Reboot your router Step # 17 - Go to https://browserleaks.com/dns - and you will see that you are now You are now running DNS OVER TLS with GETDNS plus STUBBY ( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server. 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. I am being constantly asked why did I go through all the trouble of setting up this " so called elaborate " configuration of a DNS solution - namely DNS OVER TLS ( DOT ). Among the many contributors to this project are Sinodun IT, NLnet Labs, SalesForce, Surftnet, NLnet Foundation, OTF, Stephane Bortzmeyer and No Mountain Software. The answers ( s ) are rattled off below : Unbound - Unbound 1 Stichting NLnet Labs Science Park 400, 1098 XH Amsterdam, The Netherlands To help increase online privacy, Unbound supports DNS-over-TLS and DNS-over-HTTPS which allows clients to encrypt their communication. In addition, it supports various modern standards that limit the amount of data exchanged with authoritative servers. These standards do not only improve privacy but also help making the DNS more robust. The most important are Query Name Minimisation, the Aggressive Use of DNSSEC-Validated Cache and support for authority zones, which can be used to load a copy of the root zone. Stubby - Stubby About Stubby 'Stubby' is an application that acts as a local DNS Privacy stub resolver (using DNS-over-TLS). Stubby encrypts DNS queries sent from a client machine (desktop or laptop) to a DNS Privacy resolver increasing end user privacy. Stubby is developed by the getdns project, has it's own github repo and issue tracker but dnsprivacy.org currently hosts the online documentation for Stubby . Welcome to the DNS Privacy project home page DNS Privacy Project This site is the home of a collaborative open project to promote, implement and deploy DNS Privacy. The goals of this project include:Raising awareness of the issue of DNS Privacy. Empowering users to take advantage of DNS Privacy tools and resources (client applications, DNS Privacy resolvers) Evolving the DNS to support DNS Privacy in particular developing new DNS Protocol standards Working towards full support for DNS Privacy in a range of Open Source DNS implementations including: getdns, Unbound, NSD, BIND and Knot (Auth and Resolver) Co-ordinating deployment of DNS Privacy services and documenting operational practices getdns - getdns 1 getdns is a modern asynchronous DNS API. It implements DNS entry points from a design developed and vetted by application developers, in an API specification. The open source C implementation of getdns is developed and maintained in collaboration by NLnet Labs, Sinodun and No Mountain Software. This implementation is licensed under the New BSD License. So - Stichting NLnet Labs develops and maintains Unbound, getdns and Stubby. This company sets the industry's " Gold Standard ". I use pfSense and Opnsense - I am used to Unbound. I used to run dnscrypt years ago - but then I upped my game and moved on DNS OVER TLS - DOT. Plain and simple. Once again - anyone with questions about the various DNS solutions available today should read : DNS Security: Threat Modeling DNSSEC, DoT, and DoH 2 along with my original tutorial on this topic written a while back. And by all means go with your own preference. I hope this puts this issue to rest. Again, this takes 6 to 10 ten minutes to set up. Plus I have given any and all videos to follow. These standards and products are reviewed, standardized, continually developed and constantly improved. Peace and God Bless - Stay Safe
  10. Was looking to find the best balanced settings for Torguard providing the most security with only a reasonable hit to throughput but could not find much details online. I decided to run some throughput tests on a few combinations of settings to determine the best option. The tests were done using speedtest.net using the same fixed remote server for all tests. In Torguard using the pin feature, I also fixed the VPN server IP for all tests. Throughput obviously varied based on server/ISP load but not by much. Also any test combinations where the numbers seemed to not make sense, I verified by doing the test again. Fixed Variables - Software Version - v3.90.0 - Used OpenVPN. I did test with OpenConnect with not much difference in speed and from the research so far OpenVPN is a more secure reliable option as of now. - Used UDP. TCP was about 40% slower than UDP and for general PC use losing a few packets has almost no noticeable effect. - Port - 1195 (SHA 256) - All other settings excluding the configuration changes listed below in the test were at default values. - Tests were done in order of security level (low to high) starting with Torguard completely disabled. Test Results Encryption Network Settings DL (Mbps) Loss Torguard Disabled Torguard Disabled 193 0% AES-128-CBC Default 164 15% AES-128-GCM Default 166 16% AES-256-CBC Default 160 20% AES-256-GCM Default 155 24% AES-256-CBC Block Outside DNS = On Name Server = None 163 19% AES-256-GCM Block Outside DNS = On Name Server = None 176 10% AES-256-CBC Block Outside DNS = On Name Server = VPN DNS 161 18% AES-256-GCM Block Outside DNS = On Name Server = VPN DNS 175 11% AES-256-CBC Block Outside DNS = On Name Server = Google 163 17% AES-256-GCM Block Outside DNS = On Name Server = Google 163 18% AES-256-CBC Block Outside DNS = Off Name Server = VPN DNS 164 18% AES-256-GCM Block Outside DNS = Off Name Server = VPN DNS 164 18% Summary -Using AES-256 vs AES-128 showed minor drop in throughput. -Adding the extra layers of security under DNS to prevent DNS resolve leaks had no negative impact on throughput. -Surprisingly after multiple repeat tests AES GCM (more secure) seems to provide better results using some of the DNS settings. Again there are obviously alot of other variables that would have impacted some of the results so they cannot be 100% accurate. It is also a limited test only taking 2 servers in to account but it does give a decent general idea as to what the best balanced options would be. Based on this test, the last configuration (in green) is the most secure option with a low amount of loss in throughput. Hope this helps any questions or corrections let me know.
  11. Dear TorGuard Pfsense WireGuard Users, Please Read The Entire Guide / Tutorial Before You Begin - It Will Save You Potential Setup Issues and Detail All Setup Options First you all know the drill by now - " The Intro " to pay homage to an all time oft forgotten Stax Great who speaks my mind right about now / lyrics - https://genius.com/Otis-redding-respect-lyrics and video : https://www.youtube.com/watch?v=7BDw-H_hUzw - and Nina Simone to boot : lyrics : https://genius.com/Nina-simone-mississippi-goddam-lyrics and video : https://www.youtube.com/watch?v=LJ25-U3jNWM Hello and I hope all are safe and well. Ascrod has been kind enough to make available a package for WireGuard on pfsense. I have tested the package and would like to recommend this to all of those who might be interested. The package thread and discussion are found here : https://forum.netgate.com/topic/150943/i-made-a-wireguard-package-for-pfsense and here on Github : https://github.com/Ascrod/pfSense-pkg-wireguard Here are Ascrod assets in releases on github : https://github.com/Ascrod/pfSense-pkg-wireguard/releases There is a webgui for WireGuard and it works well.The package works very well on pfsense 2.4.5. I was finally able to build my own Lucasnz pfsense 2.5.0 package successfully - and it worked as intended. Read the update for pfsense 2.5.0 pfSense-pkg-wireguard below. There also is a fork of this pfsense package developed by Ashus / pfSense-pkg-wireguard found here : https://github.com/Ashus/pfSense-pkg-wireguard Lucasnz see here for homepage : https://github.com/lucasnz/pfSense-pkg-wireguard lucasnz/pfSense-pkg-wireguard forked from Ascrod/pfSense-pkg-wireguard Here are Lucasnz assets in releases on github : https://github.com/lucasnz/pfSense-pkg-wireguard/releases/tag/v1.0.1 Please Note He Has Only One Package Which Is For pfSense 2.4.5 . If you want Lucasnz for pfSense 2.5.0 then you may either use the pre-compiled package I offer up here or build your own by following the tutorial provided below. For those interested - I have one link to a tutorial and another which points you to an already compiled Lucasnz package for pfsense 2.5.0 - which is based on FreeBSD 12. The tutorial illustrates and instructs you how to build your own Lucasnz pfSense-pkg-wireguard-1.0.1.txz package. The reason that I chose Lucasnz is because " that it just works ". Lucasnz WireGuard for pfsense survives reboots, upgrades - and has no issues with DNS or any such other related problems. The links are here below for all those interested : https://drive.google.com/file/d/1b8coPZvqmhisHpoFBfOBV9BYaH917yaC/view?usp=sharing / tutorial link https://drive.google.com/file/d/1SaggDk6-1BOwcSa4-498jQfGZICqqvsb/view?usp=sharing / package download These really work well IMHO - so I hope this helps and a word to the wise should be sufficient. I am going to try to get Ashus / pfSense-pkg-wireguard to work on pfsense 2.5.0 and I will report my findings. UPDATE BELOW : Well, I got in touch with Ashus - and he was kind enough to build and compile a " proper and official " pfSense-pkg-wireguard-1.0.1-freebsd12-amd64.txz ( this is the package needed for pfsense 2.5.0 ) . Here are Ashus assets in releases on github : https://github.com/Ashus/pfSense-pkg-wireguard/releases by using Ashus packages you can either install pfSense-pkg-wireguard-1.0.1-freebsd11-amd64.txz ( for pfsense 2.4.5 / based on FreeBsd 11 ) or use his new pfSense-pkg-wireguard-1.0.1-freebsd12-amd64.txz ( for pfsense 2.5.0 -devel - based on FreeBsd 12 ) . Always check https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/ or https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/ for the latest packages in the FreeBsd Repo depending on your architecture - especially as bash, wireguard-go, and wireguard packages are updated periodically. I have found as of late that if you try to access the main FreeBSD repo by entering the " https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/ " url - you will get the " 403 Forbidden - nginx error ". This precludes you from viewing the current FreeBSD package list. I searched around and found a FreeBSD package repo that seems to be up and stable - it is " http://pkg0.jinx.freebsd.org/FreeBSD:12:amd64/latest/All/ " or http://pkg0.jinx.freebsd.org/FreeBSD:11:amd64/latest/All/ which is located in South Africa. Virtually all of the FreeBSD package repos are inaccessible as well. Oddly, enough you are still able to download the FreeBSD packages from the main repo - it is just that you can not see the repo packages ( to check package latest versions by entering the url ). With that being said - let's proceed. the complete needed software installation is outlined like this here - see below : Use Putty or Kitty to enter an SSH session on your pfsense router in order to proceed : Or Use FreeBsd Mirror - http://pkg0.jinx.freebsd.org/FreeBSD:12:amd64/latest/All/ These packages indicated below are correct and updated as of 10/19/2020 / always remember check FreeBSD package repo for latest dependency packages The procedure detailed below is for pfsense 2.5.0 / FreeBsd 12 : Best To Use FreeBsd Mirror - http://pkg0.jinx.freebsd.org/FreeBSD:12:amd64/latest/All/ 1. pkg add http://pkg0.jinx.freebsd.org/FreeBSD:12:amd64/latest/All/bash-5.0.18_3.txz 2. (opt.) pkg add http://pkg0.jinx.freebsd.org/FreeBSD:12:amd64/latest/All/bash-completion-2.11,2.txz 3. pkg add http://pkg0.jinx.freebsd.org/FreeBSD:12:amd64/latest/All/wireguard-go-0.0.20200320.txz 4. pkg add http://pkg0.jinx.freebsd.org/FreeBSD:12:amd64/latest/All/wireguard-1.0.20200827.txz 5. pkg add https://github.com/Ashus/pfSense-pkg-wireguard/releases/download/v1.0.1b/pfSense-pkg-wireguard-1.0.1-freebsd12-amd64.txz Best To Use FreeBsd Mirror - http://pkg0.jinx.freebsd.org/FreeBSD:11:amd64/latest/All/ This procedure detailed below is for pfsense 2.4.5 / FreeBsd 11 : 1. pkg add http://pkg0.jinx.freebsd.org/FreeBSD:11:amd64/latest/All/bash-5.0.18_3.txz 2. (opt.) pkg add http://pkg0.jinx.freebsd.org/FreeBSD:11:amd64/latest/All/bash-completion-2.11,2.txz 3. pkg add http://pkg0.jinx.freebsd.org/FreeBSD:11:amd64/latest/All/wireguard-go-0.0.20200320.txz 4. pkg add http://pkg0.jinx.freebsd.org/FreeBSD:11:amd64/latest/All/wireguard-1.0.20200827.txz 5. pkg add https://github.com/Ashus/pfSense-pkg-wireguard/releases/download/v1.0.1b/pfSense-pkg-wireguard-1.0.1-freebsd11-amd64.txz Please Note and Understand : I strongly recommend using Lucasnz pfSense-pkg-wireguard-1.0.1.txz package for the reasons detailed above. For pfSense 2.4.5 ( Based on FreeBsd 11 ) in step # 5 substitute the line below : 5. pkg add https://github.com/lucasnz/pfSense-pkg-wireguard/releases/download/v1.0.1/pfSense-pkg-wireguard-1.0.1-freebsd11-amd64.txz For Lucasnz for pfSense 2.5.0 ( Based on FreeBsd 12 ) - 1 - Download the already compiled Lucasnz pfSense-pkg-wireguard-1.0.1.txz package above ( or build your own from tutorial above ) to usb drive or desktop folder where you can find this later. 2 - Next fire up your pfSense 2.5.0 router. WinSCP ( scp protocol ) into your 2.5.0 router and transfer ( drag and drop ) the Lucasnz pfSense-pkg-wireguard-1.0.1.txz from the local directory you exported it to earlier ( in this case on my Windows 10 machine ) into the /root directory of your pfSense 2.5.0 router. 3 - Finally, for pfSense 2.5.0 in step # 5 substitute the line below : 5. pkg add pfSense-pkg-wireguard-1.0.1.txz ( Use / substitute your WinSCP transferred package here ) You can also try Ascrod's Wireguard package but this is described in detail in the first link above. Ashus has more features - you can read the documentation for each and make your decision. These are Ashus' Wireguard setup directions below : Configuration Configure an interface and any number of peers. Then go to the Assign Interfaces screen and create a new interface for tunwg0. Name it, enable it, and don't touch any other settings. Once the interface is up, you can create firewall rules for it, forward ports to it, and generally treat it the same as a physical interface. It should also persist across reboots. If there is a need for more interfaces, add the tunwg1.conf or more files with incremental interface number to /usr/local/etc/wireguard/. Unfortunately those cannot be currently edited via GUI, and everytime you add more, you need to reinstall this package or wireguard service. Each time the service is reinstalled, all tunnels are detected from files again, so they could persist across reboots and could be reloaded from GUI all at once. For help with configuring WireGuard, please read the official documentation . The unofficial documentation and examples may also be helpful. 1 - You must fill in your TorGuard WirGuard information in the WireGuard webgui - under VPN > WireGuard > Interface and VPN > WireGuard > Peers - and Save Both entries See this tutorial here for directions as to how to generate your TorGuard Wireguard Configuration Files : https://forums.torguard.net/index.php?/topic/1698-pfsense-wireguard-client-working-with-catch-22/ Read Step 2 on that page for detailed explanation 2- Create WireGuard Interface with this command : # wg-quick up tunwg0 Then go to Interfaces > Assign Interfaces Add tunwg0 ( opt 1 , 2 etc depending on your setup ) Name it, enable it, and don't touch any other settings. 3 - Then setup firewall rules for tunwg0 - there are many firewall setup options to be found here : https://forum.netgate.com/topic/150943/i-made-a-wireguard-package-for-pfsense Just read through the thread. If you want a simple firewall rule setup see below : 4 - Now head to pfSense WEBGUI in order to configure Wireguard Interface ( created earlier ) and FireWall Rule. First, go to Interfaces > Assignments -you will see tunwg0 interface - click (+) add button /symbol. Once the tunwg0 interface is listed as ( OPT 1 - 2 depending on your setup ) - Click underneath it - - enter check in " Enable interface " - and enter description - I call mine " WIRE " - DO NOTHING ELSE HERE ! Save and Apply - Done with this phase. 5 - Next - Firewall Rule - 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 Square with Up Arrow (underneath Mappings ) on the page which opens change Interface from WAN in drop down menu to your WireGuard ( tunwg0 ) Interface which you created and labeled previously - in this example " WIRE " . Next - Change Source Address to " ANY " from the drop down menu. Leave / Set 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. This rule is the only one you need. Now that your TorGuard WireGuard Client is 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 pfsense Router Hope this helps someone - See screenshots below for illustrative purposes - enjoy !!! Naturally substitute your own TorGuard WireGuard connection information Peace, directnupe
  12. 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 OpenWRT 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 OpenWRT 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 for OpenWRT. 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 This is an updated guide / tutorial which explains how to setup adding DNS-Over-TLS support for OpenWRT . 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 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). 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. 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 - Let Me Save You A Future Headache Complete These Steps 1 - 7 Detailed Below Before Proceeding With LAN Interface For GETDNS and STUBBY Plus UNBOUND Tutorial I compared my OpenWRT /etc/resolv.conf file to my OPNsense and pfSense Firewalls' /etc/resolv.conf files before and after configuring LAN Interface For GETDNS and STUBBY Plus UNBOUND on these three Routers - See Results Below : # Note** # domain secureone.duckdns.org # Domain Used Throughout This Guide # Is Strictly For Illustrative Purposes and Comes From My # OpenWRT DuckDNS LET’S ENCRYPT CERTIFICATES MADE SIMPLE Tutorial My OPNsense Firewall Before Results Below : # cat /etc/resolv.conf domain secureone.duckdns.org nameserver 127.0.0.1 nameserver 127.0.0.1 After Results Below : ~ # cat /etc/resolv.conf domain secureone.duckdns.org nameserver 192.168.7.11 My pfSense Firewall Before Results Below : cat /etc/resolv.conf nameserver 127.0.0.1 search secureone.duckdns.org After Results Below : cat /etc/resolv.conf nameserver 192.168.7.11 search secureone.duckdns.org OpenWRT Before Results Below : cat /etc/resolv.conf nameserver 127.0.0.1 search secureone.duckdns.org. After Results Below - 127.0.0.1 Still Present and Now Controlled By UNBOUND : [[email protected] ~]# cat /etc/resolv.conf # /tmp/resolv.conf generated by Unbound UCI 2020-02-18T10:38:51-0500 nameserver 127.0.0.1 nameserver ::1 search secureone.duckdns.org. As you see 127.0.0.1 was still being used as resolver in /etc/resolv.conf - OPNsense and pfSense have a box to check so 127.0.0.1 is disabled and not used as resolver on the router. I wanted my OpenWRT /etc/resolv.conf file to mirror the same /etc/resolv.conf contents as on my OPNsense and pfSense Firewalls. Here is how I achieved that end on OpenWRT Router ( follow directions below ) : Source Documents : https://unix.stackexchange.com/questions/421977/how-to-set-chattr-i-for-my-etc-resolv-conf and https://www.ostechnix.com/prevent-files-folders-accidental-deletion-modification-linux/ 1 - opkg update ; opkg install chattr lsattr 2 - rm /etc/resolv.conf ( remove the symlink ) 3 - touch /etc/resolv.conf ( create the new file ) 4 - nano /etc/resolv.conf ( populate it with lan and search data ) 5 - enter as below for this example : nameserver 192.168.7.11 search secureone.duckdns.org Save and Exit 6 - chattr +i /etc/resolv.conf ( make new /etc/resolv.conf immutable / undeletable ) 7 - reboot & exit Source Document : https://www.tecmint.com/make-file-directory-undeletable-immutable-in-linux/ After Taking Above Steps 1-7 Results Are Detailed Below : [[email protected] ~]# cat /etc/resolv.conf nameserver 192.168.7.11 search secureone.duckdns.org This is what I wanted - the elimination of localhost ( 127.0.0.1 ) being used as a resolver for my OpenWRT Router's /etc/resolv.conf file. Most importantly, your OpenWRT /etc/resolv.conf file ( with LAN setting ) will persist and remain unchanged after setting up your LAN Interface For GETDNS and STUBBY Plus UNBOUND as detailed in this guide. I undertook Steps 1 - 7 above to ensure that Root Hints will not be used at all by OpenWRT Router. After all, that is the ultimate goal of this project. Take Special Attention ( Unlock /etc/resolv.conf to reset Router ) : In order to reset your OpenWRT Router to default settings for any reason - you MUST ! first issue this command # chattr -i /etc/resolv.conf After doing so - you may now reset your router using your regular method Back To Setting Up DNS Over TLS On OpenWRT : Here is a basic guide as to how to do it - https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/ However a few modifications are needed - see below and follow along : As always - opkg update first and foremost Prerequisite You have a ca cert bundle installed on your router. You can do this by running the following opkg install ca-certificates 1 - opkg update ; opkg install unbound-daemon-heavy unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host unbound-checkconf odhcpd 2 - opkg update ; opkg install stubby getdns 3- My WORKING CONFIGS /etc/unbound/unbound_srv.conf ( Adjust For Your Router - I Run WRT1900ACS and WRT3200ACM So I Have Plenty Of Ram, Storage and 2 CPU's ) You should " Optimize Unbound " - especially increase size of cache among other things see guide here and adjust for your router's memory , number of cores and so on- see here: https://nlnetlabs.nl/documentation/unbound/howto-optimise/ ## Note : do-not-query-localhost: no ## this entry is necessarily removed ## from this UNBOUND configuration below ## Disabling DNS Queries From Localhost ( 127.0.0.1 ) cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF server: tls-cert-bundle: "/var/lib/unbound/ca-certificates.crt" # use all CPUs num-threads: 2 # power of 2 close to num-threads msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 # more cache memory, rrset=msg*2 rrset-cache-size: 200m msg-cache-size: 100m # more outgoing connections # depends on number of cores: 1024/cores - 50 outgoing-range: 8192 # Larger socket buffer. OS may need config. so-rcvbuf: 4m so-sndbuf: 4m interface: 192.168.7.11 # Put Your One Main LAN Address Here outgoing-interface: 192.168.7.11 # Likewise Put Your One Main LAN Address Here cache-min-ttl: 3600 cache-max-ttl: 86400 hide-identity: yes hide-version: yes hide-trustanchor: yes harden-glue: yes harden-dnssec-stripped: yes infra-cache-numhosts: 100000 num-queries-per-thread: 4096 max-udp-size: 3072 minimal-responses: yes rrset-roundrobin: yes use-caps-for-id: no do-ip6: no do-ip4: yes do-tcp: yes do-udp: yes prefetch: yes prefetch-key: yes qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes aggressive-nsec: yes so-reuseport: yes unwanted-reply-threshold: 10000000 interface-automatic: yes verbosity: 1 private-domain: "secureone.duckdns.org" # Used For Illustrative Purposes ( See **Note Above ) harden-referral-path: yes target-fetch-policy: "0 0 0 0 0" val-clean-additional: yes ip-ratelimit: 300 ip-ratelimit-factor: 10 incoming-num-tcp: 100 edns-buffer-size: 4096 UNBOUND_SERVER_CONF As per guide :# Don’t let each server know the next recursion Enter via SSH command line: uci set '[email protected][0].query_minimize=1' uci commit I choose to use the /etc/stubby/stubby.yml file to configure STUBBY. My reasons for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file are for several reasons. I found that I have more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. So in order to use /etc/stubby/stubby.yml file, you must change a default setting in the /etc/config/stubby file to allow manual configuration. To keep this simple - go into default UCI STUBBY file which is /etc/config/stubby by entering nano /etc/config/stubby and then set option manual '1' - if you leave it at default setting of option manual 'o' you will not be able to use the /etc/stubby/stubby.yml file in order to configure STUBBY as before. So, after changing option manual '1' in the /etc/config/stubby file - configure /etc/stubby/stubby.yml as follows enter nano /etc/stubby/stubby.yml : 4 - 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 August 21 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 # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 9000 listen_addresses: - [email protected] # Put Your One Main LAN Address Here dns_transport_list: - GETDNS_TRANSPORT_TLS tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 tls_ca_path: "/etc/ssl/certs/" 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 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= ## 10 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 94.130.106.88 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 11 - The Foundation for Applied Privacy DNS TLS Server #2 A+ ( AUT ) - address_data: 93.177.65.183 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 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: Bt3fAHJeDPU2dneCx9Md6zTiKhzWtZ152To0j0f32Us= ## 13 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN ) - address_data: 115.159.131.230 tls_auth_name: "dns.rubyfish.cn" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo= ## 14 - 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/ ## 15 - The DNSPRIVACY.at TLS Server #1 A+ ( DEU ) - address_data: 94.130.110.185 tls_auth_name: "ns1.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fr9YdIAIg7TXJLLHp0XbeWKBS2utev0stoEIb+7rZjM= ## 16 - The DNSPRIVACY.at TLS Server #2 A+ ( DEU ) - expired 2020-04-01 - address_data: 94.130.110.178 tls_auth_name: "ns2.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo= # 17 - 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= ## 18 - 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: OvqVajUX+2j/xfYqPZid2Z8DMX2Vex8geaYw0UG77BE= ### Publicly Available DOT Test Servers ### ## 19 - 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: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 20 - 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: fiOT+xcarY8uz1UBZ0DzA+Gi5kcSHdBDrofcsZL3HGo= ## 21 - 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: BrjhBir4pbQ0+uTjlViVlc5qf1172WLQxDWevO/4bKI= ## 22 - 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: 1Mu+KSivSkoBfLiCzL+8xhg1YO7xmAjPJAJkjrv5ZvA= ## 23 - 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= ## 24 - 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: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= ## 25 - 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: OHdm30CP5hu1KI1bLnIokKL1eKbLNWQvN9bNsXb5TJQ= ## 26 - 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: W0CoacPgp4VP2zsOt2ERQuFqXTG37ud5t3ClB5Xh7dY= ## 27 - 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: NZqlaEd1y4tc4z2s/GcclhKlOQtynBKtbomw1dVCydU= ## 28 - 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: +Q7ZdLW0QXokd2OY/vUJm10ZAnm2KFC+ovJfm5++hDc= ## 29 - 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: +zKyo0IWR+e38Yw2KN7pMAkktQSjZUGN4h7BoYLytTk= ## 30 - 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: gWjnc5JNaub1U83vNZtyY/7f1ZYH+Zwt+LWLeTzbLEU= ## 31 - 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: R9/K3atF+ZHuBAVREmFiTX5N0qse+JIqoMF+usZ2dZg= ## 32 - 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: oZQKQh794UHpdtZc/7CG+9VUw+3uGIrQFfAhCvYcds4= ## 33 - 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: ZdED9Ry+FfdsbpGVr2IxR/IB0D7FaVpSBWvsRWutrjg= ## 34 - 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: xb6yo+7vmxFhyrA+NV1ZOKBGHuA03J4BjTwkWjZ3uZk= ## 35 - 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: 0oVEbW/240sc4++zXjICyOO4XKTIEewY9zY5G5v9YnY= ## 36 - 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: 3dV7cgTZbmHD/JTfocBI6FvoyGevpZf2n5k2fG4uVr8= ## 37 - 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: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE= ## 38 - 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: Ua+l/cIZ9dbJPExk4grit6qFZWmQZcoIoMBvMLwUDHc= ## 39 - 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: P8A1QEHTXs7QSmAuwR4FupMd3L/OW9TXbTXcFaazzoU= ## 40 - 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: ncPZ5vhEPiv7VOf2nesJW9GYOGZ48MsAhzd4PO+3NJQ= ## 41 - 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: 8ZpLg8m7CE41EnXddCRJGsaWK2UVjy2UnhPo/7BsPIo= ## 42 - 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: 9QRO8JyJCVMU+KAO9acW5xfQnSXRuj1OqAz5aZHwH+4= ## 43 - The Hostux DNS TLS Server A+ ( LUX ) - address_data: 185.26.126.37 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= ## 44 - 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= ## 45 - 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= # 46 - 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: vAgfcoO9rzejY7Pdv9MK9DymLvYYJ4PF5V1QzReF4MU= # 47 - The doh.defaultroutes.de DNS TLS Server A+ ( DEU ) - address_data: 5.45.107.88 tls_auth_name: "doh.defaultroutes.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0= ## 48 - 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= # 49 - 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= ## 50 - 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: wnJgPKtu/QHXHx3QZ7mZuIsNMv85buI5jsdsS9cTU5w= ## 51 - 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: +rBZZHFEVTmFwA8RuR9I5vdPqqaBSighP7rcoWgY9MI= ## 52 - The Arapurayil DNS TLS Server A+ ( AUS ) - address_data: 3.7.156.128 tls_auth_name: "dns.arapurayil.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c3S8JssMSrXuMjDfjwzXHoO4RQckTYTTeUThdW+meo0= ## 53 - 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= ## 54 - 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= ### Anycast Publicly Available DOT Test Servers ### ## 55 - The NixNet Uncensored Anycast DNS TLS Servers ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= ## 56 - 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 ### ## 57 - 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= ## 58 - The Comss.one DNS TLS Server #1 A+ ( CHN ) - address_data: 92.38.152.163 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 59 - The Comss.one DNS TLS Server #2 A+ ( CHN ) - address_data: 93.115.24.205 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 60 - The Comss.one DNS TLS Server #3 A+ ( CHN ) - address_data: 93.115.24.204 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= # 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_28_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 In order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby instance, OpenWrt must have OpenSSL 1.1.1 active and configured in the kernel. Any OpenWrt 18.06 Build does not offer OpenSSL 1.1.1 in any shape, form or fashion.OpenWrt 19.07.0 Release Candidates and Snapshots do provide OpenSSL 1.1.1 support. Once you have OpenSSL 1.1.1 with TLSv1.3 simply follow the guide 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 168.235.81.167:853 OR : openssl s_client 159.69.198.101: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 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 5 - MY WORKING CONFIG /etc/unbound/unbound_ext.conf ( Simply Copy and Paste Into Your SSH Session and Hit Enter ) cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] # Forward Unbound To Stubby Address/Port UNBOUND_FORWARD_CONF 6 - # Move dnsmasq to port 53535 where it will still serve local DNS from DHCP # Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535 uci set '[email protected][0].port=53535' # Configure dnsmasq to send a DNS Server DHCP option with its LAN IP # since it does not do this by default when port is configured. uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)" uci set '[email protected][0].dhcp_link=dnsmasq' # Save & Apply (will restart dnsmasq, DNS unreachable until unbound is up) uci commit && reload_config # Restart (or start) unbound (System -> Startup -> unbound -> Restart) /etc/init.d/unbound restart 7 - uci add_list [email protected][-1].server='192.168.7.11#5453' # Put Your One Main LAN Address Here uci set [email protected][-1].noresolv=1 uci commit && reload_config A - Via UCI (Unified Configuration Interface) - in shell uci set [email protected][0].cachesize=8192 uci set [email protected][0].dnsforwardmax=250 uci set [email protected][0].rebind_protection=1 uci set [email protected][0].ednspacket_max=4096 uci commit dhcp && reload_config 8 - nano /etc/config/network uci set network.wan.peerdns='0' uci set network.wan.dns='192.168.7.11' uci commit && reload_config 9 - nano /etc/config/unbound # Edit Unbound Config File config unbound option add_extra_dns '0' option add_local_fqdn '1' option add_wan_fqdn '0' option dhcp4_slaac6 '0' option dns64 '0' option dns64_prefix '64:ff9b::/96' option domain "secureone.duckdns.org" # Used For Illustrative Purposes ( See **Note Above ) option domain_type 'transparent' option edns_size '4096' option extended_stats '1' option hide_binddata '1' option extended_luci '1' option luci_expanded '1' option listen_port '53' option localservice '1' option num_threads '2' option manual_conf '0' option protocol 'ip4_only' option query_minimize '1' option query_min_strict '1' option rebind_localhost '1' option rebind_protection '1' option recursion 'aggressive' option resource 'medium' option root_age '9' option ttl_min '150' option unbound_control '3' option validator '1' option validator_ntp '1' option verbosity '2' list trigger_interface 'wan' list trigger_interface 'lan' list domain_insecure '3.us.pool.ntp.org' option dhcp_link 'dnsmasq' 10 - Final Step --- # /etc/init.d/unbound restart 11 - # reboot & exit 12 - Install OpenWRT dnsmasq-full package - ( Optional ) # opkg update ; opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk Done - See https://forums.torguard.net/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ or ( From The DNS Privacy Project ) https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 For Comparisons - Peace Lastly, Check Your DNS Servers Below : https://www.dnsleaktest.com/ https://cryptoip.info/dns-leak-test https://www.grc.com/dns/dns.htm https://bash.ws/dnsleak/test/ and last but not least https://cmdns.dev.dns-oarc.net/ for a thorough in depth DNS 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.
  13. 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 August 21 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: - [email protected] ## Enter Your One Main LAN Address Here tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 round_robin_upstreams: 1 tls_ca_path: "/etc/ssl/" 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 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= ## 10 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 94.130.106.88 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 11 - The Foundation for Applied Privacy DNS TLS Server #2 A+ ( AUT ) - address_data: 93.177.65.183 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 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: Bt3fAHJeDPU2dneCx9Md6zTiKhzWtZ152To0j0f32Us= ## 13 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN ) - address_data: 115.159.131.230 tls_auth_name: "dns.rubyfish.cn" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo= ## 14 - 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/ ## 15 - The DNSPRIVACY.at TLS Server #1 A+ ( DEU ) - address_data: 94.130.110.185 tls_auth_name: "ns1.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fr9YdIAIg7TXJLLHp0XbeWKBS2utev0stoEIb+7rZjM= ## 16 - The DNSPRIVACY.at TLS Server #2 A+ ( DEU ) - expired 2020-04-01 - address_data: 94.130.110.178 tls_auth_name: "ns2.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo= # 17 - 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= ## 18 - 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: OvqVajUX+2j/xfYqPZid2Z8DMX2Vex8geaYw0UG77BE= ### Publicly Available DOT Test Servers ### ## 19 - 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: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 20 - 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: fiOT+xcarY8uz1UBZ0DzA+Gi5kcSHdBDrofcsZL3HGo= ## 21 - 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: BrjhBir4pbQ0+uTjlViVlc5qf1172WLQxDWevO/4bKI= ## 22 - 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: 1Mu+KSivSkoBfLiCzL+8xhg1YO7xmAjPJAJkjrv5ZvA= ## 23 - 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= ## 24 - 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: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= ## 25 - 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: OHdm30CP5hu1KI1bLnIokKL1eKbLNWQvN9bNsXb5TJQ= ## 26 - 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: W0CoacPgp4VP2zsOt2ERQuFqXTG37ud5t3ClB5Xh7dY= ## 27 - 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: NZqlaEd1y4tc4z2s/GcclhKlOQtynBKtbomw1dVCydU= ## 28 - 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: +Q7ZdLW0QXokd2OY/vUJm10ZAnm2KFC+ovJfm5++hDc= ## 29 - 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: +zKyo0IWR+e38Yw2KN7pMAkktQSjZUGN4h7BoYLytTk= ## 30 - 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: gWjnc5JNaub1U83vNZtyY/7f1ZYH+Zwt+LWLeTzbLEU= ## 31 - 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: R9/K3atF+ZHuBAVREmFiTX5N0qse+JIqoMF+usZ2dZg= ## 32 - 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: oZQKQh794UHpdtZc/7CG+9VUw+3uGIrQFfAhCvYcds4= ## 33 - 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: ZdED9Ry+FfdsbpGVr2IxR/IB0D7FaVpSBWvsRWutrjg= ## 34 - 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: xb6yo+7vmxFhyrA+NV1ZOKBGHuA03J4BjTwkWjZ3uZk= ## 35 - 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: 0oVEbW/240sc4++zXjICyOO4XKTIEewY9zY5G5v9YnY= ## 36 - 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: 3dV7cgTZbmHD/JTfocBI6FvoyGevpZf2n5k2fG4uVr8= ## 37 - 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: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE= ## 38 - 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: Ua+l/cIZ9dbJPExk4grit6qFZWmQZcoIoMBvMLwUDHc= ## 39 - 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: P8A1QEHTXs7QSmAuwR4FupMd3L/OW9TXbTXcFaazzoU= ## 40 - 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: ncPZ5vhEPiv7VOf2nesJW9GYOGZ48MsAhzd4PO+3NJQ= ## 41 - 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: 8ZpLg8m7CE41EnXddCRJGsaWK2UVjy2UnhPo/7BsPIo= ## 42 - 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: 9QRO8JyJCVMU+KAO9acW5xfQnSXRuj1OqAz5aZHwH+4= ## 43 - The Hostux DNS TLS Server A+ ( LUX ) - address_data: 185.26.126.37 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= ## 44 - 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= ## 45 - 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= # 46 - 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: vAgfcoO9rzejY7Pdv9MK9DymLvYYJ4PF5V1QzReF4MU= # 47 - The doh.defaultroutes.de DNS TLS Server A+ ( DEU ) - address_data: 5.45.107.88 tls_auth_name: "doh.defaultroutes.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0= ## 48 - 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= # 49 - 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= ## 50 - 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: wnJgPKtu/QHXHx3QZ7mZuIsNMv85buI5jsdsS9cTU5w= ## 51 - 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: +rBZZHFEVTmFwA8RuR9I5vdPqqaBSighP7rcoWgY9MI= ## 52 - The Arapurayil DNS TLS Server A+ ( AUS ) - address_data: 3.7.156.128 tls_auth_name: "dns.arapurayil.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c3S8JssMSrXuMjDfjwzXHoO4RQckTYTTeUThdW+meo0= ## 53 - 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= ## 54 - 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= ### Anycast Publicly Available DOT Test Servers ### ## 55 - The NixNet Uncensored Anycast DNS TLS Servers ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= ## 56 - 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 ### ## 57 - 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= ## 58 - The Comss.one DNS TLS Server #1 A+ ( CHN ) - address_data: 92.38.152.163 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 59 - The Comss.one DNS TLS Server #2 A+ ( CHN ) - address_data: 93.115.24.205 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 60 - The Comss.one DNS TLS Server #3 A+ ( CHN ) - address_data: 93.115.24.204 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= 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 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: [email protected] ## ( 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.
  14. 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 get 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 August 21 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: - [email protected] tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 round_robin_upstreams: 1 tls_ca_path: "/etc/ssl/" 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 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= ## 10 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 94.130.106.88 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 11 - The Foundation for Applied Privacy DNS TLS Server #2 A+ ( AUT ) - address_data: 93.177.65.183 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 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: Bt3fAHJeDPU2dneCx9Md6zTiKhzWtZ152To0j0f32Us= ## 13 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN ) - address_data: 115.159.131.230 tls_auth_name: "dns.rubyfish.cn" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo= ## 14 - 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/ ## 15 - The DNSPRIVACY.at TLS Server #1 A+ ( DEU ) - address_data: 94.130.110.185 tls_auth_name: "ns1.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fr9YdIAIg7TXJLLHp0XbeWKBS2utev0stoEIb+7rZjM= ## 16 - The DNSPRIVACY.at TLS Server #2 A+ ( DEU ) - expired 2020-04-01 - address_data: 94.130.110.178 tls_auth_name: "ns2.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo= # 17 - 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= ## 18 - 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: OvqVajUX+2j/xfYqPZid2Z8DMX2Vex8geaYw0UG77BE= ### Publicly Available DOT Test Servers ### ## 19 - 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: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 20 - 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: fiOT+xcarY8uz1UBZ0DzA+Gi5kcSHdBDrofcsZL3HGo= ## 21 - 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: BrjhBir4pbQ0+uTjlViVlc5qf1172WLQxDWevO/4bKI= ## 22 - 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: 1Mu+KSivSkoBfLiCzL+8xhg1YO7xmAjPJAJkjrv5ZvA= ## 23 - 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= ## 24 - 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: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= ## 25 - 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: OHdm30CP5hu1KI1bLnIokKL1eKbLNWQvN9bNsXb5TJQ= ## 26 - 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: W0CoacPgp4VP2zsOt2ERQuFqXTG37ud5t3ClB5Xh7dY= ## 27 - 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: NZqlaEd1y4tc4z2s/GcclhKlOQtynBKtbomw1dVCydU= ## 28 - 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: +Q7ZdLW0QXokd2OY/vUJm10ZAnm2KFC+ovJfm5++hDc= ## 29 - 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: +zKyo0IWR+e38Yw2KN7pMAkktQSjZUGN4h7BoYLytTk= ## 30 - 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: gWjnc5JNaub1U83vNZtyY/7f1ZYH+Zwt+LWLeTzbLEU= ## 31 - 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: R9/K3atF+ZHuBAVREmFiTX5N0qse+JIqoMF+usZ2dZg= ## 32 - 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: oZQKQh794UHpdtZc/7CG+9VUw+3uGIrQFfAhCvYcds4= ## 33 - 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: ZdED9Ry+FfdsbpGVr2IxR/IB0D7FaVpSBWvsRWutrjg= ## 34 - 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: xb6yo+7vmxFhyrA+NV1ZOKBGHuA03J4BjTwkWjZ3uZk= ## 35 - 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: 0oVEbW/240sc4++zXjICyOO4XKTIEewY9zY5G5v9YnY= ## 36 - 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: 3dV7cgTZbmHD/JTfocBI6FvoyGevpZf2n5k2fG4uVr8= ## 37 - 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: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE= ## 38 - 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: Ua+l/cIZ9dbJPExk4grit6qFZWmQZcoIoMBvMLwUDHc= ## 39 - 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: P8A1QEHTXs7QSmAuwR4FupMd3L/OW9TXbTXcFaazzoU= ## 40 - 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: ncPZ5vhEPiv7VOf2nesJW9GYOGZ48MsAhzd4PO+3NJQ= ## 41 - 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: 8ZpLg8m7CE41EnXddCRJGsaWK2UVjy2UnhPo/7BsPIo= ## 42 - 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: 9QRO8JyJCVMU+KAO9acW5xfQnSXRuj1OqAz5aZHwH+4= ## 43 - The Hostux DNS TLS Server A+ ( LUX ) - address_data: 185.26.126.37 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= ## 44 - 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= ## 45 - 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= # 46 - 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: vAgfcoO9rzejY7Pdv9MK9DymLvYYJ4PF5V1QzReF4MU= # 47 - The doh.defaultroutes.de DNS TLS Server A+ ( DEU ) - address_data: 5.45.107.88 tls_auth_name: "doh.defaultroutes.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0= ## 48 - 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= # 49 - 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= ## 50 - 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: wnJgPKtu/QHXHx3QZ7mZuIsNMv85buI5jsdsS9cTU5w= ## 51 - 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: +rBZZHFEVTmFwA8RuR9I5vdPqqaBSighP7rcoWgY9MI= ## 52 - The Arapurayil DNS TLS Server A+ ( AUS ) - address_data: 3.7.156.128 tls_auth_name: "dns.arapurayil.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c3S8JssMSrXuMjDfjwzXHoO4RQckTYTTeUThdW+meo0= ## 53 - 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= ## 54 - 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= ### Anycast Publicly Available DOT Test Servers ### ## 55 - The NixNet Uncensored Anycast DNS TLS Servers ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= ## 56 - 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 ### ## 57 - 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= ## 58 - The Comss.one DNS TLS Server #1 A+ ( CHN ) - address_data: 92.38.152.163 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 59 - The Comss.one DNS TLS Server #2 A+ ( CHN ) - address_data: 93.115.24.205 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 60 - The Comss.one DNS TLS Server #3 A+ ( CHN ) - address_data: 93.115.24.204 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= 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. 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: [email protected] ## 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
  15. 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
  16. Dear Community, Original OPNsnese Forum Post Here : https://forum.opnsense.org/index.php?topic=13461.0 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=LQkdiJQIX5Y 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 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. This rule is the only one you need. When using these updated packages as I did, in order to stop nagging messages to re-install outdated OPNsense wireguard and wireguard-go packages use FreeBSD pkg lock option. Issue commands in order : # pkg lock wireguard and # pkg lock wireguard-go It may be necessary to reboot OPNsense after locking wireguard and wireguard-go packages in order to restart WireGuard from command line. 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
  17. Dear TorGuard OpenWrt Users, 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 Hello - and I hope that you are well. This is how to get and setup Let's Encrypt Certificate using DuckDNS on OpenWrt. If you follow these instructions you should have no problems at all. I picked DuckDns because - it allows you five Domains ( read sub-domains ) and supports Let's Encrypt on OpenWrt. First go to https://www.duckdns.org/ - Log in order create account. I use reddit to sign in - DuckDNS also offers Google, Twitter, GitHub, or Persona logins to create an account. You are allowed five sub domains - create one - name it would you like - something like secureone. Your full sub domain is now- secureone.duckdns.org - Click on " install " on the top banner - go to " first step - choose a domain " and from the drop down menu - select the sub-domain you just created - secureone.duckdns.org - then under " Routers " - select " OpenWrt " - you will then get these instructions: find them below the DuckDNS DDNS SCRIPT SECTION. Before You Begin You Should Make HOSTNAME under System something like cryptorouter ( or whatever you like ) and under Network > DHCP and DNS > Local domain - enter something like - home.secureone.duckdns.org When you are done this is the FQDN that your Let's Encrypt Certificate will named - in this example it is as follows : cryptorouter.home.secureone.duckdns.org DuckDNS DDNS SCRIPT SECTION: First, I use a script to update DuckDNS DDNS service. See here : https://www.bytebang.at/Blog/Find+public+IP+address+for+OpenWRT+via+Script# To implement this script, please follow these instructions below: opkg update && opkg install ddns-scripts luci-app-ddns ## Davidc502 SnapShots Come With This Pre-Installed DuckDNS OpenWrt DDNS SETUP : touch /usr/lib/ddns/getPublicIp.sh nano /usr/lib/ddns/getPublicIp.sh enter this script below in the new file : #!/bin/sh # sample script for detecting the public IP wget -q -O - "http://myexternalip.com/raw" ## Davidc502 SnapShots Comes With Wget Pre-Installed make it executable = chmod +x /usr/lib/ddns/getPublicIp.sh edit the config at /etc/config/ddns nano /etc/config/ddns ## Replace The IPV4 Configuration With The Contents Below: config service 'duckdns' option enabled '1' option username 'secureone' option domain 'secureone.duckdns.org' option password 'f8be3d28-104e-45d2-a5a9-e95599b84ae2' ## Use Your Own DuckDNS PassWord - This one is a fake option interface 'wan' option check_interval '5' option check_unit 'minutes' option force_interval '24' option force_unit 'hours' option ip_source 'script' option retry_interval '60' option retry_unit 'seconds' option ip_script '/usr/lib/ddns/./getPublicIp.sh' option update_url 'https://www.duckdns.org/update?domains=[USERNAME]&token=[PASSWORD]&ip=[IP]' option use_https '1' option cacert '/etc/ssl/certs/ca-bundle.crt' option lookup_host 'secureone.duckdns.org' option service_name 'duckdns.org' Next here are the correct commands for SSL HTTPS DuckDNS below: opkg update opkg install curl ## Davidc502 SnapShots Come With This Pre-Installed mkdir -p /etc/ssl/certs ## Directory Exists Already On Davidc502 SnapShots Issue This Most Important Command Below: curl -k https://certs.secureserver.net/repository/sf_bundle-g2.crt > /etc/ssl/certs/ca-bundle.crt Now Start DDNS : sh . /usr/lib/ddns/dynamic_dns_functions.sh # note the leading period start_daemon_for_all_ddns_sections "wan" exit ## Very Important To Exit we can now test the script by running the command /usr/lib/ddns/dynamic_dns_updater.sh duckdns Then Check DDNS under Services Is Up And Running. Now that you have DuckDNS Service running on your OpenWrt Router - let us install Let's Encrypt Certificate. First you must issue these commands: uci delete uhttpd.main.listen_http uci set uhttpd.main.redirect_https=1 uci set uhttpd.main.rfc1918_filter='0' ## This allows you to login with public sub-domain uci commit /etc/init.d/uhttpd restart Now install necessary Let's Encrypt packages as follows : opkg update ; opkg install socat ncat luci-app-acme acme-dnsapi acme coreutils-stat ## acme-dnsapi is themost important one Then issue certificate with this command: ## Token is your DuckDNS Password & Please Note FQDN Placement DuckDNS_Token="f8be3d28-104e-45d2-a5a9-e95599b84ae2" /usr/lib/acme/acme.sh --issue -d cryptorouter.home.secureone.duckdns.org --dns dns_duckdns The issuance takes 120 seconds to complete after acme challenge ; when finished You can locate the certificate and key files in ./.acme.sh/your.domain/, and then in the uHTTPd settings point the certificate and key path to them respectively This means that the two main files you need are found here : /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.cer /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key Now edit /etc/config/uhttpd file thusly as demonstrated below: ## Notice that I set https ONLY earlier and now the login port is set to " 10445 " nano /etc/config/uhttpd config uhttpd 'main' list listen_https '0.0.0.0:10445' list listen_https '[::]:10445' option redirect_https '1' option home '/www' option max_requests '3' option max_connections '100' option cert '/root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.cer' option key '/root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key' option cgi_prefix '/cgi-bin' list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua' option script_timeout '60' option network_timeout '30' option http_keepalive '20' option tcp_keepalive '1' option ubus_prefix '/ubus' option rfc1918_filter '0' config cert 'defaults' option days '730' option bits '4096' option country 'US' option state 'Texas' option location 'Austin' option commonname 'OpenWrt' then issue this command : chmod 400 /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key At this point DO NOT !! - I REPEAT DO NOT !! - DO NOT RESTART " uhttpd " for any reason whatsoever. Instead clear your browser - close - clean cookies and all that good stuff. Actually after clearing your web browser it is best to reboot your router in order to make sure to that you can login to your router with your new valid certificate. After reboot, open your browser and login with - https://cryptorouter.home.secureone.duckdns.org:10445 - as per this example. You should not be prompted by " insecure warning " any longer - and the green padlock will appear in the address bar. Click on it and see the certificate details if you wish. NEXT CONFIGURE ACME FOR AUTOMATIC RENEWAL edit /etc/config/acme as below: nano /etc/config/acme config acme option state_dir '/root/.acme.sh/' option account_email '[email protected]' ## Fake E-mail Too option debug '1' config cert 'example' option keylength '4096' option update_uhttpd '1' option enabled '1' option webroot '/www' list domains 'cryptorouter.home.secureone.duckdns.org' option use_staging '0' option dns 'acme.sh --insecure --issue --dns dns_duckdns -d cryptorouter.home.secureone.duckdns.org' list credentials 'export DuckDNS_Token="f8be3d28-104e-45d2-a5a9-e95599b84ae2"' Then issue this command: # /etc/init.d/acme enable - at this point it is best to reboot your router - I have found that if you restart ACME at this point via command line you may unintentionally reissue your Let's Encrypt Certificate - so as I said, REBOOT YOUR ROUTER ! BONUS : In order to preserve your Let's Encrypt Certificates - use WINSCP and go into default directory. In this case open : /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/ on the right side of the window. You will see all the certificates and associated files. Save them to a folder on your desktop USB or what have you in case you need to upgrade or install new OpenWrt - for instance, Dave puts out new SnapShots every two weeks approximately. As you know, Let's Encrypt Certificates are good for 90 days and you do not want to abuse this free service. You can reuse them via WINSCP - make sure to create and install them to proper directory on new install as follows- issue command: mkdir -p /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/ Then WINSCP the saved Let's Encrypt Files from your previous storage desktop directory or USB into this newly created router directory. That is after you setup DuckDNS - installed necessary ACME packages and follow all the instructions above EXCEPT for creating a new certificate. Do not forget this command either: chmod 400 /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key Remember all of this was done using " fictional " hostname, local domain - DuckDNS token and so on ; however, it does illustrate how to get you going. I find DuckDNS very easy to implement and manage. I also use DuckDNS on pfSense and OPNsense.
  18. READ ENTIRE GUIDE BEFORE YOU BEGIN This Tutorial / Guide Was Updated on Jan 15 2020 in order to keep you in step with changes on packages needed for OpenWrt 19.07.0 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 See here for GETDNS AND STUBBY on OPENWRT / LEDE: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md - this page is designed for DNS OVER TLS with DNSMASQ but it still is useful and informative . See Here For OPENWRT STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING https://forum.openwrt.org/t/stubby-dns-over-tls-using-dnsmasq-full-for-dnssec-caching/19107 UPDATED GUIDE For UNBOUND: ( IF YOU NEED IT ! ) https://torguard.net/forums/index.php?/topic/1509-updated-guide-for-getdns-142-2-stubby-023-3-and-unbound-181-2/ Why I am so damn serious about DNS Privacy ( just watch these when you have time - all at once or in intervals - very educational 😞 https://dnsprivacy.org/wiki/display/DP/IETF+DNS+Privacy+Tutorial https://www.youtube.com/watch?v=2JeYIecfwdc https://www.youtube.com/watch?v=JnxE5RPnyiE Active work is also underway at the IETF on DNS-over-HTTP (DOH) but today the only method standardized by the IETF is DNS-over-TLS. In the world of encryption, it's always safer to go with standardized protocols that have gone through a rigorous review process. Unfortunately DNSCrypt has not been standardized yet, and some of the ways it uses cryptography are unusual. If you need more storage and swap memory for your router see here: http://ediy.com.my/index.php/blog/item/118-how-to-increase-storage-on-tp-link-tl-mr3020-with-extroot and here: https://samhobbs.co.uk/2013/11/more-space-for-packages-with-extroot-on-your-openwrt-router For partitioning USB external flash drives I personally prefer GParted Live and / or MiniTool Partition Wizard 9.1 Boot Iso and both work great - found here: https://gparted.org/download.php and here respectively https://www.chip.de/downloads/Partition-Wizard-Bootable-CD_38297298.html For all of those who are using UNBOUND with tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" # For OpenWrt option: found here This will have to wait until OpenSSL 1.1.x .From Unbound Recursive DNS Server with UCI found here: https://github.com/openwrt/packages/blob/master/net/unbound/files/README.md And Look for section at the bottom entitled HOW TO: TLS Over DNS read this: NOTICE: Unbound requires openssl-1.1.0 to verify host certificates. OpenWrt at present is configured with openssl-1.0.2. Connections will be over TLS, but theoretically, certificates may not be from a trusted source. See report https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658 When this is resolved, it will be recommended again to install ca-bundle, maintain it, and be sure to include the TLS certificate domain index with the host addresses. 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/ Yes I run GETDNS and STUBBY. For those who wish to explore GETDNS and STUBBY - this method is the one recommended by DNSPRIVACY - see here : https://getdnsapi.net/ 5 https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby 2 https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients#DNSPrivacyClients-Unbound 3 - 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). 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 So here we go. 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 - FYI, David Mora aka iamperson347 the developer and maintainer of GETDNS and STUBBY package for OpenWRT / LEDE assisted me in putting this all together. Dave strongly suggested using DNSMASQ for DHCP and UNBOUND and STUBBY for DNS OVER TLS. Dave's reason was that OpenWrt / Lede performs best when configured in this fashion. Directly from David Mora aka iamperson347 the developer and maintainer of GETDNS and STUBBY and I quote: "I recommend running Unbound to utilize the caching. Sometimes the connections from stubby to the resolver can have a little but of lag, so caching + prefetch helps minimize the effects." Unbound is a recursive caching DNS Resolver - which by design and definition speeds up your DNS RESOLUTION. DNS addresses are stored in the cache and called upon and directed to almost IMMEDIATELY ! ( Query time: 0 msec ) resolve dns addresses in subsequent DNS look ups after your first visit to cached objects. A small number has questioned DNS OVER TLS and the supposed complexity of this setup vis a’ vis DNSCrypt. DNSCrypt has always been suggested to best deployed when forwarded to Unbound as a Caching Server. In effect, this methodology simply drops Stubby and GetDns in place instead of DNSCrypt. The use of DNSMasq for DHCP is particular to OpenWRT / LEDE. However, it is a fairly simple and straightforward task to setup DNSMasq for purposes of DHCP and well described and referenced in this tutorial. Lastly, GetDns and Stubby do allow for TLS OVER Port 443 and I have amended this guide to reflect that option for those who may worry about being blocked behind a firewall while using TLS OVER Port 853. https://www.nlnetlabs.nl/projects/unbound/about/ This method combines Unbound (as a caching proxy) and Stubby (as fully featured TLS forwarder). Stubby is essential - please read the following: Stubby' is an application that acts as a local DNS Privacy stub resolver (using DNS-over-TLS). Stubby encrypts DNS queries sent from a client machine (desktop or laptop) to a DNS Privacy resolver increasing end user privacy. Stubby is developed by the getdns project. Stubby is essential - please read the following: https://dnsprivacy.org/wiki/display/DP/About+Stubby I run GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. You can use odhcpd which will handle both DNS and DHCP where you disable and/ or remove DNSMASQ - but you will experience a performance hit. This why I use Unbound/ STUBBY for DNS and Dnsmasq for DHCP . Here is a basic guide as to how to do it - https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/ 5 However a few modifications are necessary in order to to have GetDns and Stubby up and running and successfully integrated with Unbound DNS and Dnsmasq for DHCP. I will write up a guide here - but don’t give me a hard time later on. Directly From DNS Privacy Website: Stubby is an experimental implementation of a DNS Privacy enabled stub resolver. It is currently suitable for advanced/technical users - all feedback is welcome! Also see https://dnsprivacy.org/ for more information on DNS Privacy. 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. By the way I run Davidc502 LEDE Snapshots - Moderately Customized LEDE Development Builds for Linksys 1900ac v.1 and 1900ac v.2, 1900acs v.1 v.2, 3200acm, WRT32X and 1200ac v.1 v.2 series routers. These builds keep up to date package repositories.. GetDns and Stubby are included. Dave's Builds have many other pre-installed common packages as well.. Check out homepage and downloads here: https://davidc502sis.dynamic-dns.net/ and downloads here: https://davidc502sis.dynamic-dns.net/snapshots/ . In addition, there is a very informative, instructive and active thread ( forum ) for Dave's builds and discussion of many OpenWrt / Lede packages, features, and issues. In short great technical advice and assistance can be found here: https://forum.openwrt.org/t/davidc502-wrt1200ac-wrt1900acx-wrt3200acm-wrt32x-builds/ Dave releases new updated builds every two weeks - near the middle and first of each month. - As always - opkg update first and foremost Prerequisite You have a ca cert bundle installed on your router. You can do this by running the following opkg install ca-certificates Now Let’s Move On 1 - opkg update ; opkg install unbound-daemon-heavy unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host unbound-checkconf odhcpd 2 - opkg update ; opkg install stubby getdns 3- My WORKING CONFIGS /etc/unbound/unbound_srv.conf ( Must Adjust For Your Router - I Run WRT1900ACS and WRT3200ACM So I Have Plenty Of Ram, Storage and 2 CPU's ) You should " Optimize Unbound " - especially increase size of cache among other things see guide here and adjust for your router's memory , number of cores and so on- see here: https://nlnetlabs.nl/documentation/unbound/howto-optimise/ for basic guide ( Simply Copy and Paste Into Your SSH Session and Hit Enter ) cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF server: # use all CPUs num-threads: 2 # power of 2 close to num-threads msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 # more cache memory, rrset=msg*2 rrset-cache-size: 256m msg-cache-size: 128m # more outgoing connections # depends on number of cores: 1024/cores - 50 outgoing-range: 8192 # Larger socket buffer. OS may need config. so-rcvbuf: 4m so-sndbuf: 4m cache-min-ttl: 3600 cache-max-ttl: 86400 hide-identity: yes hide-version: yes hide-trustanchor: yes harden-glue: yes harden-dnssec-stripped: yes infra-cache-numhosts: 100000 num-queries-per-thread: 4096 max-udp-size: 3072 minimal-responses: yes rrset-roundrobin: yes use-caps-for-id: no do-ip6: no do-ip4: yes do-tcp: yes do-udp: yes prefetch: yes prefetch-key: yes qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes aggressive-nsec: yes so-reuseport: yes unwanted-reply-threshold: 10000000 interface-automatic: yes verbosity: 1 private-domain: "your.domain" ## put your domain here do-not-query-localhost: no harden-referral-path: yes target-fetch-policy: "0 0 0 0 0" val-clean-additional: yes ip-ratelimit: 300 ip-ratelimit-factor: 10 incoming-num-tcp: 100 edns-buffer-size: 1472 UNBOUND_SERVER_CONF As per guide :# Don’t let each server know the next recursion Enter via SSH command line: uci set ‘[email protected][0].query_minimize=1’ I choose to use the /etc/stubby/stubby.yml file to configure STUBBY. My reasons for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file are for several reasons. I found that I have more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. So in order to use /etc/stubby/stubby.yml file, you must change a default setting in the /etc/config/stubby file to allow manual configuration. To keep this simple - go into default UCI STUBBY file which is /etc/config/stubby by entering nano /etc/config/stubby and then set option manual '1' - if you leave it at default setting of option manual 'o' you will not be able to use the /etc/stubby/stubby.yml file in order to configure STUBBY as before. So, after changing option manual '1' in the /etc/config/stubby file - configure /etc/stubby/stubby.yml as follows : 4 - My WORKING CONFIG /etc/stubby/stubby.yml I prefer to run these DNS TLS SERVERS as they tend to be stable most all of the time. However, even if you run ssl-upstream with Unbound you still will need to monitor real time status of DNS Privacy Test Servers. So, Stubby is still the full featured way to go. See all DNS TLS SERVERS here if you choose to run others: DNS Privacy Test Servers https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers 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 Servers Real Time Status here below: https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/ Here is a list of all DNS Privacy Servers in the raw. Add ( tls_port: 853 ) after ( - address_data: ) entry: https://raw.githubusercontent.com/getdnsapi/stubby/develop/stubby.yml.example See here for how to configure Stubby: https://github.com/getdnsapi/stubby DNS OVER TLS ABSOLUTE BEST CONFIGURATION FOR STUBBY FOR THE REASONS DETAILED BELOW: nano /etc/stubby/stubby.yml - replace contents of file with configuration below: 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/ 1 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 August 21 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 # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 9000 listen_addresses: - [email protected] dns_transport_list: - GETDNS_TRANSPORT_TLS tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 tls_ca_path: "/etc/ssl/certs/" 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 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= ## 10 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 94.130.106.88 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 11 - The Foundation for Applied Privacy DNS TLS Server #2 A+ ( AUT ) - address_data: 93.177.65.183 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 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: Bt3fAHJeDPU2dneCx9Md6zTiKhzWtZ152To0j0f32Us= ## 13 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN ) - address_data: 115.159.131.230 tls_auth_name: "dns.rubyfish.cn" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo= ## 14 - 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/ ## 15 - The DNSPRIVACY.at TLS Server #1 A+ ( DEU ) - address_data: 94.130.110.185 tls_auth_name: "ns1.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fr9YdIAIg7TXJLLHp0XbeWKBS2utev0stoEIb+7rZjM= ## 16 - The DNSPRIVACY.at TLS Server #2 A+ ( DEU ) - expired 2020-04-01 - address_data: 94.130.110.178 tls_auth_name: "ns2.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo= # 17 - 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= ## 18 - 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: OvqVajUX+2j/xfYqPZid2Z8DMX2Vex8geaYw0UG77BE= ### Publicly Available DOT Test Servers ### ## 19 - 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: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 20 - 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: fiOT+xcarY8uz1UBZ0DzA+Gi5kcSHdBDrofcsZL3HGo= ## 21 - 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: BrjhBir4pbQ0+uTjlViVlc5qf1172WLQxDWevO/4bKI= ## 22 - 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: 1Mu+KSivSkoBfLiCzL+8xhg1YO7xmAjPJAJkjrv5ZvA= ## 23 - 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= ## 24 - 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: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= ## 25 - 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: OHdm30CP5hu1KI1bLnIokKL1eKbLNWQvN9bNsXb5TJQ= ## 26 - 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: W0CoacPgp4VP2zsOt2ERQuFqXTG37ud5t3ClB5Xh7dY= ## 27 - 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: NZqlaEd1y4tc4z2s/GcclhKlOQtynBKtbomw1dVCydU= ## 28 - 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: +Q7ZdLW0QXokd2OY/vUJm10ZAnm2KFC+ovJfm5++hDc= ## 29 - 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: +zKyo0IWR+e38Yw2KN7pMAkktQSjZUGN4h7BoYLytTk= ## 30 - 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: gWjnc5JNaub1U83vNZtyY/7f1ZYH+Zwt+LWLeTzbLEU= ## 31 - 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: R9/K3atF+ZHuBAVREmFiTX5N0qse+JIqoMF+usZ2dZg= ## 32 - 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: oZQKQh794UHpdtZc/7CG+9VUw+3uGIrQFfAhCvYcds4= ## 33 - 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: ZdED9Ry+FfdsbpGVr2IxR/IB0D7FaVpSBWvsRWutrjg= ## 34 - 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: xb6yo+7vmxFhyrA+NV1ZOKBGHuA03J4BjTwkWjZ3uZk= ## 35 - 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: 0oVEbW/240sc4++zXjICyOO4XKTIEewY9zY5G5v9YnY= ## 36 - 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: 3dV7cgTZbmHD/JTfocBI6FvoyGevpZf2n5k2fG4uVr8= ## 37 - 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: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE= ## 38 - 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: Ua+l/cIZ9dbJPExk4grit6qFZWmQZcoIoMBvMLwUDHc= ## 39 - 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: P8A1QEHTXs7QSmAuwR4FupMd3L/OW9TXbTXcFaazzoU= ## 40 - 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: ncPZ5vhEPiv7VOf2nesJW9GYOGZ48MsAhzd4PO+3NJQ= ## 41 - 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: 8ZpLg8m7CE41EnXddCRJGsaWK2UVjy2UnhPo/7BsPIo= ## 42 - 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: 9QRO8JyJCVMU+KAO9acW5xfQnSXRuj1OqAz5aZHwH+4= ## 43 - The Hostux DNS TLS Server A+ ( LUX ) - address_data: 185.26.126.37 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= ## 44 - 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= ## 45 - 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= # 46 - 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: vAgfcoO9rzejY7Pdv9MK9DymLvYYJ4PF5V1QzReF4MU= # 47 - The doh.defaultroutes.de DNS TLS Server A+ ( DEU ) - address_data: 5.45.107.88 tls_auth_name: "doh.defaultroutes.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0= ## 48 - 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= # 49 - 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= ## 50 - 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: wnJgPKtu/QHXHx3QZ7mZuIsNMv85buI5jsdsS9cTU5w= ## 51 - 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: +rBZZHFEVTmFwA8RuR9I5vdPqqaBSighP7rcoWgY9MI= ## 52 - The Arapurayil DNS TLS Server A+ ( AUS ) - address_data: 3.7.156.128 tls_auth_name: "dns.arapurayil.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c3S8JssMSrXuMjDfjwzXHoO4RQckTYTTeUThdW+meo0= ## 53 - 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= ## 54 - 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= ### Anycast Publicly Available DOT Test Servers ### ## 55 - The NixNet Uncensored Anycast DNS TLS Servers ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= ## 56 - 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 ### ## 57 - 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= ## 58 - The Comss.one DNS TLS Server #1 A+ ( CHN ) - address_data: 92.38.152.163 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 59 - The Comss.one DNS TLS Server #2 A+ ( CHN ) - address_data: 93.115.24.205 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 60 - The Comss.one DNS TLS Server #3 A+ ( CHN ) - address_data: 93.115.24.204 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= # 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_28_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 In order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby instance, OpenWrt must have OpenSSL 1.1.1 active and configured in the kernel. Any OpenWrt 18.06 Build does not offer OpenSSL 1.1.1 in any shape, form or fashion. OpenWrt 19.07.0 Release Candidates and Snapshots do provide OpenSSL 1.1.1 support. As I have mentioned, I run Davidc502 OpenWrt Snapshots - moderately customized Builds for Linksys wrt1200ac wrt1900acx wrt3200acm wrt32x Routers found here: https://dc502wrt.org/ - These Builds come out approximately every two weeks with the latest Linux Kernels, software packages and other bleeding edge features including OpenSSL 1.1.1 with TLSv1.3 support. Once you have OpenSSL 1.1.1 with TLSv1.3 simply follow the guide 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 168.235.81.167:853 OR - openssl s_client 159.69.198.101: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 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 - You need to opkg install drill and - then run command : drill txt qnamemintest.internet.nl and / or B - opkg install bind-dig or opkg install bind-tools with 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 in " /etc/unbound/unbound_srv.conf " file. qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes See configuration above in Step # 3 . 5 - MY WORKING CONFIG /etc/unbound/unbound_ext.conf ( Simply Copy and Paste Into Your SSH Session and Hit Enter ) cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] # Forward Unbound To Stubby Address/Port UNBOUND_FORWARD_CONF 6 - From The Guide referred to in the link above - self explanatory: # Move dnsmasq to port 53535 where it will still serve local DNS from DHCP# Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535 Enter via SSH command line: uci set ‘[email protected][0].port=53535’ uci add_list “dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)” uci set ‘[email protected][0].dhcp_link=dnsmasq’ uci commit /etc/init.d/unbound restart 7 - From https://github.com/openwrt/packages/tree/master/net/unbound/files HOW TO Integrate with DHCP Parallel DNSMASQ /etc/config/dhcp After Some Reflection and Observations - Fine Tuning Your DNS Resolver After reading System Logs I realized that there is a need to amend DNSMASQ ( DHCP ) after implementing option noresolv ‘1’ in /etc/config/dhcp configuration file. This dawned on me from my years of running DNSCRYPT Proxy on OpenWrt. I referred to this guide: Go to this section near bottom of page. Use specific DNS server to lookup one or more host names https://www.leowkahman.com/2016/05/23/openwrt-encrypted-dns-lookup-using-multiple-dnscrypt-servers/ option noresolv ‘1’ is to prevent using any upstream DNS server other than those specified in this file # this file being: /etc/config/dhcp Solution is as follows add these two lines to /etc/config/dhcp: nano /etc/config/dhcp - enter these lines before / option domain ‘yourdomain’ list server '127.0.0.1#5453' # Stubby/Unbound Default Address/Port option noresolv ‘1’ # Make sure to change this as indicated or Via Uci uci add_list [email protected][-1].server='127.0.0.1#5453' uci set [email protected][-1].noresolv=1 uci commit && reload_config 7A - Disable Sending DNS Requests to ISP Provided DNS Servers uci set network.wan.peerdns='0' uci set network.wan.dns='127.0.0.1' uci commit && reload_config After you complete all the steps in this tutorial and restart your Router Check Status > System Log - You will find an entry like the one below: daemon.info dnsmasq[8532]: using nameserver 127.0.0.1#5453 - which indicates that your OpenWrt Router is using Unbound and Stubby for Encrypted DNS Resolution 8 - Working /etc/config/unbound file nano /etc/config/unbound config unbound option add_extra_dns '0' option add_local_fqdn '1' option add_wan_fqdn '0' option dhcp4_slaac6 '0' option dns64 '0' option dns64_prefix '64:ff9b::/96' option domain "your.domain" ## put your domain here option domain_type 'static' option edns_size '1280' option extended_stats '1' option hide_binddata '1' option extended_luci '1' option luci_expanded '1' option listen_port '53' option localservice '1' option manual_conf '0' option protocol 'ip4_only' option query_min_strict '1' option rebind_localhost '0' option rebind_protection '1' option recursion 'default' option resource 'medium' option root_age '28' option ttl_min '120' option unbound_control '2' option validator '1' option validator_ntp '1' option verbosity '2' list trigger_interface 'lan' list trigger_interface 'wan' option query_minimize '1' option dhcp_link 'dnsmasq' VERY IMPORTANT STEP: Now run /etc/init.d/unbound restart one more time. When you do this you will see that your unbound root.key will be installed to /var/lib/unbound/root.key and also it will install root.key to /etc/unbound/root.key. This will automatically configure DNSSEC on your router. The function also lists your auto-trust anchor in your /var/lib/unbound/unbound.conf file. You will now be running DNS OVER TLS with GETDNS and Stubby on LEDE / OpenWrt Make sure to follow this guide precisely and it works GREAT!!! You can check logs under Services > Recursive DNS > Status > Log - you will see that you have a caching encrypted DNS Resolver !!! You can install - opkg install bind-dig or opkg install bind-tools in order to be able to issue dig commands in order to check DNS resolution if you opt to - as you test you will see that your cache is working also. Bonus Setup Option ( Highly Recommended ) - Install WatchCat http://www.ibuyopenwrt.com/index.php/2-uncategorised/224-watchcat-reboot-on-internet-drop I set "Reboot on Internet Connection Lost" option. I have WatchCat set to ping Fourth Estate DNS address - 179.43.139.226 - every 20 minutes. This will keep your router up and running consistently. 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. Lastly, you can check your DNS at GRC Spoofability Test - DNS Leak - or any of 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 opkg install gnutls-utils 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 There is also a third option. kdig -d @185.49.141.37 +tls-ca +tls-host=getdnsapi.net example.com - where you must install knot-dig / opkg install knot-dig This is my personal favorite as the readout from this command will list the certificate specifically like so: ;; DEBUG: #1, CN=getdnsapi.net ;; DEBUG: SHA-256 PIN: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= and let you know that the certificate is valid like so: ;; DEBUG: TLS, The certificate is trusted. Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable. To use kdig certificate verification method on an alternate port example: kdig -d @199.58.81.218 -p 443 +tls-ca +tls-host=dns.cmrg.net example.com https:/www.dnsleaktest.com/ https://www.perfect-privacy.com/dns-leaktest/ https://www.grc.com/dns/dns.htm http://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/ See here for TorGuard Open VPN Setup https://torguard.net/forums/index.php?/topic/1247-lede-openwrt-torguard-vpn-setup/ And now you are cooking with plenty of Gas - c'est fini c'est manifique c'est ci bon
  19. So I see TorGuard now provides 'residential streaming IPs'. Sounds very promising. However, if I just need streaming, and because most browsing is now over TLS, I don't need any VPN encryption at all (which coincidentally is the bottleneck with 99% of routers). So ideally I'd pay for, say, an NYC residential IP address, and use my Ubiquity EdgeRouter-Lite (which is not speedy at all when used with OpenVPN and can't use hardware for L2TP encryption), so I'd get the maximum possible speed. My question: Is it possible to configure some sort of PPTP-client for TorGuard with no encryption whatsoever?
  20. READ ENTIRE GUIDE BEFORE YOU BEGIN This Tutorial / Guide Was Updated on Jan 15 2020 in order to keep you in step with changes on packages needed for OpenWrt 19.07.0 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 DNS OVER TLS FOR getdns 1.4.2-2 stubby 0.2.3-3 and unbound 1.8.1-2 See here for GETDNS AND STUBBY on OPENWRT / LEDE: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md - this page is designed for DNS OVER TLS with DNSMASQ but it still is useful and informative . You may also choose to use DNS OVER TLS with DNSMASQ. However, that is not the focus of this tutorial. See Here For OPENWRT STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING https://forum.openwrt.org/t/stubby-dns-over-tls-using-dnsmasq-full-for-dnssec-caching/19107 There have been some changes to DNS OVER TLS From The DNS Privacy Project. Here is how to get this up and running. Much remains the same but be aware of the changes from the original guides which I will point out to you along the way. Original posts here: https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 and here: https://torguard.net/forums/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ By the way I run Davidc502 LEDE Snapshots - Moderately Customized LEDE Development Builds for Linksys 1900ac v.1 and 1900ac v.2, 1900acs v.1 v.2, 3200acm, WRT32X and 1200ac v.1 v.2 series routers. These builds keep up to date package repositories.. GetDns and Stubby are included. Dave's Builds have many other pre-installed common packages as well.. Check out homepage and downloads here: https://davidc502sis.dynamic-dns.net/ and downloads here: https://davidc502sis.dynamic-dns.net/snapshots/ . In addition, there is a very informative, instructive and active thread ( forum ) for Dave's builds and discussion of many OpenWrt / Lede packages, features, and issues. In short great technical advice and assistance can be found here: https://forum.openwrt.org/t/davidc502-wrt1200ac-wrt1900acx-wrt3200acm-wrt32x-builds/ Dave releases new updated builds every two weeks - near the middle and first of each month. I tell you the above because I always have the most up to date packages, linux kernel, wifi drivers and so on. This tutorial may not be for you if you do not have the versions of the software listed in the header of this post. OK - here we go once again. 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 - This setup is specifically designed for GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. You can use odhcpd which will handle both DNS and DHCP where you disable and/ or remove DNSMASQ - but you will experience a performance hit. This why I use Unbound/ STUBBY for DNS and Dnsmasq for DHCP. Here is a basic guide as to how to do it - https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/Torsten's Thoughtcrimes However a few modifications are necessary in order to to have GetDns and Stubby up and running and successfully integrated with Unbound DNS and Dnsmasq for DHCP. Refer to this guide while following along with me : https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/ As always - opkg update first and foremost Prerequisite You have a ca cert bundle installed on your router. You can do this by running the following opkg install ca-certificates Now Let’s Move On 1 - opkg update ; opkg install unbound-daemon-heavy unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host unbound-checkconf odhcpd 2 - opkg update ; opkg install stubby getdns As per Torsten's Thoughtcrimes Guide: 3- My WORKING CONFIGS /etc/unbound/unbound_srv.conf ( You Must Adjust For Your Router - I Run WRT1900ACS and WRT3200ACM So I Have Plenty Of Ram, Storage and 2 CPU's ) You should " Optimize Unbound " - especially increase size of cache among other things see guide here and adjust for your router's memory , number of cores and so on- see here: https://nlnetlabs.nl/documentation/unbound/howto-optimise/ for basic guide cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF server: # use all CPUs num-threads: 2 # power of 2 close to num-threads msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 # more cache memory, rrset=msg*2 rrset-cache-size: 256m msg-cache-size: 128m # more outgoing connections # depends on number of cores: 1024/cores - 50 outgoing-range: 8192 # Larger socket buffer. OS may need config. so-rcvbuf: 4m so-sndbuf: 4m cache-min-ttl: 600 cache-max-ttl: 14400 hide-trustanchor: yes infra-cache-numhosts: 100000 num-queries-per-thread: 4096 max-udp-size: 2048 minimal-responses: yes rrset-roundrobin: yes do-tcp: yes do-ip6: no prefetch: yes prefetch-key: yes qname-minimisation: yes qname-minimisation-strict: yes so-reuseport: yes unwanted-reply-threshold: 10000000 interface-automatic: yes do-not-query-localhost: no use-caps-for-id: yes verbosity: 1 private-domain: "your.domain" harden-referral-path: yes target-fetch-policy: "0 0 0 0 0" val-clean-additional: yes UNBOUND_SERVER_CONF As per Torsten's Thoughtcrimes Guide : Don’t let each server know the next recursion Enter via SSH command line: uci set ‘[email protected][0].query_minimize=1’ 4 - Here is where a major change takes place. On getdns 1.4.2-2 and stubby 0.2.3-3 the /etc/stubby/stubby.yml file DOES NOT control the configuration of STUBBY by default. This has been replaced by the UCI system and the file /etc/config/stubby. I believe that this change to UCI was made to allow for DNSMASQ handling DNS OVER TLS. However, if you are like me - I prefer to still use UNBOUND and this how to do it. See below which is at the top of the /etc/stubby/stubby.yml file - which used to be the only file to configure STUBBY: nano /etc/stubby/stubby.yml - open file and you will see: # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. 5 - To keep this simple - go into default UCI STUBBY file which is /etc/config/stubby by entering nano /etc/config/stubby and then set option manual '1' - if you leave it at default setting of option manual 'o' you will not be able to use the /etc/stubby/stubby.yml file in order to configure STUBBY as before. So, after changing option manual '1' in the /etc/config/stubby file - configure /etc/stubby/stubby.yml as follows: See here for how to configure Stubby: https://github.com/getdnsapi/stubby DNS OVER TLS ABSOLUTE BEST CONFIGURATION FOR STUBBY FOR THE REASONS DETAILED BELOW: nano /etc/stubby/stubby.yml - replace contents of file with configuration below: 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/ 1 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 August 21 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 # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 9000 listen_addresses: - [email protected] dns_transport_list: - GETDNS_TRANSPORT_TLS tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 tls_ca_path: "/etc/ssl/certs/" 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 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= ## 10 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 94.130.106.88 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 11 - The Foundation for Applied Privacy DNS TLS Server #2 A+ ( AUT ) - address_data: 93.177.65.183 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 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: Bt3fAHJeDPU2dneCx9Md6zTiKhzWtZ152To0j0f32Us= ## 13 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN ) - address_data: 115.159.131.230 tls_auth_name: "dns.rubyfish.cn" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo= ## 14 - 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/ ## 15 - The DNSPRIVACY.at TLS Server #1 A+ ( DEU ) - address_data: 94.130.110.185 tls_auth_name: "ns1.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fr9YdIAIg7TXJLLHp0XbeWKBS2utev0stoEIb+7rZjM= ## 16 - The DNSPRIVACY.at TLS Server #2 A+ ( DEU ) - expired 2020-04-01 - address_data: 94.130.110.178 tls_auth_name: "ns2.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo= # 17 - 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= ## 18 - 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: OvqVajUX+2j/xfYqPZid2Z8DMX2Vex8geaYw0UG77BE= ### Publicly Available DOT Test Servers ### ## 19 - 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: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 20 - 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: fiOT+xcarY8uz1UBZ0DzA+Gi5kcSHdBDrofcsZL3HGo= ## 21 - 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: BrjhBir4pbQ0+uTjlViVlc5qf1172WLQxDWevO/4bKI= ## 22 - 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: 1Mu+KSivSkoBfLiCzL+8xhg1YO7xmAjPJAJkjrv5ZvA= ## 23 - 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= ## 24 - 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: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= ## 25 - 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: OHdm30CP5hu1KI1bLnIokKL1eKbLNWQvN9bNsXb5TJQ= ## 26 - 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: W0CoacPgp4VP2zsOt2ERQuFqXTG37ud5t3ClB5Xh7dY= ## 27 - 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: NZqlaEd1y4tc4z2s/GcclhKlOQtynBKtbomw1dVCydU= ## 28 - 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: +Q7ZdLW0QXokd2OY/vUJm10ZAnm2KFC+ovJfm5++hDc= ## 29 - 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: +zKyo0IWR+e38Yw2KN7pMAkktQSjZUGN4h7BoYLytTk= ## 30 - 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: gWjnc5JNaub1U83vNZtyY/7f1ZYH+Zwt+LWLeTzbLEU= ## 31 - 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: R9/K3atF+ZHuBAVREmFiTX5N0qse+JIqoMF+usZ2dZg= ## 32 - 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: oZQKQh794UHpdtZc/7CG+9VUw+3uGIrQFfAhCvYcds4= ## 33 - 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: ZdED9Ry+FfdsbpGVr2IxR/IB0D7FaVpSBWvsRWutrjg= ## 34 - 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: xb6yo+7vmxFhyrA+NV1ZOKBGHuA03J4BjTwkWjZ3uZk= ## 35 - 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: 0oVEbW/240sc4++zXjICyOO4XKTIEewY9zY5G5v9YnY= ## 36 - 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: 3dV7cgTZbmHD/JTfocBI6FvoyGevpZf2n5k2fG4uVr8= ## 37 - 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: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE= ## 38 - 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: Ua+l/cIZ9dbJPExk4grit6qFZWmQZcoIoMBvMLwUDHc= ## 39 - 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: P8A1QEHTXs7QSmAuwR4FupMd3L/OW9TXbTXcFaazzoU= ## 40 - 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: ncPZ5vhEPiv7VOf2nesJW9GYOGZ48MsAhzd4PO+3NJQ= ## 41 - 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: 8ZpLg8m7CE41EnXddCRJGsaWK2UVjy2UnhPo/7BsPIo= ## 42 - 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: 9QRO8JyJCVMU+KAO9acW5xfQnSXRuj1OqAz5aZHwH+4= ## 43 - The Hostux DNS TLS Server A+ ( LUX ) - address_data: 185.26.126.37 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= ## 44 - 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= ## 45 - 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= # 46 - 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: vAgfcoO9rzejY7Pdv9MK9DymLvYYJ4PF5V1QzReF4MU= # 47 - The doh.defaultroutes.de DNS TLS Server A+ ( DEU ) - address_data: 5.45.107.88 tls_auth_name: "doh.defaultroutes.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0= ## 48 - 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= # 49 - 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= ## 50 - 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: wnJgPKtu/QHXHx3QZ7mZuIsNMv85buI5jsdsS9cTU5w= ## 51 - 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: +rBZZHFEVTmFwA8RuR9I5vdPqqaBSighP7rcoWgY9MI= ## 52 - The Arapurayil DNS TLS Server A+ ( AUS ) - address_data: 3.7.156.128 tls_auth_name: "dns.arapurayil.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c3S8JssMSrXuMjDfjwzXHoO4RQckTYTTeUThdW+meo0= ## 53 - 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= ## 54 - 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= ### Anycast Publicly Available DOT Test Servers ### ## 55 - The NixNet Uncensored Anycast DNS TLS Servers ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= ## 56 - 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 ### ## 57 - 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= ## 58 - The Comss.one DNS TLS Server #1 A+ ( CHN ) - address_data: 92.38.152.163 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 59 - The Comss.one DNS TLS Server #2 A+ ( CHN ) - address_data: 93.115.24.205 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 60 - The Comss.one DNS TLS Server #3 A+ ( CHN ) - address_data: 93.115.24.204 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= # 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_28_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 In order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby instance, OpenWrt must have OpenSSL 1.1.1 active and configured in the kernel. Any OpenWrt 18.06 Build does not offer OpenSSL 1.1.1 in any shape, form or fashion. OpenWrt 19.07.0 Release Candidates and Snapshots do provide OpenSSL 1.1.1 support. As I have mentioned, I run Davidc502 OpenWrt Snapshots - moderately customized Builds for Linksys wrt1200ac wrt1900acx wrt3200acm wrt32x Routers found here: https://dc502wrt.org/ - These Builds come out approximately every two weeks with the latest Linux Kernels, software packages and other bleeding edge features including OpenSSL 1.1.1 with TLSv1.3 support. Once you have OpenSSL 1.1.1 with TLSv1.3 simply follow the guide 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 168.235.81.167:853 OR : openssl s_client 159.69.198.101: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 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. 6 - Now from the Torsten's Thoughtcrimes Guide again - My WORKING CONFIG /etc/unbound/unbound_ext.conf cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] UNBOUND_FORWARD_CONF 7 - Once again follow the steps in Torsten's Thoughtcrimes Guide # Move dnsmasq to port 53535 where it will still serve local DNS from DHCP # Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535 uci set '[email protected][0].port=53535' # Configure dnsmasq to send a DNS Server DHCP option with its LAN IP # since it does not do this by default when port is configured. uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)" uci set '[email protected][0].dhcp_link=dnsmasq' # Save & Apply (will restart dnsmasq, DNS unreachable until unbound is up) uci commit # Restart (or start) unbound (System -> Startup -> unbound -> Restart) /etc/init.d/unbound restart 8 - From https://github.com/openwrt/packages/tree/master/net/unbound/files HOW TO Integrate with DHCP Parallel DNSMASQ nano /etc/config/dhcp After Some Reflection and Observations - Fine Tuning Your DNS Resolver After reading System Logs I realized that there is a need to amend DNSMASQ ( DHCP ) after implementing option noresolv ‘1’ in /etc/config/dhcp configuration file. This dawned on me from my years of running DNSCRYPT Proxy on OpenWrt. I referred to this guide: Go to this section near bottom of page. Use specific DNS server to lookup one or more host names https://www.leowkahman.com/2016/05/23/openwrt-encrypted-dns-lookup-using-multiple-dnscrypt-servers/ option noresolv ‘1’ is to prevent using any upstream DNS server other than those specified in this file # this file being: /etc/config/dhcp Solution is as follows add these two lines to /etc/config/dhcp: or using UCI uci add_list [email protected][-1].server='127.0.0.1#5453' uci set [email protected][-1].noresolv=1 uci commit && reload_config or nano /etc/config/dhcp - enter these lines before / option domain ‘yourdomain’ list server '127.0.0.1#5453' # Stubby/Unbound Default Address/Port option noresolv ‘1’ # Make sure to change this as indicated After you complete all the steps in this tutorial and restart your Router Check Status > System Log - You will find an entry like the one below: daemon.info dnsmasq[8532]: using nameserver 127.0.0.1#5453 - which indicates that your OpenWrt Router is using Unbound and Stubby for Encrypted DNS Resolution 9 - Now go to the default UNBOUND configuration file /etc/config/unbound and enter the following : Open file by SSH nano /etc/config/unbound - then only replace the config unbound - leave the config zone entries as they are config unbound option dns64 '0' option edns_size '4096' option extended_luci '1' option hide_binddata '1' option enabled '1' option listen_port '53' option localservice '1' option luci_expanded '1' option manual_conf '0' option rebind_localhost '0' option rebind_protection '1' option recursion 'passive' option resource 'medium' option root_age '9' option ttl_min '120' option unbound_control '2' option validator '1' option validator_ntp '1' option query_minimize '1' option query_min_strict '1' option dhcp_link 'dnsmasq' option protocol 'ip4_only' option prefetch_root '0' option extended_stats '1' list trigger_interface 'lan' list trigger_interface 'wan' 10 - For DNS OVER TLS resolution add Custom DNS resolver as follows: using UCI uci set network.wan.peerdns='0' uci set network.wan.dns='127.0.0.1' uci set network.wan6.peerdns='0' # if you use Stubby for IPV6 uci set network.wan6.dns='0::1' # if you use Stubby for IPV6 uci commit or Via Luci Interface Under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Server 127.0.0.1 - 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. 11 - VERY IMPORTANT STEP - after setting your DNS to 127.0.0.1 ( you need 127.0.01 as this is what both Stubby and Unbound use as their local resolver ) You must run /etc/init.d/unbound restart one more time. When you do this you will see that your unbound root.key will be installed to /var/lib/unbound/root.key and also it will install root.key to /etc/unbound/root.key. This will automatically configure DNSSEC on your router. The function also lists your auto-trust anchor in your /var/lib/unbound/unbound.conf file. 12 - 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 - You need to opkg install drill and - then run command : drill txt qnamemintest.internet.nl and / or B - opkg install bind-dig or opkg install bind-tools with 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 in " /etc/unbound/unbound_srv.conf " file. qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes 13 - I have found that for whatever reasons it is best to make these entries in startup in order for stubby and unbound to fire up after a reboot. On boot, in case GetDns and Stubby fails to start. This is very likely due to Internet connection not available yet at time of starting Unbound GetDns and Stubby. In such a case, the workaround is to wait for Internet connection to be available before restarting Unbound GetDns and Stubby. Add the following lines into /etc/rc.local: You may also enter these additions via Luci menu Startup > Local Startup nano /etc/rc.local # Put your custom commands here that should be executed once # the system init finished. By default this file does nothing. # Wait until Internet connection is available for i in {1..60}; do ping -c1 -W1 99.192.182.100 &> /dev/null && break; done # Restart DNS Privacy Daemon - Stubby as it requires a successful #time sync for its encryption to work/ /etc/init.d/unbound restart /etc/init.d/stubby restart /etc/init.d/openvpn restart #If you run VPN as you should exit 0 14 - You will now be running DNS OVER TLS with GETDNS and Stubby on LEDE / OpenWrt Make sure to follow this guide precisely and it works GREAT!!! You can check logs under Services > Recursive DNS > Status > Log - you will see that you have a caching encrypted DNS Resolver !!! Bonus Setup Option ( Highly Recommended ) - Install WatchCat http://www.ibuyopenwrt.com/index.php/2-uncategorised/224-watchcat-reboot-on-internet-drop I set "Reboot on Internet Connection Lost" option. I have WatchCat set to ping Fourth Estate DNS address - 179.43.139.226 - every 20 minutes. This will keep your router up and running consistently. 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 is a sure fire method 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 opkg install gnutls-utils 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 There is also a third option. kdig -d @185.49.141.37 +tls-ca +tls-host=getdnsapi.net example.com - where you must install knot-dig / opkg install knot-dig This is my personal favorite as the readout from this command will list the certificate specifically like so: ;; DEBUG: #1, CN=getdnsapi.net ;; DEBUG: SHA-256 PIN: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= and let you know that the certificate is valid like so: ;; DEBUG: TLS, The certificate is trusted. Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable. To use kdig certificate verification method on an alternate port example: kdig -d @199.58.81.218 -p 443 +tls-ca +tls-host=dns.cmrg.net example.com 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. Lastly, you can check your DNS at GRC Spoofability Test - DNS Leak - or any of 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. https://www.dnsleaktest.com/ https://www.perfect-privacy.com/dns-leaktest/ https://www.grc.com/dns/dns.htm http://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/ See here for TorGuard Open VPN Setup https://torguard.net/forums/index.php?/topic/1247-lede-openwrt-torguard-vpn-setup/ And now you are cooking with plenty of Gas - c'est fini c'est manifique c'est ci bon Peace and Grace Unto All, directnupe Parting Thoughts: My reason for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file is for the following reasons. 1- I found that I had more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. 2 - In my testing UCI system /etc/config/stubby file configurations did not work well with UNBOUND. As I said, I believe that this is for native DNSMASQ on Openwrt. For instance, there is an entry option appdata_dir '/var/lib/stubby' - this is for Stubby to do DNSSEC as DNSMASQ does do not do this. 3 - In short, I prefer UNBOUND along with STUBBY and GETDNS as NLnet Labs develops all of these components which were constructed to implement DNS OVER TLS ( aka DNS PRIVACY ). I am sure that they will do their best to make sure that all of these components work well together. Others may think otherwise and I respect that. However, 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.
  21. This tutorial speaks for itself Supplement for Topic: https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 These are the best DNS PRIVACY NAME SERVERS for the detailed reasons listed below. Edit your /etc/stubby/stubby.yml - SSH and enter nano /etc/stubby/stubby.yml - Use these listed below for Stubby configuration. See here for correct format and layout: https://torguard.net/forums/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ In order to save you some time - here is a list of IPV4 DNS PRIVACY Name Servers which are QNAME minimisation enabled: This list contains in order Hostname for TLS authentication, IP address, TLS Port ( s ) and SPKI pin getdnsapi.net 185.49.141.37 853 foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9S= iana.tenta.io 99.192.182.200 853 nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0= kaitain.restena.lu 158.64.1.29 853 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4= dnsovertls2.sinodun.com 145.100.185.17 853 NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg= dns.cmrg.net 199.58.81.218 853 or 443 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= dot.securedns.eu 146.185.167.43 853 or 443 h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= ns1.dnsprivacy.at 94.130.110.185 853 vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY= ns2.dnsprivacy.at 94.130.110.178 853 s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg= dns.neutopia.org 89.234.186.112 853 or 443 wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= In order to save you some time - here is a list of IPV6 DNS PRIVACY Name Servers which are QNAME minimisation enabled: This list contains in order Hostname for TLS authentication, IP address, TLS Port ( s ) and SPKI pin getdnsapi.net 2a04:b900:0:100::37 853 foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9S= cloudflare-dns.com 2606:4700:4700::1111( or 1001 ) 853 yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= kaitain.restena.lu 2001:a18:1::29 853 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4= dnsovertls2.sinodun.com 2001:610:1:40ba:145:100:185:17 853 NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg= dns.cmrg.net 2001:470:1c:76d::53 53053/853/ or 443 5zFN3smRPuHIlM/8L+hANt99LW26T97RFHqHv90awjo= dot.securedns.eu 2a03:b0c0:0:1010::e9a:3001 853/443 h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= ns1.dnsprivacy.at 2a01:4f8:c0c:3c03::2 853 vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY= ns2.dnsprivacy.at 2a01:4f8:c0c:3bfc::2 853 s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg= dns.neutopia.org 2a00:5884:8209::2 853 /443 wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= 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 - You need to opkg install drill and - then run command : drill txt qnamemintest.internet.nl and / or B - opkg install bind-dig or opkg install bind-tools with 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 in " /etc/unbound/unbound_srv.conf " file: qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes For better DNS resolution follow the /etc/config/unbound file in this tutorial below ( where Lan and Wan are Unbound Triggers ) then add DNS resolvers as follows: Under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Servers in order 127.0.0.1, along with Tenta ICANN nameservers 99.192.182.200 and 66.244.159.200 - Your DNS will still resolve using the upstream name servers you selected in stubby.yml - Things Will Work Fine and as Intended. I have found that it is best to use Tenta ICANN DNS name servers as " custom DNS servers " on the Wan interface. I chose Tenta ICANN 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 ICANN DNS as the backbone name servers on OpenWrt: 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. https://tenta.com/dns-setup-guides Working /etc/config/unbound file nano /etc/config/unbound - edit as shown below config unbound option dns64 '0' option edns_size '4096' option extended_luci '1' option extended_stats '0' option hide_binddata '1' option domain 'yourdomain.com' option domain_type 'static' option enabled '1' option listen_port '53' option localservice '1' option luci_expanded '1' option manual_conf '0' option query_min_strict '1' option rebind_localhost '0' option rebind_protection '1' option recursion 'passive' option resource 'medium' option root_age '9' option ttl_min '120' option unbound_control '2' option validator '1' option validator_ntp '1' option query_minimize '1' option dhcp_link 'dnsmasq' option enabled '1' option protocol 'ip4_only' option prefetch_root '0' list trigger_interface 'lan' list trigger_interface 'wan' PS - Tenta DNS OVER TLS does not support IPV6 as of yet - but keep checking the DNS PRIVACY Monitoring Page as these things change frequently and all the time. This whole process is relatively new after all. In this case, under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Servers in order Local host 127.0.0.1 and Cloudflare DNS 1.1.1.1 and 1.0.0.1 - Cloudflare supports DNS OVER TLS as well. I am not quite sure if you should enter Cloudflare DNS IPV6 Name Servers ( 2606:4700:4700::1111 and 2606:4700:4700::1001 ) here in the case you are using IPV6 blended with IPV4 or IPV6 exclusively.
  22. This Tutorial / Guide Was Updated on Jan 19 2020 in order to keep you in step with changes on packages needed for OpenWrt 19.07.0 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 READ ENTIRE GUIDE BEFORE YOU BEGIN See here for GETDNS AND STUBBY on OPENWRT / LEDE: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md OPENWRT STUBBY DNS OVER TLS USING UNBOUND: https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 https://torguard.net/forums/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ I have written tutorials where DNS OVER TLS setup is focused on deploying UNBOUND STUBBY and GETDNS along with DNSMASQ for DHCP on OPENWRT/LEDE. Thanks to my good friend Specimen ( see his tutorial / guide here : https://forum.openwrt.org/t/tutorial-dns-over-tls-with-dnsmasq-and-stubby-no-need-for-unbound/18663 - I was able to realize that we can eliminate UNBOUND all together for those who wish to do so for any number of reasons. For those of you who that may have limited memory or storage available on your router and you need more storage and swap memory for your router see here: http://ediy.com.my/index.php/blog/item/118-how-to-increase-storage-on-tp-link-tl-mr3020-with-extroot and here: https://samhobbs.co.uk/2013/11/more-space-for-packages-with-extroot-on-your-openwrt-router -Specimen's tutorial features a method to install STUBBY and GETDNS to RAM very smartly and efficiently as well - that will not be covered here as I have found that DNSMASQ-FULL is a better solution in my opinion. 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 DNSMASQ-FULL 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 - So - let's get started with no further ado: 2 - A - opkg update B - opkg install ca-certificates C - opkg install stubby ( GETDNS and LIBYAML will be installed as dependencies ) 3 - This guide aforementioned at the top of this page: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md is the one I followed. However, the only issue is that the guide gives one several options as to how to deploy STUBBY and GETDNS with DNSMSQ and / or DNSMSQ-FULL. With the availability of options just may come confusion and mistakes. So, the purpose of this tutorial is to demonstrate how to eliminate potential errors during setup of STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING as the title asserts. 4 - I chose to use the /etc/stubby/stubby.yml file to configure STUBBY. My reasons for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file are for several reasons. I found that I have more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. So in order to use /etc/stubby/stubby.yml file, you must change a default setting in the /etc/config/stubby file to allow manual configuration. 5 - To keep this simple - go into default UCI STUBBY file which is /etc/config/stubby by entering nano /etc/config/stubby and then set option manual '1' - if you leave it at default setting of option manual 'o' you will not be able to use the /etc/stubby/stubby.yml file in order to configure STUBBY as before. So, after changing option manual '1' in the /etc/config/stubby file - configure /etc/stubby/stubby.yml as follows: 6 - The next step is to configure /etc/stubby/stubby.yml file in the standard fashion. Note that DNSSEC is not configured in STUBBY as DNSMASQ-FULL will be configured to implement this feature later on in this process. Here is my /etc/stubby/stubby.yml file nano /etc/stubby/stubby.yml : Stubby github config: https://raw.githubusercontent.com/getdnsapi/stubby/develop/stubby.yml.example 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/ 1 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 August 21 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 # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 9000 listen_addresses: - [email protected] dns_transport_list: - GETDNS_TRANSPORT_TLS tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 tls_ca_path: "/etc/ssl/certs/" 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 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= ## 10 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 94.130.106.88 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 11 - The Foundation for Applied Privacy DNS TLS Server #2 A+ ( AUT ) - address_data: 93.177.65.183 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU= ## 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: Bt3fAHJeDPU2dneCx9Md6zTiKhzWtZ152To0j0f32Us= ## 13 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN ) - address_data: 115.159.131.230 tls_auth_name: "dns.rubyfish.cn" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo= ## 14 - 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/ ## 15 - The DNSPRIVACY.at TLS Server #1 A+ ( DEU ) - address_data: 94.130.110.185 tls_auth_name: "ns1.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fr9YdIAIg7TXJLLHp0XbeWKBS2utev0stoEIb+7rZjM= ## 16 - The DNSPRIVACY.at TLS Server #2 A+ ( DEU ) - expired 2020-04-01 - address_data: 94.130.110.178 tls_auth_name: "ns2.dnsprivacy.at" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo= # 17 - 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= ## 18 - 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: OvqVajUX+2j/xfYqPZid2Z8DMX2Vex8geaYw0UG77BE= ### Publicly Available DOT Test Servers ### ## 19 - 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: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 20 - 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: fiOT+xcarY8uz1UBZ0DzA+Gi5kcSHdBDrofcsZL3HGo= ## 21 - 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: BrjhBir4pbQ0+uTjlViVlc5qf1172WLQxDWevO/4bKI= ## 22 - 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: 1Mu+KSivSkoBfLiCzL+8xhg1YO7xmAjPJAJkjrv5ZvA= ## 23 - 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= ## 24 - 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: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= ## 25 - 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: OHdm30CP5hu1KI1bLnIokKL1eKbLNWQvN9bNsXb5TJQ= ## 26 - 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: W0CoacPgp4VP2zsOt2ERQuFqXTG37ud5t3ClB5Xh7dY= ## 27 - 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: NZqlaEd1y4tc4z2s/GcclhKlOQtynBKtbomw1dVCydU= ## 28 - 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: +Q7ZdLW0QXokd2OY/vUJm10ZAnm2KFC+ovJfm5++hDc= ## 29 - 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: +zKyo0IWR+e38Yw2KN7pMAkktQSjZUGN4h7BoYLytTk= ## 30 - 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: gWjnc5JNaub1U83vNZtyY/7f1ZYH+Zwt+LWLeTzbLEU= ## 31 - 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: R9/K3atF+ZHuBAVREmFiTX5N0qse+JIqoMF+usZ2dZg= ## 32 - 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: oZQKQh794UHpdtZc/7CG+9VUw+3uGIrQFfAhCvYcds4= ## 33 - 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: ZdED9Ry+FfdsbpGVr2IxR/IB0D7FaVpSBWvsRWutrjg= ## 34 - 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: xb6yo+7vmxFhyrA+NV1ZOKBGHuA03J4BjTwkWjZ3uZk= ## 35 - 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: 0oVEbW/240sc4++zXjICyOO4XKTIEewY9zY5G5v9YnY= ## 36 - 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: 3dV7cgTZbmHD/JTfocBI6FvoyGevpZf2n5k2fG4uVr8= ## 37 - 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: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE= ## 38 - 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: Ua+l/cIZ9dbJPExk4grit6qFZWmQZcoIoMBvMLwUDHc= ## 39 - 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: P8A1QEHTXs7QSmAuwR4FupMd3L/OW9TXbTXcFaazzoU= ## 40 - 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: ncPZ5vhEPiv7VOf2nesJW9GYOGZ48MsAhzd4PO+3NJQ= ## 41 - 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: 8ZpLg8m7CE41EnXddCRJGsaWK2UVjy2UnhPo/7BsPIo= ## 42 - 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: 9QRO8JyJCVMU+KAO9acW5xfQnSXRuj1OqAz5aZHwH+4= ## 43 - The Hostux DNS TLS Server A+ ( LUX ) - address_data: 185.26.126.37 tls_auth_name: "dns.hostux.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE= ## 44 - 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= ## 45 - 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= # 46 - 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: vAgfcoO9rzejY7Pdv9MK9DymLvYYJ4PF5V1QzReF4MU= # 47 - The doh.defaultroutes.de DNS TLS Server A+ ( DEU ) - address_data: 5.45.107.88 tls_auth_name: "doh.defaultroutes.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0= ## 48 - 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= # 49 - 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= ## 50 - 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: wnJgPKtu/QHXHx3QZ7mZuIsNMv85buI5jsdsS9cTU5w= ## 51 - 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: +rBZZHFEVTmFwA8RuR9I5vdPqqaBSighP7rcoWgY9MI= ## 52 - The Arapurayil DNS TLS Server A+ ( AUS ) - address_data: 3.7.156.128 tls_auth_name: "dns.arapurayil.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c3S8JssMSrXuMjDfjwzXHoO4RQckTYTTeUThdW+meo0= ## 53 - 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= ## 54 - 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= ### Anycast Publicly Available DOT Test Servers ### ## 55 - The NixNet Uncensored Anycast DNS TLS Servers ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug= ## 56 - 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 ### ## 57 - 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= ## 58 - The Comss.one DNS TLS Server #1 A+ ( CHN ) - address_data: 92.38.152.163 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 59 - The Comss.one DNS TLS Server #2 A+ ( CHN ) - address_data: 93.115.24.205 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= ## 60 - The Comss.one DNS TLS Server #3 A+ ( CHN ) - address_data: 93.115.24.204 tls_port: 853 tls_auth_name: "dns.comss.one" tls_pubkey_pinset: - digest: "sha256" value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4= # 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_28_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 In order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby instance, OpenWrt must have OpenSSL 1.1.1 active and configured in the kernel. Any OpenWrt 18.06 Build does not offer OpenSSL 1.1.1 in any shape, form or fashion. OpenWrt 19.07.0 Release Candidates and Snapshots do provide OpenSSL 1.1.1 support. As I have mentioned, I run Davidc502 OpenWrt Snapshots - moderately customized Builds for Linksys wrt1200ac wrt1900acx wrt3200acm wrt32x Routers found here: https://dc502wrt.org/ - These Builds come out approximately every two weeks with the latest Linux Kernels, software packages and other bleeding edge features including OpenSSL 1.1.1 with TLSv1.3 support. Once you have OpenSSL 1.1.1 with TLSv1.3 simply follow the guide 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 168.235.81.167:853 OR : openssl s_client 159.69.198.101: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 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 7 - Integration of STUBBY with DNSMASQ A - Set DNSMASQ to send DNS requests to STUBBY - this is done to allow Localhost ( 127.0.0.1 ) on port 5453 to be the sole resolver used by your router. This forces router to use DNS OVER TLS as STUBBY listens on the default address / port 127.0.0.1#5453 . There are two methods to do this: uci add_list [email protected][-1].server='127.0.0.1#5453' uci set [email protected][-1].noresolv=1 uci commit Or edit the /etc/config/dhcp file nano /etc/config/dhcp list server '[email protected]' option noresolv '1' 8 - Disable Sending DNS Requests to ISP Provided DNS Servers uci set network.wan.peerdns='0' uci set network.wan.dns='127.0.0.1' uci set network.wan6.peerdns='0' # If you use STUBBY for IPV6 uci set network.wan6.dns='0::1' # If you use STUBBY for IPV6 uci commit Or In the Luci Web interface under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Server 127.0.0.1 - 9 - Now restart DNSMASQ and enable, start and restart STUBBY just to make sure everything is up and running before you proceed. Run the following commands: /etc/init.d/dnsmasq restart /etc/init.d/stubby enable /etc/init.d/stubby start /etc/init.d/stubby restart 10 - Enabling DNSSEC - We are going to use DNSMASQ-FULL in order to enable this feature. This one command removes DNSMASQ and installs DNSMASQ-FULL. In order to achieve this end, enter this as one command: A - opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk 11 - We are now going to configure STUBBY not to perform DNSSEC validation and configure DNSMASQ-FULL to require DNSSEC validation. We do so by entering the following commands via UCI: uci set [email protected][-1].dnssec=1 uci set [email protected][-1].dnsseccheckunsigned=1 uci commit Or edit the /etc/config/dhcp file nano /etc/config/dhcp option dnssec '1' option dnsseccheckunsigned '1' To verify DNSSEC trust-anchors, this is how to do it ( 1 ) trust-anchors are here: TRUSTANCHORSFILE="/usr/share/dnsmasq/trust-anchors.conf" so in SSH shell issue command : cat /usr/share/dnsmasq/trust-anchors.conf - and Voila' - Whoop There It Is ! 12 - Now I am used to running UNBOUND so I accustomed its' caching feature. To increase DNSMASQ-FULL cache use one of these two methods: A - Via UCI (Unified Configuration Interface) - in shell uci set [email protected][0].cachesize=1000 uci commit dhcp Or edit the /etc/config/dhcp file nano /etc/config/dhcp option cachesize '1000' Now restart DNSMASQ and restart STUBBY once again: /etc/init.d/dnsmasq restart /etc/init.d/stubby restart 13 - I have found that for whatever reasons it is best to make these entries in startup in order for STUBBY and DNSMASQ-FULL to fire up after a reboot. On boot, in case GETDNS and STUBBY fails to start. This is very likely due to Internet connection not available yet at time of starting DNSMASQ-FULL GETDNS and STUBBY. In such a case, the workaround is to wait for Internet connection to be available before restarting DNSMASQ-FULL GETDNS and STUBBY. The solution is to add the following lines into /etc/rc.local: You may also enter these additions via Luci menu Startup > Local Startup nano /etc/rc.local # Put your custom commands here that should be executed once # the system init finished. By default this file does nothing. # Wait until Internet connection is available for i in {1..60}; do ping -c1 -W1 99.192.182.100 &> /dev/null && break; done # Restart DNS Privacy Daemon - Stubby as it requires a successful #time sync for its encryption to work/ /etc/init.d/dnsmasq restart /etc/init.d/stubby restart /etc/init.d/openvpn restart #If you run VPN as you should exit 0 Reboot your router just to make sure everything is running as designed. 14 - Two quick command line tests for you to conduct after rebooting your router: A - DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy. The name servers listed I use help to consistently ensure QNAME Minimisation functions as designed. The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. You need to opkg install bind-tools or opkg install bind-dig command : dig txt qnamemintest.internet.nl +short and / or dig -t txt qnamemintest.internet.nl 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. B - DNSSEC TEST - command : dig dnssectest.sidn.nl +dnssec +multi @127.0.0.1 Look at the flags section. You should see : ;; flags: qr rd ra ad; As long as you get ad flag as you should, you now have verified DNSSEC as well. 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 opkg install gnutls-utils 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 There is also a third option. kdig -d @185.49.141.37 +tls-ca +tls-host=getdnsapi.net example.com - where you must install knot-dig / opkg install knot-dig This is my personal favorite as the readout from this command will list the certificate specifically like so: ;; DEBUG: #1, CN=getdnsapi.net ;; DEBUG: SHA-256 PIN: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= and let you know that the certificate is valid like so: ;; DEBUG: TLS, The certificate is trusted. Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable. To use kdig certificate verification method on an alternate port example: kdig -d @199.58.81.218 -p 443 +tls-ca +tls-host=dns.cmrg.net example.com Peace Unto All, directnupe Parting Thoughts: I really like this deployment and implementation of DNS OVER TLS. It seems to be very snappy in resolving DNS queries - even a bit more responsive than UNBOUND. It is pretty simple and straight forward to set up and the documentation is very easily understood. Moreover, DNSMASQ is the native resolver for OpenWRT, so this set up minimizes any other components which may bog down your router. In essence, this setup is most clean and elegant in my estimation. Also, DNSMASQ-FULL allows you a more robust resolver than the native install standard DNSMASQ version. DNSMASQ-FULL allows for DNSSEC and QNAME Minimisation. I am using this setup now and I will report back later on; however, for now it is working beautifully.
  23. Hello All, I am the guy - directnupe - who wrote the guides - https://torguard.net/forums/index.php?/topic/1374-adding-dns-over-tls-support-to-openwrt-lede-with-unbound/ and https://forum.lede-project.org/t/adding-dns-over-tls-support-to-openwrt-lede-with-unbound/13765 . You also can leave out GETDNS and STUBBY see here: https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/ # "read all guides to see how to install and run UNBOUND" Prerequisite You have a ca cert bundle installed on your router. You can do this by running the following opkg update / opkg install ca-certificates / opkg install luci-ssl For all of those who are using UNBOUND with tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" # For OpenWrt option: This will have to wait until OpenSSL 1.1.x is included in OpenWrt/Lede or Unbound devs to find a way to validate it without using a function only available in OpenSSL 1.1.x - so the current OpenSSL version ( 1.0.2o ) does not support this feature. If you need more storage and swap memory for your router see here: http://ediy.com.my/index.php/blog/item/118-how-to-increase-storage-on-tp-link-tl-mr3020-with-extroot and here: https://samhobbs.co.uk/2013/11/more-space-for-packages-with-extroot-on-your-openwrt-router For DNS-Over-TLS support to OpenWRT (LEDE) with Unbound without GETDNS and STUBBY - see this article - https://www.ctrl.blog/entry/unbound-tls-forwarding and https://www.monperrus.net/martin/randomization-encryption-dns-requests In OpenWrt / Lede the ca-certificates package is located in /etc/ssl/certs/ca-certificates.crt much like Debian/Ubuntu. So actually as the title of the article says in order to " Actually secure DNS over TLS in Unbound " you should configure it thusly ( using Coudflare and Quad9 for this example - IPV4 and IPV6 if you so choose ) : First go into SSH shell and enter : nano /etc/unbound/unbound_srv.conf enter the following in the new file: server: do-tcp: yes prefetch: yes qname-minimisation: yes rrset-roundrobin: yes use-caps-for-id: yes tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" # For OpenWrt Then hit ( Ctrl + o ) - you will be asked to write file - hit enter to save file then ( Ctrl + x ) to close file and go back into shell Next go into SSH shell and enter : nano /etc/unbound/unbound_ext.conf enter the following in the new file: forward-zone: name: "." forward-addr: 2620:fe::[email protected]#dns.quad9.net forward-addr: [email protected]#dns.quad9.net forward-addr: 2620:fe::[email protected]#dns.quad9.net forward-addr: [email protected]#dns.quad9.net forward-addr: 2606:4700:4700::[email protected]#cloudflare-dns.com forward-addr: [email protected]#cloudflare-dns.com forward-addr: 2606:4700:4700::[email protected]#cloudflare-dns.com forward-addr: [email protected]#cloudflare-dns.com forward-ssl-upstream: yes Then hit ( Ctrl + o ) - you will be asked to write file - hit enter to save file then ( Ctrl + x ) to close file and go back into shell 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 ) Look at bottom of page on reddit post for related entry Peace, directnupe
  24. Dear Staff, I started using vpn service from Torguard and I have no complaints. Just a quick question about the handshake encryption provided by you. It seems that the strongest one from you is 2048 bit RSA while other VPN vendors are providing the maximum of 4096 bit RSA. Do you have any plans to provide 4096 bit RSA in future or any rationale for providing the maximum of 2048 bit RSA. Thanks a lot.
  25. I have a question about using different levels of encryption with Viscosity. I use this page for reference VPN Encryption and Spec. So from reading that page I assume that by default Viscosity comes configured to use BF-CBC, correct? Now if I want to use AES-256-CBC with a specific server all I have to do is change remote server port to 995 and add "cipher AES-256-CBC" to extra openvpn configuration commands, correct? I have done above and everything appears to be working fine. Support told me that using AES-256-CBC with Viscosity was not possible and I should use the TorGuard client instead so I just want for someone who an expert on this to confirm that what I did above is right and works correctly. Thanks!
×
×
  • Create New...