Jump to content
TorGuard

Search the Community

Showing results for tags 'encryption'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • The Lounge
    • TorGuard News
    • Introductions
    • 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
  • 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...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 7 results

  1. READ ENTIRE GUIDE BEFORE YOU BEGIN 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. 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 install unbound odhcpd unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host 2 - opkg install getdns stubby 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: nano /etc/stubby/stubby.yml and change the file content to: resolution_type: GETDNS_RESOLUTION_STUB dns_transport_list: - GETDNS_TRANSPORT_TLS tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private : 1 idle_timeout: 60000 # keep-alive for 1 min, for better performance listen_addresses: - [email protected] #Stubby/Unbound#Default Address/Port round_robin_upstreams: 1 upstream_recursive_servers: # IPV4 Servers # The getdnsapi.net Server - address_data: 185.49.141.37 tls_port: 853 tls_auth_name: "getdnsapi.net" tls_pubkey_pinset: - digest: "sha256" value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= # The Fondation RESTENA Server - address_data: 158.64.1.29 tls_auth_name: "kaitain.restena.lu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4= ### Test servers ### ## Surfnet/Sinodun Servers - address_data: 145.100.185.17 tls_port: 853 tls_auth_name: "dnsovertls2.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg= # The securedns.eu Server - address_data: 146.185.167.43 tls_auth_name: "dot.securedns.eu" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= # The dns.cmrg.net Server - address_data: 199.58.81.218 tls_port: 443 tls_auth_name: "dns.cmrg.net" tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= #The BlahDNS Japan DNS TLS Server - address_data: 108.61.201.119 tls_auth_name: "dns.jp.blahdns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: AoeARyI3TTLqCwrnDI1oPCWjvp2WXJ6Avhl/vF0ntGg= #The BlahDNS German DNS TLS Server - address_data: 217.61.0.97 tls_auth_name: "dns.de.blahdns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: W2Re17OKKn0J+YQLWeQlViGCLstusZN9wt8Rti+7CHw= # DNSPRIVACY.at Primary DNS TLS Server - address_data: 94.130.110.185 tls_port: 853 tls_auth_name: "ns1.dnsprivacy.at" tls_pubkey_pinset: - digest: "sha256" value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY= # DNSPRIVACY.at Secondary DNS TLS Server - address_data: 94.130.110.178 tls_port: 853 tls_auth_name: "ns2.dnsprivacy.at" tls_pubkey_pinset: - digest: "sha256" value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg= # The dns.neutopia.org Server - address_data: 89.234.186.112 tls_port: 443 tls_auth_name: "dns.neutopia.org" tls_pubkey_pinset: - digest: "sha256" value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= # The Lorraine Data Network TLS Server - address_data: 80.67.188.188 tls_auth_name: "ns0.ldn-fai.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM= ### Anycast services ### #Tenta ICANN DNS TLS Primary Server - address_data: 99.192.182.200 tls_auth_name: "iana.tenta.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0= #Tenta OpenNIC DNS TLS Primary Server - address_data: 99.192.182.100 tls_auth_name: "opennic.tenta.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0= #Cloudflare DNS TLS Primary Server - address_data: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= #Cloudflare DNS TLS Secondary Server - address_data: 1.0.0.1 tls_auth_name: "cloudflare-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= 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 - Optionally, enter DNS Servers in order 127.0.0.1, along with Tenta nameservers 99.192.182.200 and 99.192.182.100 - 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 you may use Tenta DNS name servers as " custom DNS servers " on the Wan interface. Tenta DNS is a good choice because their name servers support both emerging DNS privacy standards - DNS-over-TLS, and DNS-over-HTTPS, which both provide last mile encryption to keep your DNS queries private and free from tampering. Tenta DNS also is the only AnyCast DOT service which includes built-in BGP integration, offering single engine convenience for DNS Anycasting with QNAME minimisation enabled on its' name servers by default. Main benefits of Tenta DNS as the backbone name servers on 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 12 - 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. 13 - 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 14 - 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 15 - 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 gnutls-cli --print-cert -p 853 185.49.141.37 - 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.
  2. 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 - 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. 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." This is why I put this all together using Unbound DNS Caching Server. Use Localhost along with Tenta nameservers 99.192.182.200 and 99.192.182.100 for your OpenWrt Router. Tenta DNS is a full-fledged DNS solution, including DNSSEC and DNS-over-TLS. These are the folks that developed and support the Tenta Browser see here: https://github.com/tenta-browser/tenta-dns and read About Tenta section at the very bottom of the page. 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. - Latest Stable Version of OpenWrt / Lede 18.06.1 includes up to date Unbound, GETDNS and STUBBY: ( download and do fresh install of squashfs-factory.img on your device for best performance ) https://downloads.openwrt.org/releases/18.06.1/targets/ as do OpenWrt/LEDE Development Snapshots here: https://downloads.openwrt.org/snapshots/targets/ HINT / TIP: You can add these packages by adding package url repository URL under your " Custom Feeds " if for any reason you need to do so. Remember that the custom feed package url feed must match your router's architecture. For example if you have the Linksys WRT1900ACS then your package feed for your router is listed as Package architecture: arm_cortex-a9_vfpv3 so your custom url feed is : src/gz OpenWrt_packages https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9_vfpv3/packages/ - You can find router's architecture here: https://openwrt.org/toh/start and then look on Device Page and / or Device Techdata. Remember to remove custom feed url after installing your GETDNS and SUBBY packages in order to avoid software package conflicts. 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 install unbound odhcpd unbound-control unbound-control-setup luci-app-unbound unbound-anchor 2 - opkg install getdns stubby 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 # make sure to install libevent outgoing-range: 8192 # Larger socket buffer. OS may need config. so-rcvbuf: 4m so-sndbuf: 4m cache-min-ttl: 600 cache-max-ttl: 14400 qname-minimisation: yes qname-minimisation-strict: yes hide-trustanchor: yes infra-cache-numhosts: 100000 num-queries-per-thread: 4096 minimal-responses: yes rrset-roundrobin: yes do-tcp: yes do-ip6: no prefetch: yes prefetch-key: yes so-reuseport: yes unwanted-reply-threshold: 10000000 interface-automatic: yes max-udp-size: 2048 num-queries-per-thread: 4096 do-not-query-localhost: no verbosity: 1 private-domain: "yourdomain.here" harden-referral-path: yes 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’ 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. The mix of dns.cmrg.net, DNSPRIVACY.at and getdnsapi.net Servers work in an optimal fashion on OpnSense. However, if for any reason you lose internet while running Stubby- chances are it is due to one or more of the servers you are running being down. I told you and it is mentioned on DNSPRIVACY website that all of this ( for the time being ) is experimental. 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://github.com/getdnsapi/stubby/blob/release/0.2.3/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: resolution_type: GETDNS_RESOLUTION_STUB dns_transport_list: - GETDNS_TRANSPORT_TLS tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private : 1 idle_timeout: 60000 # keep-alive for 1 min, for better performance listen_addresses: - [email protected] ## Stubby / Unbound ## Default Address/Port round_robin_upstreams: 1 upstream_recursive_servers: # IPV4 Servers # The getdnsapi.net Server - address_data: 185.49.141.37 tls_port: 853 tls_auth_name: "getdnsapi.net" tls_pubkey_pinset: - digest: "sha256" value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= # The Fondation RESTENA Server - address_data: 158.64.1.29 tls_auth_name: "kaitain.restena.lu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4= ### Test servers ### ## Surfnet/Sinodun Servers - address_data: 145.100.185.17 tls_port: 853 tls_auth_name: "dnsovertls2.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg= # The securedns.eu Server - address_data: 146.185.167.43 tls_auth_name: "dot.securedns.eu" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= # The dns.cmrg.net Server - address_data: 199.58.81.218 tls_port: 443 tls_auth_name: "dns.cmrg.net" tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= # DNSPRIVACY.at Primary DNS TLS Server - address_data: 94.130.110.185 tls_port: 853 tls_auth_name: "ns1.dnsprivacy.at" tls_pubkey_pinset: - digest: "sha256" value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY= # DNSPRIVACY.at Secondary DNS TLS Server - address_data: 94.130.110.178 tls_port: 853 tls_auth_name: "ns2.dnsprivacy.at" tls_pubkey_pinset: - digest: "sha256" value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg= # The dns.neutopia.org Server - address_data: 89.234.186.112 tls_port: 443 tls_auth_name: "dns.neutopia.org" tls_pubkey_pinset: - digest: "sha256" value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= ### Anycast services ### #Tenta ICANN DNS TLS Primary Server - address_data: 99.192.182.200 tls_auth_name: "iana.tenta.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0= All of these name servers listed above DO NOT log ! repeat DO NOT log ! your DNS queries. In full disclosure some name servers claim to log traffic volume only. See here for details : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers and look under " Logging " column. DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy - Run Test After Completing Full Setup These name servers listed above help to consistently ensure QNAME Minimisation functions as designed within UNBOUND ( The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. ) Use either or both of these two methods to verify QNAME Minimisation A - 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 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 - 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: A - 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 nameservers 99.192.182.200 and 99.192.182.100 - 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 DNS name servers as " custom DNS servers " on the Wan interface. I chose Tenta DNS because their name servers support both emerging DNS privacy standards - DNS-over-TLS, and DNS-over-HTTPS, which both provide last mile encryption to keep your DNS queries private and free from tampering. Tenta DNS also is the only AnyCast DOT service which includes built-in BGP integration, offering single engine convenience for DNS Anycasting with QNAME minimisation enabled on its' name servers by default. Main benefits of Tenta DNS as the backbone name servers on 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 9 - Working /etc/config/unbound file nano /etc/config/unbound config unbound option dns64 '0' option edns_size '4096' option extended_luci '1' option extended_stats '0' option hide_binddata '1' option domain 'yourdomain.here' 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 'small' 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' 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 gnutls-cli --print-cert -p 853 185.49.141.37 - 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
  3. 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.
  4. 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. 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 : # 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 dns_transport_list: - GETDNS_TRANSPORT_TLS tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 60000 listen_addresses: - [email protected] upstream_recursive_servers: # IPV4 Servers # The getdnsapi.net Server - address_data: 185.49.141.37 tls_port: 853 tls_auth_name: "getdnsapi.net" tls_pubkey_pinset: - digest: "sha256" value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= # The Fondation RESTENA Server - address_data: 158.64.1.29 tls_auth_name: "kaitain.restena.lu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4= ### Test servers ### ## Surfnet/Sinodun Servers - address_data: 145.100.185.17 tls_port: 853 tls_auth_name: "dnsovertls2.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg= # The securedns.eu Server - address_data: 146.185.167.43 tls_auth_name: "dot.securedns.eu" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= # The dns.cmrg.net Server - address_data: 199.58.81.218 tls_port: 443 tls_auth_name: "dns.cmrg.net" tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= #The BlahDNS Japan DNS TLS Server - address_data: 108.61.201.119 tls_auth_name: "dns.jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: xUUS3QKzpYz2seet8+zChlhp0jpNCbiGtXFb0ZtAkic= #The BlahDNS German DNS TLS Server - address_data: 159.69.198.101 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: atJFsia3frz6t/gLTe2qyBKT1a+nrPpyjQqp1bZwttI= # DNSPRIVACY.at Primary DNS TLS Server - address_data: 94.130.110.185 tls_port: 853 tls_auth_name: "ns1.dnsprivacy.at" tls_pubkey_pinset: - digest: "sha256" value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY= # DNSPRIVACY.at Secondary DNS TLS Server - address_data: 94.130.110.178 tls_port: 853 tls_auth_name: "ns2.dnsprivacy.at" tls_pubkey_pinset: - digest: "sha256" value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg= #DNS Warden DNS TLS Primary Server - address_data: 213.136.83.50 tls_auth_name: "dns1.dnswarden.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: fOJ7TG7gmlcDEsqvf6qhtThCUri7U+p/QgTnG62D5FA= #dns.seby.io - Vultr TLS Server - address_data: 45.76.113.31 tls_auth_name: "dot.seby.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Zo6lWnGmWBuhPToAq3GR8QFwRxRdFaLNgFlbS9Z8ALU= #The doh.defaultroutes.de DNS TLS Server - address_data: 5.45.107.88 tls_auth_name: "doh.defaultroutes.de" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: zYnx/ptyLlxHp9RQ5cHXbe2HJLXyZUT3A/lbyhd0B/M= # The dns.neutopia.org Server - address_data: 89.234.186.112 tls_port: 443 tls_auth_name: "dns.neutopia.org" tls_pubkey_pinset: - digest: "sha256" value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= # The Lorraine Data Network TLS Server - address_data: 80.67.188.188 tls_auth_name: "ns0.ldn-fai.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM= ### Anycast services ### #Tenta ICANN DNS TLS Primary Server - address_data: 99.192.182.200 tls_auth_name: "iana.tenta.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0= #Tenta OpenNIC DNS TLS Primary Server - address_data: 99.192.182.100 tls_auth_name: "opennic.tenta.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0= #Cloudflare DNS TLS Primary Server - address_data: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= #Cloudflare DNS TLS Secondary Server - address_data: 1.0.0.1 tls_auth_name: "cloudflare-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= 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 gnutls-cli --print-cert -p 853 185.49.141.37 - 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.
  5. 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
  6. 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.
  7. 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!
×