Search the Community

Would request that Torguard have a serious look into using servers being run on RAM only. Benefits of operating servers in RAM include: It's harder for unauthorized person's or groups to gain access to data. Hackers cannot install back doors and hence cannot steal any user private keys. This is because the Operating System and the necessary files are all loaded on boot via a read-only image. This read-only image is hard to compromise because it is cryptographically signed. It is easier to get data from traditional Hard Drives. Even if data is erased, software commonly used by law enforcement can still recover some data. Interested parties with curious and prying eyes can get encryption keys from the server configuration. Additionally, if the server is physically seized, the Hard Drive can be accessed with ease. No VPN provider in the world will take the risk of going to jail if not handing over server logs when court order subpoena to do so. Logs will be handed over. Regardless of no-logs stated claim. RAM-only servers ensure user activities will never fall to unauthorized persons or parties. A simple remote reboot will wipe all the data on the servers. This also bolsters the Torguard's no-log policy. If the servers are physically seized, no Torguard user needs to worry about sensitive data. Torguard can initiate security procedures to reboot the servers remotely. When this happens, all data from the previous session will be lost. A read-only image provides consistency to all of Torguard's servers. Loading an entire software stack at boot gets rid of any mis-configurations. When using Hard Drives, any and all incremental updates can alter some server configurations There will be differences in server configurations and this can lead to vulnerabilities on Torguard's end. A RAM-only Torguard service ensures utmost privacy and security, consistency and performance. Better to have servers on RAM than on physical Hard Drives. Many current VPN providers have servers running on RAM. Torguard should do so as well to remain competitive amongst competing VPN providers. There are only a few selected VPN providers that use the above mentioned for their clients. Torguard is not one of them. Recommend Torguard change to RAM only servers. Please have a serious look into this.

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

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

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.

Hello -- When do you plan to implement TLS v1.3? Just curious.. It's been out for a while now, and as a company in the security business, you'd be ahead of others. Thanks.

Interesting read... https://uk.pcmag.com/torguard-vpn/116817/news/compression-and-vpns-make-for-leaked-secrets

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.

Hello, i guess most people have heard about the cloudbleed bug. if not: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ Since TorGuards Website also uses it, maybe everyone here should change his/her password and activate 2FA.

Not bad at all for simply connecting but as you see, even connecting to torguard brings issues if your ISP is spying on you. This is very good example of something, where other tests show you that everyhing is ok but this test clearly shows you that your ISP is hijacking DNS. You need to have Java installed on your pc to run these tests, it does not work in chrome, but on firefox it does even if using combination of proxifier and foxyproxy (because java tool does all the job, not the browser itself) TEST NOW WITH ANALYZR Good article in german explaining it a little bit and includes the test itself. Send your tests to TorGuard support, they will help you very fast with any leaks, problems or even unintentionally missconfigured device like to open ports which you do not want at all opened. Here is one example (it provides a link which you can send to torguard support if your tests show any issues): More test results (example):