OPNsense Forum

Archive => 19.1 Legacy Series => Topic started by: opnfwb on June 15, 2019, 06:16:49 pm

Title: OPNsense 19.1.x and DNSoverTLS with Hostname Verification
Post by: opnfwb on June 15, 2019, 06:16:49 pm
Greetings OPNsense users. I had previously opened a thread last spring when DNS over TLS was first available through CloudFlare and Quad9. This thread is available here and discussed some initial configurations that we could use to enable DNS over TLS with the version of OPNsense that was currently available back then. OldThread: https://forum.opnsense.org/index.php?topic=7811.0

Today I'd like to post this as more of a Howto for the current version (19.1.9) of OPNsense on x86-64. There are some additional features that we can use to ensure better security while using DNS over TLS.

This example shows Quad9 and also shows the hostname verification for those DNS servers. We also have to tell Unbound to use the TLS cert bundle to verify that the hostname matches the certificate.
The following text can be copy/pasted in to your Custom unbound options:
Code: [Select]
# TLS Config
tls-cert-bundle: "/etc/ssl/cert.pem"
# Forwarding Config
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 9.9.9.9@853#quad9.net
forward-addr: 149.112.112.112@853#quad9.net
   
Another item I have noticed is that if we are going to use Unbound in forwarding mode (using the code above puts Unbound in forwarding mode), you DO NOT need to enable DNSSEC with CloudFlare or Quad9. They already do DNSSEC verification on their results and if we configure Unbound to forward through those services, we do not need to do extra work to create more DNSSEC traffic on DNS entries that are already receiving DNSSEC from our forwarding location. We can verify that DNSSEC continues to work here: http://www.dnssec-or-not.org/

Below is also an example for CloudFlare, if you prefer to us them as well. I have tested both of these configurations and they work very well with OPNsense 19.1.9 x86-64. If using the CloudFlare code below, you can also test that it is working by visiting this link after applying the code: https://1.1.1.1/help
Code: [Select]
# TLS Config
tls-cert-bundle: "/etc/ssl/cert.pem"
# Forwarding Config
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#1dot1dot1dot1.cloudflare-dns.com
forward-addr: 1.0.0.1@853#1dot1dot1dot1.cloudflare-dns.com

Finally, I have attached some screenshots to show further optimizations that I have done within Unbound General and Unbound Advanced configuration pages. The Advanced settings further tune Unbound to enable better caching response (serve expired), and to also enable better privacy. If you like, you can also set your Unbound Advanced to the same settings as shown in these screenshots and you should see snappier performance as a result of Unbound doing better caching.

Also ensure that when using forwarding mode, the System DNS is blank. Navigate to System/Settings/General, if any DNS servers are specified there they should be removed. Then, ensure that "allow DHCP override on WAN" is also unchecked. This will make the router use the local Unbound service with our chosen settings to forward DNS over TLS.

As always, would love to see if other folks are also seeing positive results with these settings or if there are even better options that we can use, please post them here!
Title: Re: OPNsense 19.1.x and DNSoverTLS with Hostname Verification
Post by: kanstin on June 16, 2019, 10:22:37 pm
This is great! Thank you, opnfwb!

I would like to add the following. In addition to the above configuration, in System:Settings:General you have to remove all dns servers. It must be blank as shown in the attached image. Also, LibreSSL doesn't seem to work for longer than just a few seconds for me. I had to switch to OpenSSL.

Title: Re: OPNsense 19.1.x and DNSoverTLS with Hostname Verification
Post by: opnfwb on June 26, 2019, 02:22:10 pm
kanstin, this is a great point! I've updated the original post to reflect this as well. Thank you!
Title: Re: OPNsense 19.1.x and DNSoverTLS with Hostname Verification
Post by: JohnDoe17 on June 30, 2019, 05:18:00 am
Good stuff!  Thanks!
 :D
Title: Re: OPNsense 19.1.x and DNSoverTLS with Hostname Verification
Post by: JohnDoe17 on July 01, 2019, 01:16:20 am
I *think* the configs need to be adjusted slightly...

NOTE the additional "dns" in the "dns.quad9.net" string.
Code: [Select]
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net

NOTE the removal of "1dot1dot1dot1dot1" in the "cloudflare-dns.com" string.
Code: [Select]
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com

Maybe someone can confirm this or not.
Title: Re: OPNsense 19.1.x and DNSoverTLS with Hostname Verification
Post by: donatom3 on July 01, 2019, 06:37:14 am
Thanks this config is working great for me.
One question about privacy though.

Under Advanced Settings "Hide Identity" and "Hide Version" aren't those only hiding it from my devices that are making dns queries to unbound?

In my access lists no outside networks are allowed so doesn't that mean my router isn't going to give it's hostname and version away to any outside parties?
Title: Re: OPNsense 19.1.x and DNSoverTLS with Hostname Verification
Post by: opnfwb on July 01, 2019, 02:45:26 pm
I *think* the configs need to be adjusted slightly...

NOTE the additional "dns" in the "dns.quad9.net" string.
Code: [Select]
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net

NOTE the removal of "1dot1dot1dot1dot1" in the "cloudflare-dns.com" string.
Code: [Select]
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com

Maybe someone can confirm this or not.

Thanks for pointing this out. In CloudFlare's case, they have several DNS names that seem to work when using hostname verification. The base cloudflare-dns.com and 1dot1dot1dot1dot1.cloudflare-dns.com are valid here. They will also allow the use of "one.one.one.one", but I did not list that because I thought it would cause confusion for those expecting a more normal hostname. CloudFlare also has a DNS tutorial for Android that specifically mentioned the full DNS name, so that's the one I chose to use for the config listed here. Here is the CloudFlare Android link for reference: https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/android/

In regards to Quad9, the cert seems to work with their base domain quad9.net and with dns.quad9.net. I tried both interchangeably and both worked within Unbound. For a cleaner looking config I think its probably fine to shorten up the DNS hostname to just cloudflare-dns.com or quad9.net. Although based on how the hostname certs are used, I'm not sure it matters as long as the certificate includes the main hostname?

Also for those interested, you can create a fake name, such as "fakedns.com" and use that in the Unbound configuration with Quad9 or CloudFlare. Check the unbound logs and you should see auth failures when using this spoofed hostname. Change it back to their actual domain with the correct cert and it should work again.

For instance, this should result in failures within your Unbound logs:
Code: [Select]
forward-addr: 1.1.1.1@853#afakednsname.comAnd this line should of course, result in an operational state again:
Code: [Select]
forward-addr: 1.1.1.1@853#1dot1dot1dot1.cloudflare-dns.com
Under Advanced Settings "Hide Identity" and "Hide Version" aren't those only hiding it from my devices that are making dns queries to unbound?

In my access lists no outside networks are allowed so doesn't that mean my router isn't going to give it's hostname and version away to any outside parties?
Good question, my understanding is that this only applies to Unbound when querying and/or forwarding requests to the WAN. However, I will admit that I am not the authoritative source here so it's possible that maybe Unbound also supplies its version information to internal LAN clients that request it? I leave both options checked because in theory it should reduce the ability to "fingerprint" your system as it sends DNS requests to the WAN because we aren't disclosing any version information that could be used to uniquely identify us.