[Updated on 10.03.2020]Since opnsense 18.7.9 it is possible to use encrypted DNS with the opnsense-plugin "os-dnscrypt-proxy". Thanks to mimugmail (m.muenz@gmail.com). This plugin supports DNSCrypt (https://dnscrypt.info (https://dnscrypt.info)) and DNS over HTTPS (DoH) with DNSSEC and DNSBL.
Explanations and Differences:DNSCrypt or
DNS over HTTPS = protocol that authenticates communications between a dns-client and a dns-resolver. It encrypts the traffic and prevents dns spoofing or man-in-the-middle-attacks. DoH is standardized through IETF and standardport for resolvers is 443. DNSCrypt use different ports. Resolver on the internet often use ports like 443, 4443, 5443 or 8443 and is currently not standardized but has more privacy features.
DNSSEC = DNS Extension that allows a client to validate the dns response on supported domains and TLDs. Resolvers check the digital signature of dns responses.
DNSBL = Domain Name System Blacklists with RPZ (response policy zone) to block ads, trackers and malware domains.
This technique prevents not against ISP-censorship !!! because your browser requests for https has the Server Name Indication (SNI) unencrypted. Currently only Cloudflare and Firefox have implemented ESNI for testing. Tor or a VPN can solve this. Here the answer from the developer of DNSCrypt, Frank Denis:
https://superuser.com/questions/1318588/what-exactly-isp-can-see-when-someone-use-dnscrypt-proxy-with-dnscrypt-enabled-p (https://superuser.com/questions/1318588/what-exactly-isp-can-see-when-someone-use-dnscrypt-proxy-with-dnscrypt-enabled-p)
Scenario:dnscrypt-proxy is only listen on the localhost addresses 127.0.0.1 (IPv4) and ::1 (IPv6) on port 5353 and handle the dns requests to the internet encrypted.
unbound dns forwards all queries to dnscrypt-proxy while itself is listening on all interfaces on port 53 (IPv4 + IPv6) and handle the dns requests for the local network unencrypted.
The reason behind that scenario is unbound dns can act as a dns-resolver for your lan with all his features. If you allow to register dhcp leases you can reach your clients via their hostnames and do not need to know their ip addresses. The dns traffic on the lan side is not encrypted because the most client's OS currently does not support this. For decentralization dnscrypt-proxy uses a pool of random servers from a public list. Normally is choosing automatically the fastest with the options you set (IPv4, IPv6, DNSCrypt, DoH, DNSSEC, NoLog, NoFilter). Every 3 hours it checks the fastest server again. You can shorten the time interval by running the existing cronjob under System/Settings/Cron "Download DNSCrypt-Proxy DNSBLs and restart". You only need dnscrypt-proxy because unbound dns (and also dnsmasq) has only limited support for DNSCrypt/DoH and DNSBL.
You can also configure dnscrypt-proxy as standalone dns-server. For this follow these instructions:
https://wiki.opnsense.org/manual/how-tos/dnscrypt-proxy.html (https://wiki.opnsense.org/manual/how-tos/dnscrypt-proxy.html)
Install DNSCrypt-Proxy:System/Firmware/Plugins
=> Install "os-dnscrypt-proxy"
Configuration DNSCrypt-Proxy:Services/DNSCrypt-Proxy/Configuration/General
=> Check "Enable DNSCrypt-Proxy"
=> "Listen Address" is 127.0.0.1:5353 and [::1]:5353
=> Check "Use IPv4 Servers"
=> Check "Use IPv6 Servers"
=> Check "Use DNSCrypt Servers"
=> Check "Use DNS-over-HTTPS Servers"
=> Check "Require DNSSEC"
(see attachments "Services-DNSCrypt-Proxy_01.png", "Services-DNSCrypt-Proxy_02.png")
(https://forum.opnsense.org/index.php?action=dlattach;topic=10670.0;attach=7461;image)
(https://forum.opnsense.org/index.php?action=dlattach;topic=10670.0;attach=7463;image)
=> As "Fallback Resolver" you can use the standard Quad9 Server (9.9.9.9:53) or Cloudflare (1.1.1.1:53) or what ever you want.
Optional Configuration DNSCrypt-Proxy (manual Servers):For some business usecases is it neccessary to use manual dns server for additional dns services from Cloudflare or Cisco Umbrella. For other reason you want to use specific servers from your country. If you use the "Server List" the options (DNSSEC, NoLog, NoFilter) will be ignored.
Services/DNSCrypt-Proxy/Configuration/General
=> On "Server List" you can enter the servernames from this public list https://dnscrypt.info/public-servers/ (https://dnscrypt.info/public-servers/).
use the exactly servernames and not any IP'sCloudflare CDN (DoH) its one of the fastest but in the past another user has make the experience that some sites are not available like oneplus.com or postbank.de because DNSSEC was broken => seems to be fixed.
In that case you had to configure unbound dns to redirect the query for this domain to another dns server. This can be done on "Services/Unbound DNS/Overrides/Domain Overrides".
cloudflare
cloudflare-ipv6
for services like Cisco Umbrella.
cisco
cisco-ipv6
(see attachment "Services-DNSCrypt-Proxy_03.png")
(https://forum.opnsense.org/index.php?action=dlattach;topic=10670.0;attach=7465;image)
Another option is to create your own server on Services/DNSCrypt-Proxy/Configuration/Servers.
Configuration Unbound DNS:Services/Unbound DNS/General
=> Check "Enable Unbound"
=> Check "Enable DNSSEC Support"
=> Uncheck "DNS Query Forwarding"
=> Under "Custom options" you must configure unbound dns that is all forwarding to dnscrypt-proxy. I setup this for IPv4 + IPv6 because dnscrypt-proxy and unbound dns is listening on both addresses and in the original unbound.conf "interface-automatic" is set to yes, see:
ssh on opnsense: "cat /var/unbound/unbound.conf"
# Interface IP(s) to bind to
interface: 0.0.0.0
interface: ::0
interface-automatic: yesUser karlson2k figured out a solution where entries in "Services/Unbound DNS/Overrides/Domain Overrides" prevents unbound dns to start if you forward to dnscrypt-proxy. Writing "server:" at the beginning of "Custom options" solves this.
Quote from: karlson2k on January 13, 2020, 10:03:18 PM
The reason is that domain overrides is included in unbound.conf before "Custom options" and domain overrides change section from "server:" to "forward-zone:".
To fix error in configuration, you need to add "server:" line before "do-not-query-localhost: no".
so the complete configuration looks like...
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
forward-addr: ::1@5353
=> Choose "All (recommended)" on "Outgoing Network Interfaces". In the past you had the option "localhost" but this is removed since version 19.
Configuration System DNS-Server:System/Settings/General
=> Check that
no one "DNS Server" is configured
=> Uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN"
=> Uncheck "Do not use the local DNS service as a nameserver for this system"
(see attachment "System-Settings-General.png")
(https://forum.opnsense.org/index.php?action=dlattach;topic=10670.0;attach=7467;image)
All is done!
Check if your DNS Configuration works correctly:=> https://dnsleaktest.com (https://dnsleaktest.com)
Check against dns-leaks and what dns-server you currently use
=> https://cmdns.dev.dns-oarc.net/ (https://cmdns.dev.dns-oarc.net/)
Check your dns features
=> https://internet.nl/test-connection/ (https://internet.nl/test-connection/)
If you use IPv6 and DNSSEC
=> http://www.dnssec-or-not.com/ (http://www.dnssec-or-not.com/)
If you use DNSSEC
=> https://tools.dnsstuff.com/ (https://tools.dnsstuff.com/)
DNS-Tools and more
Recommendation to other Tutorial:Forward all unencrypted dns traffic to OPNsense, see:
https://forum.opnsense.org/index.php?topic=9245.0 (https://forum.opnsense.org/index.php?topic=9245.0)
Kind Regards ;)
Nice :)
Thanks, p1n0ck10.
Quote from: p1n0ck10 on December 13, 2018, 10:14:12 PM
This technique prevents not against ISP-censorship !!! a VPN-Provider can solve this.
here the answer from the developer Frank Denis:
https://superuser.com/questions/1318588/what-exactly-isp-can-see-when-someone-use-dnscrypt-proxy-with-dnscrypt-enabled-p
First of all many thanks for this ingenious instruction.
I have two questions.
1. What settings should I make if I use a transparent proxy and at the same time have a few clients that do not use a transparent proxy and continue to receive their DNS request via unbound?
2. Now if my provider can read everything again which sense is behind this plugin to use?
Because the different servers the dnscrypt used I can enter myself also in the unbound dns server list and for that I don´t need this plugin.
thx
rené
Quote from: opnsenseuser on December 16, 2018, 08:37:38 AM
1. What settings should I make if I use a transparent proxy and at the same time have a few clients that do not use a transparent proxy and continue to receive their DNS request via unbound?
Which Transparent Proxy do you mean? Web Proxy or DNS Proxy?
Quote from: opnsenseuser on December 16, 2018, 08:37:38 AM
2. Now if my provider can read everything again which sense is behind this plugin to use?
Because the different servers the dnscrypt used I can enter myself also in the unbound dns server list and for that I don´t need this plugin.
The sense of the plugin is to encrypt the DNS traffic over DNSCrypt or DoH (DNS over HTTPS). This in combination with DNSSEC checks the digital signature of DNS responses to verify that the data match what the zone owner initially configured. It makes DNS more secure against spoofing or changing the DNS-Records do you ask for. More Info here: https://dnscrypt.info/faq/
Quote from: p1n0ck10 on December 16, 2018, 01:29:26 PM
Quote from: opnsenseuser on December 16, 2018, 08:37:38 AM
1. What settings should I make if I use a transparent proxy and at the same time have a few clients that do not use a transparent proxy and continue to receive their DNS request via unbound?
Which Transparent Proxy do you mean? Web Proxy or DNS Proxy?
1. Squid http(s) proxy with cert (yes, web)
2. What can i do to give the provider no way to read my surfing behavior?
You wrote something about vpn dns!
I currently do not use vpn.
Is this still possible ?
And is there any instructions for opnsense?
Quote from: opnsenseuser on December 16, 2018, 08:37:38 AM
1. What settings should I make if I use a transparent proxy and at the same time have a few clients that do not use a transparent proxy and continue to receive their DNS request via unbound?
Quote from: p1n0ck10 on December 16, 2018, 01:29:26 PM
Which Transparent Proxy do you mean? Web Proxy or DNS Proxy?
Quote from: opnsenseuser on December 16, 2018, 02:08:27 PM
Squid http(s) proxy with cert (yes, web)
Web Proxy and DNS are different things. Transparent Web Proxy catch all your clients to HTTP and HTTPS requests when you have set a NAT-Rule. Your clients will still ask for DNS even if you use the Transparent Web Proxy. In the Web Proxy you can add blocklists, too. Without DNS you can't resolve names in the internet. So DNS is a important component to search the Internet and should be encrypted like HTTPS.
Quote from: opnsenseuser on December 16, 2018, 02:08:27 PM
2. What can i do to give the provider no way to read my surfing behavior?
You wrote something about vpn dns!
I currently do not use vpn.
Is this still possible ?
And is there any instructions for opnsense?
(all traffic not only for DNS) The opnsense-plugin "os-tor" (https://www.torproject.org/) can solve this or a VPN-Provider. First you must read what VPN-Provider do you prefer and which features it has and what do you need. here two examples:
https://nordvpn.com
https://www.perfect-privacy.com/
The most VPN-Provider supports normal IPsec and OpenVPN. OPNsense can do that ;-)
Do I have to change anything for the Bind PlugIn to work together?
So follow the instructions in here and make sure that unbound is pointing to port 53530 (default for BIND).
Bind doesn't let you put in port numbers for the forwarders so you have to edit the config file.
Go to the BIND service page first and fill in 127.0.0.1 and ::1 in the forwarders section.
Also make sure DNSSEC Validation is "Auto". Now hit Save
Then you need to edit /usr/local/etc/namedb/named.conf to add in the ports for the forwarders to point to dnscrypt. I like using winscp to ssh to the unit and doing this in a txt editor but do it however you'd like
Now you should have a forwarders line
This is what my forwarder line looks like after adding in the port numbers.
forwarders { 127.0.0.1 port 5353; ::1 port 5353; };
Basically I just added " port 5353" to the end of each forwarder IP.
It appears to be working for me. All the leak tests give me the same result I got when I was just using dnscrypt and BIND appears.
Only quirk I had is the first time after installing bind and dnscrypt-proxy I could not start dnscrypt-proxy service without restarting opnsense. After the restart it appeared to work fine.
You can also add an alias 127.0.0.8 and listen dnscrypt to this IP with port 53. Will also work ...
Quote from: mimugmail on December 25, 2018, 07:55:19 AM
You can also add an alias 127.0.0.8 and listen dnscrypt to this IP with port 53. Will also work ...
Yes that would make it easier so you wouldn't have to edit the file. I wish I thought of doing it that way.
Thanks for the tutorial. I am always looking for ways to improve DNS security.
I know enough about networking to be dangerous. You tutorial was easy to follow and get working.
I am curious though. Before, I used Cloudflare and Google for DNS and that is reflected in DNS tests. Now when I check DNS it appears that I am using random servers, but the provider comes back as Cloudflare. I assume the fastest server available is responding but the request is encrypted?
Yes, it chooses fastest one, but you can also use manual server (with next version)
Had to give up on this plugin. While I like the idea, I had too many DNS lookup failures.
And why should they be related to the plugin? If it works it works .. if you have something wrong, nothing works.
This is great! Many thanks to the dev mimugmail (m.muenz@gmail.com) and for the tutorial!
I had a little trouble with it not starting when I entered some dns servers in the list at https://dnscrypt.info/public-servers/ (https://dnscrypt.info/public-servers/)
I ended up looking at the log located in cat /var/log/dnscrypt-proxy/dnscrypt-proxy.log and choosing 3 of the resolvers that worked. I am wondering if one of the resolvers goes down, will this stop dnsproxy from starting at boot?
I went a different route from the tutorial in first post, I set up a Virtual IP in Firewall --> Virtual IP
I used: IP Alias | loopback | 127.0.0.2
Then configured the DNSCrypt plugin to use 127.0.0.2:53 (and deleted the default ones)
Lastly I headed over to System --> Settings --> General and put 127.0.0.2 in the in the DNS Server box.
My test at https://www.dnsleaktest.com showed my dns queries are using dnscrypt. :-)
One feature request is to be able edit the verb for the log and also to show the log in the GUI.
Thanks again for this plugin!
Log in the UI is already under review, perhaps with 19.1.
The default behavior is to use the fastest two servers, and it checks every hour which one is the fastest, so no problem :)
Quote from: cake on January 25, 2019, 04:23:02 AM
I had a little trouble with it not starting when I entered some dns servers in the list at
I ended up looking at the log located in (https://dnscrypt.info/public-servers/%5B/url)cat /var/log/dnscrypt-proxy/dnscrypt-proxy.log and choosing 3 of the resolvers that worked. I am wondering if one of the resolvers goes down, will this stop dnsproxy from starting at boot?
Lastly I headed over to System --> Settings --> General and put 127.0.0.2 in the in the DNS Server box.
One feature request is to be able edit the verb for the log and also to show the log in the GUI.
Thanks again for this plugin!
I only recommend unbound and dnscrypt in this way what i wrote because i'm not a fan to have to many DNS-resolver between clients and internet. makes little bit difficult to solve dns errors. i have testet many DNS-resolver from the public list https://dnscrypt.info/public-servers/ (https://dnscrypt.info/public-servers/)
The best way is to use the automatic option because the fastest and a pool of random servers is used. If you use the manual configuration of servers i only recommend cloudflare and cisco (opendns) because these are dnsproviders with bigger infrastructure behind the szene. Cisco (opendns) has the disadvantage thats not using DNSSEC.
The best DNS results on https://cmdns.dev.dns-oarc.net (https://cmdns.dev.dns-oarc.net) i achieved with cloudflare.
I don't know why you using 127.0.0.2 in the configuration of system/settings/general. In my opinion opnsense uses localhost as default dns-resolver. The dns-resolver in system/settings/general is normally configured with external dns resolver. that job makes dnscrypt. in my configuration is the way.
opnsense => localhost = unbound => forwarding mode to dnscrypt. thats it
Good too hear that the log is coming to the GUI ;)
Hi,
After reading all configuration guides for dnscrypt-proxy plugin and several testing I wasn't able to make it work with unbound, only with dnsmaq and dnscrypt-proxy instance running on 127.0.0.2:53 and 127.0.0.2 as the only dns server on System-> settings; but with this configuration I found a problem because on boot dnsmasq is started before dnscrypt-proxy so system can't resove domains. Creating an script to start dnscrypt-proxy before dnsmasq at boot time finally solved it.
I hope this info may be useful to others.
Regards.
I'm running into the same issue.
I can enable and start Unbound but it will not start after adding Advanced Settings part per: https://wiki.opnsense.org/manual/how-tos/dnscrypt-proxy.html
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
No error messages appear in webui or log.
I can start unbound from shell with -d -v, it shows no errors at that time in shell or in ui log.
Goal is to forward incoming requests to my pihole VM, which should get its DNS replies from dnscrypt on opnsense.
I'm guessing same Unbound problem as Bind has:
> When you are using Overrides in Unbound you can not use ``do-not-query-localhost``.
Cheers,
Franco
Quote from: franco on March 20, 2019, 09:23:16 PM
I'm guessing same Unbound problem as Bind has:
> When you are using Overrides in Unbound you can not use ``do-not-query-localhost``.
Cheers,
Franco
Thanks for the reply, I have a number of Overrides, after removing the do-not-query-localhost line Unbound starts!
Overrides can also be done via dnscrypt-proxy if you need them. Also Adblocking is now available vial the plugin itself.
Quote from: mimugmail on March 21, 2019, 02:34:44 PM
Overrides can also be done via dnscrypt-proxy if you need them. Also Adblocking is now available vial the plugin itself.
Thanks.
Had a look at using dnscrypt-proxy alone but the webui of pihole proved to be more featured.
Indeed :)
Hi All,
strange. I have 1 entry in the Host Override in Unbound and have no issues with "do-not-query-localhost: no"
great that DNSBL is implemented in the dnycrypt proxy. thanks mimugmail ;)
Does anybody get server timeouts after a few days or so? I start dnscrypt and after a couple days most servers are timeout according to the log. Not sure how to investigate. Maybe I start with making the log more verbose?
But does it switch to other ones?
Yes it does switch, maybe I have a setting wrong or some other configuration.
Here is a bit of a log, you can see at first 3 have a timeout, and 6 hours later 11 servers are timeout. [2019-04-18 19:56:57] [NOTICE] Source [public-resolvers.md] loaded
[2019-04-18 19:56:57] [NOTICE] dnscrypt-proxy 2.0.19
[2019-04-18 19:56:57] [NOTICE] Loading the set of whitelisting rules from [whitelist.txt]
[2019-04-18 19:56:57] [NOTICE] Loading the set of blocking rules from [blacklist.txt]
[2019-04-18 19:56:57] [NOTICE] Loading the set of cloaking rules from [cloaking-rules.txt]
[2019-04-18 19:56:57] [NOTICE] Loading the set of forwarding rules from [forwarding-rules.txt]
[2019-04-18 19:56:57] [NOTICE] Now listening to 127.0.0.2:53 [UDP]
[2019-04-18 19:56:57] [NOTICE] Now listening to 127.0.0.2:53 [TCP]
[2019-04-18 19:56:57] [NOTICE] Now listening to 192.168.44.4:53 [UDP]
[2019-04-18 19:56:57] [NOTICE] Now listening to 192.168.44.4:53 [TCP]
[2019-04-18 19:56:58] [NOTICE] [arvind-io] OK (crypto v2) - rtt: 256ms
[2019-04-18 19:56:58] [NOTICE] [bottlepost-dns-nl] OK (crypto v2) - rtt: 286ms
[2019-04-18 19:57:00] [NOTICE] [charis] TIMEOUT
[2019-04-18 19:57:00] [NOTICE] [cpunks-ru] OK (crypto v1) - rtt: 313ms
[2019-04-18 19:57:01] [NOTICE] [cs-ch] OK (crypto v2) - rtt: 312ms
[2019-04-18 19:57:01] [NOTICE] [cs-swe] OK (crypto v2) - rtt: 293ms
[2019-04-18 19:57:01] [NOTICE] [cs-nl] OK (crypto v2) - rtt: 213ms
[2019-04-18 19:57:01] [NOTICE] [cs-nl2] OK (crypto v2) - rtt: 169ms
[2019-04-18 19:57:02] [NOTICE] [cs-fi] OK (crypto v2) - rtt: 200ms
[2019-04-18 19:57:02] [NOTICE] [cs-pl] OK (crypto v2) - rtt: 295ms
[2019-04-18 19:57:02] [NOTICE] [cs-dk] OK (crypto v2) - rtt: 206ms
[2019-04-18 19:57:02] [NOTICE] [cs-it] OK (crypto v2) - rtt: 170ms
[2019-04-18 19:57:02] [NOTICE] [cs-fr] OK (crypto v2) - rtt: 158ms
[2019-04-18 19:57:03] [NOTICE] [cs-fr2] OK (crypto v2) - rtt: 160ms
[2019-04-18 19:57:03] [NOTICE] [cs-pt] OK (crypto v2) - rtt: 211ms
[2019-04-18 19:57:03] [NOTICE] [cs-hk] OK (crypto v2) - rtt: 361ms
[2019-04-18 19:57:03] [NOTICE] [cs-ro] OK (crypto v2) - rtt: 191ms
[2019-04-18 19:57:03] [NOTICE] [cs-mo] OK (crypto v2) - rtt: 205ms
[2019-04-18 19:57:04] [NOTICE] [cs-lv] OK (crypto v2) - rtt: 202ms
[2019-04-18 19:57:04] [NOTICE] [cs-uk] OK (crypto v2) - rtt: 165ms
[2019-04-18 19:57:04] [NOTICE] [cs-de] OK (crypto v2) - rtt: 162ms
[2019-04-18 19:57:04] [NOTICE] [cs-de2] OK (crypto v2) - rtt: 169ms
[2019-04-18 19:57:04] [NOTICE] [cs-ca] OK (crypto v2) - rtt: 218ms
[2019-04-18 19:57:05] [NOTICE] [cs-ca2] OK (crypto v2) - rtt: 291ms
[2019-04-18 19:57:05] [NOTICE] [cs-usny] OK (crypto v2) - rtt: 274ms
[2019-04-18 19:57:05] [NOTICE] [cs-usil] OK (crypto v2) - rtt: 274ms
[2019-04-18 19:57:05] [NOTICE] [cs-usnv] OK (crypto v2) - rtt: 216ms
[2019-04-18 19:57:08] [NOTICE] [cs-uswa] TIMEOUT
[2019-04-18 19:57:08] [NOTICE] [cs-usdc] OK (crypto v2) - rtt: 264ms
[2019-04-18 19:57:08] [NOTICE] [cs-ustx] OK (crypto v2) - rtt: 242ms
[2019-04-18 19:57:08] [NOTICE] [cs-usga] OK (crypto v2) - rtt: 250ms
[2019-04-18 19:57:09] [NOTICE] [cs-usnc] OK (crypto v2) - rtt: 258ms
[2019-04-18 19:57:09] [NOTICE] [cs-usca] OK (crypto v2) - rtt: 209ms
[2019-04-18 19:57:09] [NOTICE] [cs-usor] OK (crypto v2) - rtt: 272ms
[2019-04-18 19:57:09] [NOTICE] [d0wn-is-ns2] OK (crypto v1) - rtt: 235ms
[2019-04-18 19:57:10] [NOTICE] [d0wn-tz-ns1] OK (crypto v1) - rtt: 392ms
[2019-04-18 19:57:10] [NOTICE] [de.dnsmaschine.net] OK (crypto v2) - rtt: 204ms
[2019-04-18 19:57:10] [NOTICE] [dnscrypt.ca-1] OK (crypto v2) - rtt: 297ms
[2019-04-18 19:57:11] [NOTICE] [dnscrypt.ca-2] OK (crypto v2) - rtt: 288ms
[2019-04-18 19:57:11] [NOTICE] [dnscrypt.eu-dk] OK (crypto v2) - rtt: 205ms
[2019-04-18 19:57:11] [NOTICE] [dnscrypt.eu-nl] OK (crypto v1) - rtt: 301ms
[2019-04-18 19:57:11] [NOTICE] [dnscrypt.me] OK (crypto v2) - rtt: 180ms
[2019-04-18 19:57:11] [NOTICE] [dnscrypt.nl-ns0] OK (crypto v2) - rtt: 196ms
[2019-04-18 19:57:12] [NOTICE] [dnscrypt.uk-ipv4] OK (crypto v2) - rtt: 282ms
[2019-04-18 19:57:12] [NOTICE] [ev-va] OK (crypto v2) - rtt: 274ms
[2019-04-18 19:57:12] [NOTICE] [ev-to] OK (crypto v2) - rtt: 270ms
[2019-04-18 19:57:12] [NOTICE] [freetsa.org] OK (crypto v1) - rtt: 256ms
[2019-04-18 19:57:13] [NOTICE] [ibksturm] OK (crypto v2) - rtt: 453ms
[2019-04-18 19:57:13] [NOTICE] [ipredator] OK (crypto v1) - rtt: 194ms
[2019-04-18 19:57:13] [NOTICE] [opennic-ethservices] OK (crypto v1) - rtt: 261ms
[2019-04-18 19:57:14] [NOTICE] [opennic-ethservices2] OK (crypto v1) - rtt: 259ms
[2019-04-18 19:57:14] [NOTICE] [opennic-luggs] OK (crypto v1) - rtt: 284ms
[2019-04-18 19:57:14] [NOTICE] [opennic-luggs2] OK (crypto v1) - rtt: 287ms
[2019-04-18 19:57:14] [NOTICE] [publicarray-au] OK (crypto v2) - rtt: 176ms
[2019-04-18 19:57:17] [NOTICE] [qag.me] TIMEOUT
[2019-04-18 19:57:17] [NOTICE] [quad9-dnscrypt-ip4-nofilter-pri] OK (crypto v1) - rtt: 160ms
[2019-04-18 19:57:17] [NOTICE] [quad9-dnscrypt-ip4-nofilter-alt] OK (crypto v1) - rtt: 158ms
[2019-04-18 19:57:19] [NOTICE] [qualityology.com] TIMEOUT
[2019-04-18 19:57:19] [NOTICE] [scaleway-fr] OK (crypto v2) - rtt: 162ms
[2019-04-18 19:57:19] [NOTICE] [securedns] OK (crypto v1) - rtt: 284ms
[2019-04-18 19:57:20] [NOTICE] [soltysiak] OK (crypto v1) - rtt: 280ms
[2019-04-18 19:57:20] [NOTICE] [suami] OK (crypto v2) - rtt: 161ms
[2019-04-18 19:57:20] [NOTICE] [trashvpn.de] OK (crypto v2) - rtt: 169ms
[2019-04-18 19:57:20] [NOTICE] [ventricle.us] OK (crypto v2) - rtt: 275ms
[2019-04-18 19:57:22] [NOTICE] [opennic-bongobow] TIMEOUT
[2019-04-18 19:57:22] [NOTICE] [opennic-R4SAS] OK (crypto v2) - rtt: 191ms
[2019-04-18 19:57:22] [NOTICE] Server with the lowest initial latency: cs-fr (rtt: 158ms)
[2019-04-18 19:57:22] [NOTICE] dnscrypt-proxy is ready - live servers: 61
[2019-04-18 20:57:25] [NOTICE] [charis] TIMEOUT
[2019-04-18 20:57:31] [NOTICE] [cs-uswa] OK (crypto v2) - rtt: 289ms
[2019-04-18 20:57:40] [NOTICE] [qag.me] TIMEOUT
[2019-04-18 20:57:42] [NOTICE] [qualityology.com] TIMEOUT
[2019-04-18 20:57:46] [NOTICE] [opennic-bongobow] TIMEOUT
[2019-04-18 20:58:01] [NOTICE] Server with the lowest initial latency: cs-fr (rtt: 158ms)
[2019-04-18 21:58:04] [NOTICE] [charis] TIMEOUT
[2019-04-18 21:58:18] [NOTICE] [qag.me] TIMEOUT
[2019-04-18 21:58:20] [NOTICE] [qualityology.com] TIMEOUT
[2019-04-18 21:58:24] [NOTICE] [opennic-bongobow] TIMEOUT
[2019-04-18 21:58:39] [NOTICE] Server with the lowest initial latency: cs-fr (rtt: 158ms)
[2019-04-18 22:58:42] [NOTICE] [charis] TIMEOUT
[2019-04-18 22:58:57] [NOTICE] [qag.me] TIMEOUT
[2019-04-18 22:58:59] [NOTICE] [qualityology.com] TIMEOUT
[2019-04-18 22:59:02] [NOTICE] [opennic-bongobow] TIMEOUT
[2019-04-18 22:59:17] [NOTICE] Server with the lowest initial latency: scaleway-fr (rtt: 159ms)
[2019-04-18 23:59:19] [NOTICE] [charis] TIMEOUT
[2019-04-18 23:59:25] [NOTICE] [cs-lv] TIMEOUT
[2019-04-18 23:59:27] [NOTICE] [cs-de] TIMEOUT
[2019-04-18 23:59:38] [NOTICE] [qag.me] TIMEOUT
[2019-04-18 23:59:40] [NOTICE] [qualityology.com] TIMEOUT
[2019-04-18 23:59:44] [NOTICE] [opennic-bongobow] TIMEOUT
[2019-04-18 23:59:50] [NOTICE] [cs-lv] TIMEOUT
[2019-04-18 23:59:52] [NOTICE] [cs-de] TIMEOUT
[2019-04-19 00:00:02] [NOTICE] Server with the lowest initial latency: cs-fr2 (rtt: 158ms)
[2019-04-19 01:00:05] [NOTICE] [charis] TIMEOUT
[2019-04-19 01:00:10] [NOTICE] [cs-lv] TIMEOUT
[2019-04-19 01:00:12] [NOTICE] [cs-de] TIMEOUT
[2019-04-19 01:00:16] [NOTICE] [cs-uswa] TIMEOUT
[2019-04-19 01:00:25] [NOTICE] [qag.me] TIMEOUT
[2019-04-19 01:00:27] [NOTICE] [qualityology.com] TIMEOUT
[2019-04-19 01:00:30] [NOTICE] [opennic-bongobow] TIMEOUT
[2019-04-19 01:00:37] [NOTICE] [cs-lv] TIMEOUT
[2019-04-19 01:00:39] [NOTICE] [cs-de] TIMEOUT
[2019-04-19 01:00:51] [NOTICE] [cs-uswa] TIMEOUT
[2019-04-19 01:00:51] [NOTICE] Server with the lowest initial latency: cs-fr2 (rtt: 158ms)
[2019-04-19 02:00:54] [NOTICE] [charis] TIMEOUT
[2019-04-19 02:01:00] [NOTICE] [cs-lv] TIMEOUT
[2019-04-19 02:01:02] [NOTICE] [cs-de] TIMEOUT
[2019-04-19 02:01:05] [NOTICE] [cs-uswa] TIMEOUT
[2019-04-19 02:01:12] [NOTICE] [ibksturm] TIMEOUT
[2019-04-19 02:01:16] [NOTICE] [qag.me] TIMEOUT
[2019-04-19 02:01:18] [NOTICE] [qualityology.com] TIMEOUT
[2019-04-19 02:01:22] [NOTICE] [opennic-bongobow] TIMEOUT
[2019-04-19 02:01:28] [NOTICE] [cs-lv] TIMEOUT
[2019-04-19 02:01:30] [NOTICE] [cs-de] TIMEOUT
[2019-04-19 02:01:42] [NOTICE] [cs-uswa] TIMEOUT
is it possible to have dnscrypt have a different set of DNS server(s) for an ip range?
No, but manual addition
so essentially just add dns servers in via static ip mappings? I have my kids devices mapped, but I was hoping to set it via range or group setting rather than manually per device. I hope this could be a future feature. It would be great for parental control features and being able to drill down for reports that are generated per user.
Just use Port redirection for kids IPs to make use of it. Rest could go with usual DNS
While I would love to use dnscrypt I can't because of some websites apperently having broken dnssec support like postbank.de see https://community.cloudflare.com/t/problem-with-oneplus-com-and-postbank-de/29232. I currently use dns over tls and there happends the same with dnssec enabled but I can configure a override to get those sites working. I don't know how I can make this work with dnssec and dnscrypt set up because you can only use unbound overrides if "do-not-query-localhost: no" isn't being used. If anyone knows how to make it work please let me know.
Quote from: DoomSalamander on June 27, 2019, 01:59:00 PM
While I would love to use dnscrypt I can't because of some websites apperently having broken dnssec support like postbank.de see https://community.cloudflare.com/t/problem-with-oneplus-com-and-postbank-de/29232. I currently use dns over tls and there happends the same with dnssec enabled but I can configure a override to get those sites working. I don't know how I can make this work with dnssec and dnscrypt set up because you can only use unbound overrides if "do-not-query-localhost: no" isn't being used. If anyone knows how to make it work please let me know.
You must configure Unbound DNS to redirect this query to another DNS-Resolver. Example with Quad9 DNS.
Copy this to your Custom Config:
server:
do-not-query-localhost: no
forward-zone:
name: "postbank.com"
forward-addr: 9.9.9.9
forward-zone:
name: "postbank.de"
forward-addr: 9.9.9.9
forward-zone:
name: "."
forward-addr: ::1@5353
forward-addr: 127.0.0.1@5353
with this config i can resolve postbank.com and postbank.de
Kind Regards
Thank you very much! Seems to work flawlessly. You should add that to your tutorial and mention that some sites may have broken dnssec support and you can add them that way as an exception.
Quote from: DoomSalamander on June 30, 2019, 01:53:49 PM
Thank you very much! Seems to work flawlessly. You should add that to your tutorial and mention that some sites may have broken dnssec support and you can add them that way as an exception.
This problem seems to be only at Cloudflare but its caused by Postbank
Another options is to use Quad9 DNS Server in the Server List of the DNSCrypt-Proxy Plugin on OPNsense
quad9-dnscrypt-ip6-filter-pri
quad9-dnscrypt-ip4-filter-pri
Then you don't have to add exceptions to the custom config in Unbound DNS. But Quad9 seems to be more slowly.
Kind Regards
Quote from: p1n0ck10 on June 30, 2019, 02:15:28 PM
This problem seems to be only at Cloudflare.
Another options is to use Quad9 DNS Server in the Server List of the DNSCrypt-Proxy Plugin on OPNsense
Yeah I read that too that this only happens with cloudflare. Apparently of their IETF implantation of DNSSEC. I wanted to use cloudflare because of their speed.
i have updated the tutorial...
The different between Cloudflare and Quad9 is that Cloudflare use QNAME Minimisation and Quad9 not and Quad9 is slower. Results on https://cmdns.dev.dns-oarc.net/
Cloudflare:
(see Attachment: Cloudflare_DNS-Results.png)
https://forum.opnsense.org/index.php?action=dlattach;topic=10670.0;attach=7441;image
Quad9:
(see Attachment: Quad9_DNS-Results.png)
https://forum.opnsense.org/index.php?action=dlattach;topic=10670.0;attach=7443;image
@mimugmail:
i have tried to configure the exceptions under Services/DNSCrypt-Proxy/Configuration/Forwarders
but it don't work. In my opinion this would be the right place? Have you any ideas?
Sorry, can't follow. What exactly do you want to achieve.
Quote from: mimugmail on July 02, 2019, 09:57:50 PM
Sorry, can't follow. What exactly do you want to achieve.
If you use Cloudflare in the Server List you can't access the Domains postbank.com and postbank.de. My idea was to redirect the DNS query to another Server (example Quad9). If i use this on Unbound DNS it works. If i configure this in the DNSCrypt-Proxy under Forwarders it don't work.
Old - Post but was reading up on the "Server List" if you want to manually use known servers like "cloudflare"
Noticed that when I add 1.1.1.1 / 1.1.1.1:53 it fails with something like no servers found.
the list does seem to work when typing cloudflare lower case then it saves and works.
SNI Still not encrypted but still a vast improvement for my testing.
- The sites not loading issue.
(figure off topic but might as well attempt to explain what I'm guess Issue is in this particular Case)
That I found is the firewall on the remote site blocking origination countries / geo IPs
I do this to on many firewalls like meraki and others.
trick is some sites are pulling css / fonts and other items from IPs that are not located in referenced IPs by Geo and if your rule is set to something like only allow these counties and deny all other traffic. then you get the above kind of issue.
basically the bank is blocking certain countries from access.
you might be in .de however your request when using CF is routed through another country like (example) spain/france/etc for speed / backbone performance - then that might be a blocked inbound ..
the firewall for the bank is blocking inbound from either CF proxy due to too many hits from their proxy IP (which is common for a webserver that doesn't understand to strip back to the originators actual IP)
(/figure off topic but might as well attempt to explain what I'm guess Issue is in this particular Case)
HELP!?!
I've googled around, hunted high and low, and STILL haven't found an answer...I'm not sure that this is the right forum for this question, BUT it concerns the topic of what I'm trying to do. If I'm in the wrong place, feel free to move me!
First off, I'm new to both OPNSense and *BSD. I found my way here via the 'Security Now' podcast. Steve Gibson mentioned pfSense in a recent podcast; he was talking about his SG1100 router equipped with pfSense and also mentioned that pfSense could be installed on a router or spare PC - the spare PC caught my attention! :o After investigating, I ruled out pfSense because the machine that I intended to use is an OLD, Intel P4 system - pfSense seems to have deprecated support for 32bit machines. After more googling, I discovered that OPNSense was another fork of the old mOnOwall firewall AND it still supports 32bit machines. :)
The reason that 'spare PC' caught my attention: I started dual booting WindowsXP and Gentoo Linux back in the early 2000s. When XP hit its' expiration date, I moved completely over to Gentoo Linux. That old P4 has been gathering dust and I decided I wanted to turn it into a firewall/router box. I had the router side working, more or less, when other things came up. So I never finished it. When I discovered OPNSense, and realized it did EVERYTHING that I wanted, out-of-the-box, I decided to have at it.
So; 3 weeks later, after much fiddling (and googling) around, I have a working system! Getting my primary and secondary wireless network up and running was a P.I.T.A!!! (I have a Netgear WNR3500 and a Linksys WRT-54G, both running DD-WRT variants, that provide my primary and secondary WiFi networks.) So, that brings me to my question...
I want to use DNSCrypt-Proxy on my OPNSense box. EVERYTHING I've found says: go to System->Firmware->Plugins and install DNSCrypt-Proxy. It DOES NOT exist on my box!!! I tried changing 'repository' locations and updating, but NO DNSCrypt-Proxy in 'Plugins'! Eventually, after reading through these forums, I found a post that helped me bring 'ports' into that box. In turn, I was able to intall DNSCrypt-Proxy2. HOWEVER, that's all CLI stuff. It's installed as a 'package' on my machine and doesn't show up in the 'Services' menu. Being a Gentoo Linux user, I'm not adverse to fiddling around with config files but, as the OP said, I REALLY don't want to mix config file setup with GUI configurations... So, the question is: why is this NOT showing up as a plugin in System->Firmware->Plugins and, where can I go to make this happen? If I CAN'T make this happen, is there a preferred 'how-to tutorial' site that I can go to, to configure this manually?
This is what's in the box:
OPNsense 19.7.4_1-i386
FreeBSD 11.2-RELEASE-p14-HBSD
OpenSSL 1.0.2s 28 May 2019
and the initial install was: OPNsense-19.7-OpenSSL-vga-i386.img (downloaded form OPNSense website), installed on a bootable USB drive.
TIA!!!
Dnscrypt depends on Go language and Go is not compatible to i386 :( Sorry Dude ...
It's compatible, but we keep the i386 version light so that it keeps building faster. Please also note that OPNsense 20.1 (January 2020) will remove i386 altogether as planned a long time ago.
Cheers,
Franco
Quote from: mimugmail on September 23, 2019, 08:14:48 PM
Dnscrypt depends on Go language and Go is not compatible to i386 :( Sorry Dude ...
Quote from: franco on September 24, 2019, 07:26:48 AM
It's compatible, but we keep the i386 version light so that it keeps building faster. Please also note that OPNsense 20.1 (January 2020) will remove i386 altogether as planned a long time ago.
Cheers,
Franco
Well then...I guess that's a good excuse to upgrade the motherboard! ;D The board in that machine IS about 15 years old!
In the mean time: I have a FreeBSD 13.0-Current install running in Virtualbox so I can get some education on *BSD. If I understand the *BSD system correctly, this would be the equivalent of the 'testing' branch in Linux.
I learn best by doing, which is why I chose Gentoo when I converted to Linux. To this day, I run ' ~AMD64' (testing branch) on MY machine. Periodically, I run into problems but, fixing those problems is the best way, IMHO to learn more about the system! So, by installing a 'testing' branch, I will learn more about how *BSD works! :)
Thanks franco, and mimugmail, for your responses! :)
When you install 13 you wont get any binary updates, it's usually only for testing the current state (correct me if I'm wrong Franco). You should install 12.0, there are not many features and it's way better supported.
It's not like with linux that you have bleeding edge wifi or graphic adapters when running 13 :)
For some odd reason the guide doesn't work for me. After activating the plugin URLs are no longer resoved. I'm on the latest version of OPN and have two WAN interfaces. There are rules on the LAN interface to allow packets going to ports 53 and 5353 on the firewall itself. Any ideas?
Are only interested in DNSBL?
I'm trying to switch to DoH, right now i'm using DoT via unbound.
Are you using unbound and dnscrypt for DOH? Or just using dnscrypt as standalone?
When using unbound and dnscrypt as per the instructions in the first post (but unchecking DNSSEC in unbound) it works fine. However when trying to use dnscrypt as standalone DNS listening on port 53, it also doesnt work. To be more specific it works for a bit then nothing resolves. I'm not sure why.
I tried both, neither works.
Thanks for the hint regarding unchecking DNSSEC in unbound! However it still won't resolve any addresses :( Either I'm missing something or there are issues when using multi-WAN (fallback, not load balancing).
My settings are in attachment in case anyone is kind enough to check (I re-activeted DNSSEC in unbound and uncommented the custom options to reactivate DoT for now) :)
Outgoing interface WAN doesnt make sense when it forwards to dnscrypt on localhost? Do you have ipv6 on WAN?
I have two VLANs, one each per ISP. WAN uses IPv4+6 and WAN_elem IPv4.
You were right, the outgoing interface had to be changed to reach DNSCrypt at localhost. It's pretty obvious if you think about it, yet I completely missed it :P Thank you!
Glad you did it :)
I've setup everything in this guide. It's worked great and appears to be doing it's job. I've selected only Cloudflare for my DNScrypt provider. However, when I go to Cloudflare's help page it shows me that I'm not connected and DNS over HTTPS isn't working. I was wondering if you might know why?
I use the 1.1.1.1 test page: https://1.1.1.1/help/
Can you check the logs after dnscrypt-proxy restart if there is something interesting?
Unbound settings:
Network interfaces: All local ones
CheckDNSSec Support
Check DHCP Registration
Check DHCP Static Mappings
Local Zone Type: Transparent
Outgoing Network Interfaces: All local ones
- Note I had this set to WAN when I was using pfSense but it doesn't work for me here
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
Quote from: mimugmail on December 08, 2019, 09:46:14 AM
Can you check the logs after dnscrypt-proxy restart if there is something interesting?
Nothing that I could see:
[2019-12-08 08:53:59] [NOTICE] dnscrypt-proxy is ready - live servers: 1
[2019-12-08 08:53:59] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 3ms)
[2019-12-08 08:53:59] [NOTICE] [cloudflare] OK (DoH) - rtt: 3ms
[2019-12-08 08:53:59] [NOTICE] Now listening to 127.0.0.1:5353 [TCP]
[2019-12-08 08:53:59] [NOTICE] Now listening to 127.0.0.1:5353 [UDP]
[2019-12-08 08:53:59] [NOTICE] Loading the set of forwarding rules from [forwarding-rules.txt]
[2019-12-08 08:53:59] [NOTICE] Loading the set of cloaking rules from [cloaking-rules.txt]
[2019-12-08 08:53:57] [NOTICE] Loading the set of blocking rules from [blacklist.txt]
[2019-12-08 08:53:57] [NOTICE] Firefox workaround initialized
[2019-12-08 08:53:57] [NOTICE] Loading the set of whitelisting rules from [whitelist.txt]
[2019-12-08 08:53:57] [NOTICE] Source [public-resolvers.md] loaded
[2019-12-08 08:53:57] [NOTICE] Network connectivity detected
[2019-12-08 08:53:57] [NOTICE] dnscrypt-proxy 2.0.31
[2019-12-08 08:23:19] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 4ms)
When I visit https://1.1.1.1/help in Firefox (Note I have uBlock Origin installed), I also get the same message from Edge though about DoH not working.
[2019-12-08 09:00:48] 192.168.1.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.0.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.0.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net DS PASS 9ms cloudflare
[2019-12-08 09:00:48] 192.168.3.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net AAAA SYNTH 0ms -
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net A PASS 4ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.cloudflareresolve.com.cdn.cloudflare.net A PASS 4ms cloudflare
[2019-12-08 09:00:48] 192.168.9.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.map.cloudflareresolve.com A PASS 10ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.map.cloudflareresolve.com A PASS 33ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.1.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.1.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.9.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 is-doh.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-doh.cloudflareresolve.com A PASS 6ms cloudflare
[2019-12-08 09:00:48] 192.168.3.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-dot.cloudflareresolve.com A PASS 7ms cloudflare
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-dot.cloudflareresolve.com A PASS 34ms cloudflare
[2019-12-08 09:00:48] 192.168.2.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.4.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.2.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.3.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com DS PASS 1ms -
[2019-12-08 09:00:48] 192.168.0.1 is-cf.cloudflareresolve.com.cdn.cloudflare.net DS PASS 0ms -
[2019-12-08 09:00:48] 192.168.4.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-cf.cloudflareresolve.com A PASS 77ms cloudflare
[2019-12-08 09:00:48] 192.168.4.1 is-cf.cloudflareresolve.com DS PASS 2ms -
[2019-12-08 09:00:48] 192.168.2.1 ae55910f-9418-4ad0-b84e-8635371cbcf5.is-cf.cloudflareresolve.com A PASS 19ms cloudflare
Can you check with tcpdump on WAN If you see DNS traffic on 53 or just 443.
Quote from: mimugmail on December 08, 2019, 11:31:18 AM
Can you check with tcpdump on WAN If you see DNS traffic on 53 or just 443.
Ya, I did that earlier, nothing on 53, although I also have a firewall rule blocking it for external networks and only allowing it for internal.
tcpdump -ni ix0 port 53
listening on ix0
0 packets captured
130285 packets received by filter
0 packets dropped by kernel
tcpdump -ni ix0 port 443
listening on ix0
3109 packets captured
2318077 packets received by filter
0 packets dropped by kernel
...
11:00:31.179125 IP 1.0.0.1:443 > WAN_IP:17505: flags [.] ack 18163, win 63, length 0
11:00:31.179377 IP 1.0.0.1:443 > WAN_IP:17505: flags [F.] seq 53635, ack 18162, win 63, length 0
tcpdump -ni ix0 host 1.0.0.1 and port 443 - I get a whole bunch more 1.0.0.1:443 traffic.
Then it's surely an error at Cloudfare not detecting it as encrypted ...
are you using pihole by any chance?
I have the same issue.
Quote from: mimugmail on December 08, 2019, 03:28:56 PM
Then it's surely an error at Cloudfare not detecting it as encrypted ...
That's what I'm thinking, I just wanted to check to make sure I didn't have any settings wrong though.
Quote from: sol on December 08, 2019, 04:04:18 PM
are you using pihole by any chance?
I have the same issue.
No, I'm just using the settings from the first post here that use Unbound as a forwarder to DNScrypt which then uses DNS over HTTPS to Cloudflare (in my case) to resolve.
Question: Will this setup cause any issues with setting up Dynamic DNS? On the DDNS creation page it says:
Quote"You must configure a DNS server in System: General setup or allow the DNS server list to be overridden by DHCP/PPP on WAN for dynamic DNS updates to work."
But with this setup both of those are not done.
Quote from: WhosTheBosch on December 08, 2019, 11:05:21 PM
Question: Will this setup cause any issues with setting up Dynamic DNS? On the DDNS creation page it says:
Quote"You must configure a DNS server in System: General setup or allow the DNS server list to be overridden by DHCP/PPP on WAN for dynamic DNS updates to work."
But with this setup both of those are not done.
At least with Namecheap Dynamic DNS this works.
I found the original instructions helpful. The server list is what I was stuck on the most. I didn't realize you had to enter the name of the server rather than the IP address. It makes sense because there are sometimes multiple options per DNS server (like Quad9).
One gotcha I would like to mention in case someone finds it useful. I am running the MDNS Repeater service (so that I can make use of certain services across VLANs like being able to autodiscover and access my printer/scanner across VLANs). This service runs on port 5353 which is the default value for the dnscrypt-proxy plugin. The dnscrypt-proxy service would not start unless I changed the port to something else. Once I changed the default port and updated my configuration in the Unbound settings, I was up and running!
I have updated the Tutorial...
Happy New Year to All ;) 8)
A few additions/corrections.
If you use any domain overrides in Unbound then provided recipe will result in failed to (re)start Unbound.
The reason is that domain overrides is included in unbound.conf before "Custom" options and domain overrides change section from "server:" to "forward-zone:".
To fix error in configuration, you need to add "server:" line before "do-not-query-localhost: no"
Also, if you are not worried about a few leaked DNS requests, you can use option "forward-first: yes" so if DNSCrypt-Proxy is failed (or not started yet), Unbound will fallback to normal resolving. This gives you a much more stable but a bit less private configuration.
Also make sure that you did not set any specific "Outgoing Network Interfaces" otherwise Unbound will fail to connect to loopback addresses.
My resulting "Custom options" for Unbound:
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
forward-first: yes
Thanks for the additional informations. I had no problems over 1 year with this config and also opnsense has this in his official documentation, see:
https://wiki.opnsense.org/manual/how-tos/dnscrypt-proxy.html?
Quote
domain overrides change section from "server:" to "forward-zone:".
To fix error in configuration, you need to add "server:" line before "do-not-query-localhost: no"
I have 1 override in unbound and all works fine. But People who has problems can try to write "server:" at the beginning on "custom options". This already exists in unbound.conf.
Quote
Also, if you are not worried about a few leaked DNS requests, you can use option "forward-first: yes" so if DNSCrypt-Proxy is failed (or not started yet), Unbound will fallback to normal resolving. This gives you a much more stable but a bit less private configuration.
If DNSCrypt does not start i want to know that. For me this is not an option that unbound use a fallback resolver or forwards dns query to the systems dns. Maybe you don't know that encrypted dns fails over weeks. DNSCrypt has a fallback resolver.
Quote
Also make sure that you did not set any specific "Outgoing Network Interfaces" otherwise Unbound will fail to connect to loopback addresses.
In the past i choosed "localhost" on Outgoing Network Interface because i had the assurance that traffic goes to DNSCrypt but this is removed since opnsense 19. Now you must choose "All".
Kind Regards
The geoip with alias's addition to OpnSense came at a good time. According to ipleak.net mine was using a dnscrypt server in China. Seems like a bad idea. I had no idea dnscrypt-proxy servers in cn were add to the official list.
Quote from: cake on January 17, 2020, 10:06:46 PM
The geoip with alias's addition to OpnSense came at a good time. According to ipleak.net mine was using a dnscrypt server in China. Seems like a bad idea. I had no idea dnscrypt-proxy servers in cn were add to the official list.
thats why you can use your trusted and favorite servers on "Server List" ;-)
Quote from: p1n0ck10 on January 15, 2020, 10:14:20 PM
Thanks for the additional informations. I had no problems over 1 year with this config and also opnsense has this in his official documentation, see:
https://wiki.opnsense.org/manual/how-tos/dnscrypt-proxy.html?
Official documentation also needs to be fixed.
Quote from: p1n0ck10 on January 15, 2020, 10:14:20 PM
Quote
domain overrides change section from "server:" to "forward-zone:".
To fix error in configuration, you need to add "server:" line before "do-not-query-localhost: no"
I have 1 override in unbound and all works fine. But People who has problems can try to write "server:" at the beginning on "custom options". This already exists in unbound.conf.
This will work if you have host override. But any single domain override will break it.
On the other hand, even if you don't have any overrides, line "server:" will not harm anything.
So safe and future-proof solution is to add "server:". In this case configuration will not break after future changes, which can include domain overrides.
Quote from: p1n0ck10 on January 15, 2020, 10:14:20 PM
Quote
Also make sure that you did not set any specific "Outgoing Network Interfaces" otherwise Unbound will fail to connect to loopback addresses.
In the past i choosed "localhost" on Outgoing Network Interface because i had the assurance that traffic goes to DNSCrypt but this is removed since opnsense 19. Now you must choose "All".
Yes, it
must be set to "All". Otherwise configuration will not work.
It worth to mention it in your "HOWTO".
I spent some time before figured out why my configuration doesn't work at all.
Quote from: p1n0ck10 on January 18, 2020, 04:29:06 PM
Quote from: cake on January 17, 2020, 10:06:46 PM
The geoip with alias's addition to OpnSense came at a good time. According to ipleak.net mine was using a dnscrypt server in China. Seems like a bad idea. I had no idea dnscrypt-proxy servers in cn were add to the official list.
thats why you can use your trusted and favorite servers on "Server List" ;-)
Thank you, I will now. :-)
Quote
karlson2k:
This will work if you have host override. But any single domain override will break it.
On the other hand, even if you don't have any overrides, line "server:" will not harm anything.
So safe and future-proof solution is to add "server:". In this case configuration will not break after future changes, which can include domain overrides.
thats correct. I have only 1 host override. i will add this to the Tutorial. Thank you for the explanations.
Quote
karlson2k:
Yes, it must be set to "All". Otherwise configuration will not work.
It worth to mention it in your "HOWTO".
I spent some time before figured out why my configuration doesn't work at all.
thats already in the Tutorial ;-)
does this replace using stubby?
Quote from: Nekromantik on January 26, 2020, 07:01:11 PM
does this replace using stubby?
stubby uses DoT and dnscrypt-proxy uses DNSCrypt or DoH and optional DNSBL. difficult to say what is better. depend of privat/business yousecase. i think DoH for client <-> resolver requests and DoT for server <-> resolver requests. DNSCrypt seems not so populate but has more privacy features. you don't can use both for the same ports. only with different and then you must handle the request from the clients. i like the option from dnscypt-proxy to use an own serverlist from trusted server and it always use the fastest. DoH seems to be the fastest way because existing technologies and knowledge for https requests can be used for this. loadbalancer, haproxies, not blocked ports...
with an cronjob on opnsense you can restart the service from dnscrypt-proxy every 15min or 30min and it use the fastest server again. for me a good combination. all can be configured over the gui. Not necessary to install packages over cli.
If you use the firewall only for you and you are the only admin thats ok to configure the firewall with custom configurations if you know what you do.
If you use the firewall for customers/other admins or only not familiar with deep firewall knowledge its diffcult to handle custom options and manual installations of packages. stability, troubleshooting. some configs over gui. some over cli... not really supportet and so on...
but this is only my experience ;-)
thanks
How to redirect all traffic to forward traffic to Unbound DNS/DNSCrypt Current I have rule that
Interface LAN
Protocol TCP/UDP
Source LAN Net
Destination ANY
Destination port range DNS.
Or is related to the article that you have posted that would work with HOWTO - Redirect all DNS Requests to Opnsense injunction with you current article?
thanks
Quote from: chain on March 02, 2020, 04:10:15 AM
How to redirect all traffic to forward traffic to Unbound DNS/DNSCrypt Current I have rule that
Interface LAN
Protocol TCP/UDP
Source LAN Net
Destination ANY
Destination port range DNS.
Or is related to the article that you have posted that would work with HOWTO - Redirect all DNS Requests to Opnsense injunction with you current article?
thanks
It is good explained in the HOWTO - Redirect all DNS Requests to Opnsense. It is only a recommendation and they are not dependent to each other. It should be a NAT Rule => "Firewall/NAT/Port Forward" and destination is "invert" + "Local Firewall Address" that means if your clients uses not the local firewall address for unencrypted dns (Port 53) it redirects the request to opnsense. If some clients in your network uses encrypted dns it would not apply.
I think you have a normal rule that is not correct...
So the rule should look like this that I have include
I found these posts useful.
https://forum.opnsense.org/index.php?topic=5593.0
https://forum.opnsense.org/index.php?topic=9245.0
Hello,
I just finished setting up DNScrypt-proxy on OPNsense with unbound following the provided guide, and it works great with the exception of not being able to verify DoH is enabled through cloudflare's site for example. Most likely because it knows nothing about the local DNS setup and how it's being routed through OPNsense. However I see that a local DoH server can be setup via DNScrypt-proxy: https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Local-DoH
I've taken a look at the dnscrypt-proxy.toml configuration file located in /usr/local/etc/dnscrypt-proxy, however there is no section called local_doh. I assume that any changes via the OPNsense GUI would overwrite any changes done manually via the config file? Perhaps an update to the os-dnscrypt-proxy plugin could be made to allow this configuration through the GUI?
EDIT: I missed this part in the wiki near the bottom (don't pay attention to the "Secure DNS" column, the green mark will only be shown when using Cloudflare). So I guess that check will never work unless pointing to cloudflare directly, but I suppose this would be the local solution in order to enable ESNI in Firefox when using DoH. Which may be debatable on it's current usefullness due to it's lack of implementation.
Install DNSCrypt-Proxy:
System/Firmware/Plugins
=> Install "os-dnscrypt-proxy"
is the plugin discontinued?
For me trying to use on OPNsense 2.1.9 the plugin (os-dnscrypt-proxy) is missing on the plugin list.
i386?
yes sure i386, but that shouldn't be a problem.
Version 18.7 still had the plugin in the i386 pepository
http://mirror.wjcomms.co.uk/opnsense/FreeBSD:11:i386/18.7/latest/Latest/
So it is apparently feasible in terms of programming?
I think it depends on Go which is now unsupported in i386
Quote from: mimugmail on December 25, 2018, 07:55:19 AM
You can also add an alias 127.0.0.8 and listen dnscrypt to this IP with port 53. Will also work ...
How Do I do this for IPv6 please?
Virtual IP for ::8 ??
Greets
Byte
::1
Quote from: mimugmail on August 23, 2020, 10:07:08 AM
::1
I doesn´t understand this.
127.0.0.1 doesn´t work, because unbound dns ist listen to Port 53.
So I set 127.0.0.8 as virtual IP and listen do Port 53.
So ::1 doesn´t work, because unbound DNS listen to Port 53,
so I need another virtual IP for listen to Port 53.
e.g. ::8 Port 53 ???
Greets
Byte
Ah, yes, you can add as many loopback ips as you like, or just use a different port
Thanks,
In BIND, you can't set Port for Forwarder in GUI.
Should ::8 work for ipv6?
And wich Adapter I shoud set?
Loopback?
Greets
Byte
Hi guys,
I have OPNSense installed as a VM in a Proxmox homelab test server for the purpose of trial and error (the first error is that the PC only has one physical NIC).
I setup Unbound and DNSCrypt as described in this excellent HowTo. Now to the odd behaviour:
If I use the automatic DNS option for a client, I get the expected ISP running a dnsleaktest.com extended test and if I set a DNS like the fallback resolver specified in DNSCrypt, then I get that.
However, if I set the OPNSense VM as the sole DNS then nothing will be resolved. Yet, if I specify a second DNS name server, like the one used as fallback resolver, then I do get DNScrypt results. Even more strange, I don't exclusively get DNSCrypt name server, but also the odd amazon, google and similar?!?
Running "dnscrypt-proxy -resolve opnsense.org" and "unbound-host opnsense.org" don't return anything unexpected.
Has anyone seen that before and/or any idea how to solve it?
I am new to the topic and any help and advise would be much appreciated.
New DNS Security Protocol from Cloudflare
Info: https://blog.cloudflare.com/oblivious-dns/
Hello Guys, following this tutorial, I deployed DNSCrypt and it's working. Is it possible to use this service in conjunction with a Transparent Proxy?
Hi All,
I followed the tutorial and DNSSEC works fine for ipv4 but I get no access on IPv6. All the tests fail on IPv6.
I made sure that IPv6 was enabled and added to the rules.
Is there something more basic I am missing? Gateway maybe? NIC properties?
[UPDATE]
I am now able to get IPv6 DNS. I set the WAN Interface IPv6 Configuration type to DHCPv6 with a PD of 60 and my two LAN interfaces to 'Track Interface', each with a different Prefix ID. I could not find info on how to get multiple LAN interfaces to work with IPv6 anywhere, so hopefully this info will help someone.
If this approach is incorrect, please post here.
[UPDATE2]
Seems all my proxys didn't work because they were using IPv6 addressing, so I changed Settings>General>Prefer IPv4 over IPv6 to checked, and now everything works again.
Again, if this wasn't the correct way to handle this, please advise.
Thanks
I have set the Unbound + DNSCrypt-proxy bundle as described, for it makes sense.
Unfortunately,
some of the requests seems to fail from my computer.
Further investigation revealed the following:
1. The cache sometimes causes troubleWhen DNSCrypt-proxy restarts for too long, Unbound panics and says that all is lost, and then my macOS caches that there is no IP for the name, and I get a blank page.
This behaviour can be eliminated with
forward-first: yes, as someone mentioned, but this poses obvious disadvantages.
Another possibility is
forward-no-cache: yes, but that might be even worse.
Now, a better option is to enable
Unbound DNS :: Advanced :: Serve expired responses, because the most affected records are short-TTL ones.
2. DNSSEC hardening causes troubleWhen
Unbound DNS :: Advanced :: Harden DNSSEC data is enabled (a naive thing to do, it was), this often happens:
2021-06-20T03:33:04 unbound[76608] [76608:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone
2021-06-20T03:33:04 unbound[76608] [76608:0] info: validator operate: query wiki.mageia.org. A IN
2021-06-20T03:33:04 unbound[76608] [76608:3] debug: verify: signature mismatch
Disabling the option solves the problem.
Now, what I don't understand at all is that when I change forwarders from DNSCrypt to
9.9.9.9@53, it seems fine (with other settings unchanged):
2021-06-20T15:57:58 unbound[13980] [13980:1] debug: validator[module 0] operate: extstate:module_wait_subquery event:module_event_pass
2021-06-20T15:57:58 unbound[13980] [13980:1] info: validator operate: query wiki.mageia.org. A IN
2021-06-20T15:57:58 unbound[13980] [13980:1] info: Verified that unsigned response is INSECURE
Some awkward behaviour is also visible around them new
TYPE65 requests, but I did not reveal anything specific.
3. Even when all works, Unbound seems to treat forwarders inefficiently
2021-06-20T15:57:57 unbound[13980] [13980:1] info: resolving wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: processQueryTargets: wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: sending query: wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] debug: sending to target: <.> 9.9.9.9#53
2021-06-20T15:57:57 unbound[13980] [13980:1] debug: cache memory msg=138269 rrset=146053 infra=10617 val=136881
2021-06-20T15:57:57 unbound[13980] [13980:1] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_reply
2021-06-20T15:57:57 unbound[13980] [13980:1] info: iterator operate: query wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: sanitize: removing extraneous answer RRset: sucuk.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: response for wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: reply from <.> 9.9.9.9#53
2021-06-20T15:57:57 unbound[13980] [13980:1] info: query response was CNAME
2021-06-20T15:57:57 unbound[13980] [13980:1] info: resolving wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: processQueryTargets: wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: sending query: sucuk.mageia.org. A IN
So, what I read from this, when Unbound gets
CNAME instead of
A, it does query for that
A, but first complains that it is from another domain. I am mildly concerned that this is not right.
Recommendations for the tutorial
- Add a suggestion to enable Unbound DNS :: Advanced :: Serve expired responses.
- Add a suggestion to disable Unbound DNS :: Advanced :: Harden DNSSEC data.
- Propose a consensus for DNSBL: it is possible to use them in either DNSCrypt-Proxy or Unbound, but some advice might be helpful for users. My personal opinion is that Unbound is a better place (as of 21.4), but that might be debatable.
- Investigate the extraneous RRSet magic.
Thank you for the attention.
How to solve the wrong boot load order?
Unbound loads early, before DNSCrypt is loaded. Unbound fails to connect to DNSCrypt and reports error. The error persist until DNSCrypt is loaded AND Unbound is restarted.
More details here: https://forum.opnsense.org/index.php?topic=23606.0
I configured my unbound & dnscrypt-proxy as described in the first post.
Unfortunatley it doesn't work right.
While some domains are working fine others can't be resolved at all.
query.log of dnscrypt-proxy shows like this:
[2021-07-12 16:46:13] 127.0.0.1 office365.com DS PASS 11ms NextDNS-Primary
[2021-07-12 16:46:13] 127.0.0.1 office365.com DS PASS 0ms -
[2021-07-12 16:46:13] 127.0.0.1 office365.com DS PASS 0ms -
[2021-07-12 16:46:13] 127.0.0.1 office365.com DS PASS 0ms -
[2021-07-12 16:46:13] 127.0.0.1 office365.com DS PASS 0ms -
[2021-07-12 16:46:13] 127.0.0.1 office365.com DS PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 community.librenms.org A PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 librenms.org DS PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 librenms.org DS PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 librenms.org DS PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 librenms.org DS PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 librenms.org DS PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 librenms.org DS PASS 0ms -
[2021-07-12 16:46:22] 127.0.0.1 beacons.gvt2.com A PASS 0ms -
As you can see the first request was working while all the others end with "PASS" but with the "-" in the end of the line instead the selected DNS-Server profile.
Unbound custom options:
server:
tls-cert-bundle: "/etc/ssl/cert.pem"
local-zone: "use-application-dns.net" always_nxdomain
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5354
dnscrypt-proxy is listening on 127.0.0.1:5354 and does get the requests forwarded by unbound, so this shouldn't be the issue.
Any ideas why this does happen?
Edit:
I can solve the issue by uncheck "Enable DNSSEC Support" in unbound settings.
I do not like to disable DNSSEC support. So is there a other way to get it working?
I followed this tutorial (but I do have the DNS servers set in the general settings) and I have issues after a while, where Unbound fails (but DNScrypt remains working).
Unbound:
# dig @127.0.0.1 docs.ruckuswireless.com
; <<>> DiG 9.16.18 <<>> @127.0.0.1 docs.ruckuswireless.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39747
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;docs.ruckuswireless.com. IN A
DNScrypt:
# dig @127.0.0.1 -p5300 docs.ruckuswireless.com
; <<>> DiG 9.16.18 <<>> @127.0.0.1 -p5300 docs.ruckuswireless.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19463
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;docs.ruckuswireless.com. IN A
;; ANSWER SECTION:
docs.ruckuswireless.com. 599 IN CNAME docs.ruckuswireless.com.cdn.cloudflare.net.
docs.ruckuswireless.com.cdn.cloudflare.net. 599 IN A 104.20.41.32
docs.ruckuswireless.com.cdn.cloudflare.net. 599 IN A 104.20.42.32
;; Query time: 35 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Tue Jul 27 12:24:22 CEST 2021
;; MSG SIZE rcvd: 140
Anyone knows what could be happening?
Dear @p1n0ck10 and others,
Does this DOH still work on opnsense 21.7 ?
Since unbound dns - custom options is removed (?)
I followed your guide and have this in the custom options added:
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
forward-addr: ::1@5353
Can I upgrade to opnsense 21.7 or what should we alter where in the opnsense gui to keep DoH running like it should???
https://forum.opnsense.org/index.php?topic=23929.msg115176#msg115176
is the solution, but you need to mess around with console and these things don'T end in config.xml, so you need to restore this manually for any new install.
Or you install the plugin from the community repo (mimugmail) for the custom options field after updating to 21.7
https://forum.opnsense.org/index.php?topic=23929.msg114064#msg114064
Thanks for the link, but Owh, messing around with the console doesn't sound very promising....
Should we better switch from DoH to DoT than? Since that is more straight forward?
As I just read here: https://homenetworkguy.com/how-to/configure-dns-over-tls-unbound-opnsense/
I thought that DoH was the " better" solution over DoT ?
Better as in what? ;-)
I use DoT and there is a page in 21.7 for that, together with CNAME minimisation under "Advanced" settings for unbound you are for most things on the not-so-unsafe side. Choose some servers you want to trust, I posted my choice in the thread linked above.
Or you install the plugin for the custom stuff in unbound from mimugmail. Choose your weapon...
QuoteBetter as in what? ;-)
good question :-)
When learning about DoT and DoH I read this: "However, from a privacy perspective, DoH is arguably preferable. With DoH, DNS queries are hidden within the larger flow of HTTPS traffic. This gives network administrators less visibility but provides users with more privacy."
And that made me choose DoH back than...
But I'm also looking at opnsense and read about the native DoT usage in Unbound, added with the latest update of opnsense loosing the DoH custom option in Unbound, made we switch to DoT and keeps things over here easy to manage and update future proof without having to "mesh around in the console" :-)
Thanks for your help!
Running DoT works as a charm...
When I leave my own network, I'm a user and would use DoH, as it is not easy to block for admins.
When I'm in my own network, I'm an admin and hate DoH. But for the provider or anybody upstream (if he can open TLS traffic), it hardly makes a difference, if he filters for port 853 or the DNS providers by a list of IPs contacted on port 443 via DoH...
Now that the "custom options" are gone for Unbound DNS since OPNsense 21.7, how do I configure Unbound DNS with DNSCRYPT-PROXY ?
Quote from: JohnnyBeee on August 14, 2021, 10:05:17 AM
Now that the "custom options" are gone for Unbound DNS since OPNsense 21.7, how do I configure Unbound DNS with DNSCRYPT-PROXY ?
It appears that the only straight way is
Enable Forwarding Mode with DNSCrypt-Proxy being listed in system DNS.
Ugly and will also create madness with multiple WANs.
On the 21.7.1 version the DoT doesn't work easy. Required 3 service restarts. No idea why.
Once I define and enable the entries under Unbound -> DNS over TLS and enable 1 of them, dns is dead.
2021-08-14T15:37:31 unbound[96235] [96235:0] info: mesh has 0 recursion states (0 with reply, 0 detached), 0 waiting replies, 21 recursion replies sent, 0 replies dropped, 0 states jostled out
2021-08-14T15:37:31 unbound[96235] [96235:0] info: server stats for thread 7: requestlist max 4 avg 0.545455 exceeded 0 jostled 0
2021-08-14T15:37:31 unbound[96235] [96235:0] info: server stats for thread 7: 146 queries, 125 answers from cache, 21 recursions, 1 prefetch, 0 rejected by ip ratelimiting
Finally it started working
https://1.1.1.1/help#eyJpc0NmIjoiTm8iLCJpc0RvdCI6IlllcyIsImlzRG9oIjoiTm8iLCJyZXNvbHZlcklwLTEuMS4xLjEiOiJZZXMiLCJyZXNvbHZlcklwLTEuMC4wLjEiOiJZZXMiLCJyZXNvbHZlcklwLTI2MDY6NDcwMDo0NzAwOjoxMTExIjoiTm8iLCJyZXNvbHZlcklwLTI2MDY6NDcwMDo0NzAwOjoxMDAxIjoiTm8iLCJkYXRhY2VudGVyTG9jYXRpb24iOiJBTVMiLCJpc1dhcnAiOiJObyIsImlzcE5hbWUiOiJDbG91ZGZsYXJlIiwiaXNwQXNuIjoiMTMzMzUifQ==
Quote from: ingvarr on August 14, 2021, 03:12:03 PM
Quote from: JohnnyBeee on August 14, 2021, 10:05:17 AM
Now that the "custom options" are gone for Unbound DNS since OPNsense 21.7, how do I configure Unbound DNS with DNSCRYPT-PROXY ?
It appears that the only straight way is Enable Forwarding Mode with DNSCrypt-Proxy being listed in system DNS.
Ugly and will also create madness with multiple WANs.
The only problem with that is the port. You cannot specify a port in the system settings and you cannot have 2 services listening on the same port (53).
So am I right to assume that the custom options have only disappeared from the configuration GUI but are still taken into account when entered in unbound.conf?
Quote from: JohnnyBeee on August 17, 2021, 04:36:54 AM
Quote from: ingvarr on August 14, 2021, 03:12:03 PM
Quote from: JohnnyBeee on August 14, 2021, 10:05:17 AM
Now that the "custom options" are gone for Unbound DNS since OPNsense 21.7, how do I configure Unbound DNS with DNSCRYPT-PROXY ?
It appears that the only straight way is Enable Forwarding Mode with DNSCrypt-Proxy being listed in system DNS.
Ugly and will also create madness with multiple WANs.
The only problem with that is the port. You cannot specify a port in the system settings and you cannot have 2 services listening on the same port (53).
So am I right to assume that the custom options have only disappeared from the configuration GUI but are still taken into account when entered in unbound.conf?
Virtual IPs?
Regarding DNS Crypt Proxy with Unbound DNS – General Network Interfaces, should here be really selected All Interfaces or just specific, like LAN, VLAN and OpenVPN Connection?
What are further recommended Settings under Unbound DNS – Advanced?
Thx
Advanced Configurations in https://docs.opnsense.org/manual/unbound.html#advanced-configurations (https://docs.opnsense.org/manual/unbound.html#advanced-configurations)
is describing new way to add custom option into unbound.
So I did create file
/usr/local/etc/unbound.opnsense.d/dns-crypt-forward.conf
with this content
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
forward-addr: ::1@5353
command configctl unbound check is OK with that
now, question is how to check if unbound is forwarding queries to dns-cryopt?
so trying these webs:
- http://verteiltesysteme.net/ saying OK
- https://dnsleaktest.com/ running extetended test and result is list of different DNS resolvers from different countries
- https://cmdns.dev.dns-oarc.net/ looks OK
Quote from: janci on September 14, 2021, 07:07:31 AM
Advanced Configurations in https://docs.opnsense.org/manual/unbound.html#advanced-configurations (https://docs.opnsense.org/manual/unbound.html#advanced-configurations)
is describing new way to add custom option into unbound.
So I did create file
/usr/local/etc/unbound.opnsense.d/dns-crypt-forward.conf
with this content
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
forward-addr: ::1@5353
command configctl unbound check is OK with that
now, question is how to check if unbound is forwarding queries to dns-cryopt?
so trying these webs:
- http://verteiltesysteme.net/ saying OK
- https://dnsleaktest.com/ running extetended test and result is list of different DNS resolvers from different countries
- https://cmdns.dev.dns-oarc.net/ looks OK
Thanks for all the setup details it worked great! The easiest way to see it was working was to look in Services: DNSCrypt-Proxy: Log / Queries and seeing entries appear!
Can I adopt this configuration 1:1? In this setup, the proxy and relay server have been connected. Or is that not intended?
https://codeberg.org/DecaTec/dnscrypt-proxy-config/commit/6dc93c83e3d7c2249075264bf7ca46ae54a83835
Version 23.7 needs some adoption as it has a small bug.
The configuration file must be:
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
forward-addr: ::1@5353
server:
Note duplicated server: at the end of the block
I added the custom config like this:
server:
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353
forward-addr: ::1@5353
But I get an error:
root@OPNsense:/usr/local/etc/unbound.opnsense.d # configctl unbound check
[1697893333] unbound-checkconf[21658:0] error: duplicate forward zone . ignored.
no errors in /var/unbound/unbound.conf
what I'm doing wrong?
ok find the misconfiguration:
got also forwarding configured under Services: Unbound DNS: DNS over TLS
disabled both entries solved my problem.
I have a stupid question: if you want secure DNS queries, why not just use DNS over TCL?
@senser because it's not the only thing I want.
now it works, I don't have an idea what was wrong the last time.
I made any changes to the file after reading docs and tips.
just tried following this guide. i get the port in use error if i use 127.0.0.1:5353 and or ::1:5353. i currently have 0.0.0.0:5353 set and leak tests seems to wok, but i think this puts me in standalone mode. which would negate the need for unbound correct?
is there anyway to get the 127 and ::1 working?
As a pointer for what you might need to tweak in your configuration of OPN: 0.0.0.0:5353 means listen on that port on all interfaces, and that will include 127.0.0.1 aka "loopback".
Hi,
the Unbound Docu say on top also set listening and unbound interfaces to "All" but what are the implications when the "WAN Interface" is listening on Port 5353 for example? Just want to be sure, that my Opnsense cannot be used from others then, to be a Public DNS Server?
Warning
Below table contains the options to manually set listening and outbound interfaces, the recommended setting for both is "All" for good reasons. Unless you absolutely know what you are doing, best keep these settings default as misuse often causes startup issues.
Trying now to create a local loopack interface
Interfaces -> Other Type -> Loopback -> + > Name LO1
Interfaces -> Assigment Name "LO1",
Interfaces -> LO1 - Enable Interface
IPv4 Configuration Type: Static IPv4
IPv4 address: 127.0.0.1/8
When i try to save i get the error: The following input errors were detected:
• This IPv4 address is being used by another interface or VIP.
Has someone correctly accomplished this?