OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: opnfwb on April 04, 2018, 12:54:02 am
-
Call out for testing DNS over TLS with the new Quad9 and Cloudflare DNS servers that have been discussed recently. I wanted to see if we could get the default Unbound instance in OPNsense to use these new DNS encrypted and privacy oriented DNS providers.
I’m currently using these and this appears to be working because I can see all of the outbound queries in the pfTop view on OPNsense. I see outbound DNS queries on port 853 going to the addresses that I have specified in the custom options. Internal LAN queries come in over port 53 as per usual but outbound queries to the WAN now happen on Port 853 to the DNS TLS providers listed below.
Here are the settings I have configured to get Unbound to send DNS over TLS to Quad9 and Cloudflare.
OPNsense x86_64 18.1.5
UnboundDNS/General
Enable DNS resolver (checked)Enable DNSSEC support (checked)Enable Forwarding mode (UNCHECKED, had to do this to get these to work)
Paste these values in to the custom options field. Save/Apply settings.
Custom Options:
ssl-upstream: yes
forward-zone:
name: "."
forward-addr: 9.9.9.9@853 #Quad9 ip4
forward-addr: 149.112.112.112@853 #Quad9 ip4
forward-addr: 2620:fe::fe@853 #Quad9 ip6
forward-addr: 1.1.1.1@853 #Cloudflare ip4
forward-addr: 1.0.0.1@853 #Cloudflare ip4
forward-addr: 2606:4700:4700::1111@853 #Cloudflare ip6
forward-addr: 2606:4700:4700::1001@853 #Cloudflare ip6
You should now have DNS queries going to Port 853 using TLS to the addresses specified in the custom options field. Obviously, if you aren’t using ipv6, you can omit some of the addresses. If you only want to use Quad9 or Cloudflare, you can omit whichever provider you don’t want to use.
I’d love to have other folks try this out and report their findings.
As far as I can tell this seems to be working very well and it was quite easy to configure. However, I don't consider myself an "advanced" user and I would like to see feedback from others here just to ensure that this is a good setup to use going forward.
-
Works perfectly fine here (so far).
Well done!
Although I would need to see those packets over a dump, to check if these are really going over TLS.
-
There is one Twitter thread here with an error report... https://twitter.com/colinsmall/status/981348043080585216
But it might be the ISP getting in the way.
Cheers,
Franco
-
No such thing here... Still working fine :)
-
I've seen the no cipher warning recently... it was due to a PAN firewall playing with fire in SSL proxy / peek mode, but failing to know a couple of ciphers that LibreSSL could do. ;)
-
Tried it, sadly unbound stops working aftter some minutes, stating "SSL_handshake syscall: Connection reset by peer"
I'm using only the Quad9 address and LibreSSL.
-
Just for fun, try OpenSSL.
-
Just for fun, try OpenSSL.
Same thing, resolver.log shows no error
-
I'm also using Quad9 with LibreSSL. Still working fine :)
-
My bad, unbound wasn't starting because of an include, seems to work so far..
I'll retry with LibreSSL.
Is there a log file other than resolver.log?
Edit:
Unbound dies with both OpenSSL and LibreSSL after approximately 2 minutes with a handshake failure "no ciphers available; ssl handshake failed 9.9.9.9 port 853".
With LibreSSL I also see:
"error: could not SSL_new crypto error: 14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version"
-
It still looks like someone is meddling with your (DNS) SSL stream. :(
-
Well OPNsense is running behind an ISP router, but I don't think this is the issue, since I never had any problems with this setup..
There is no proxy or interception running on OPNsense or elsewhere.
-
This is also how some MITM attacks/behaviors look like.
Not saying that your ISP does something similar, but something/somebody is interfering with it. Maybe a service running on that same port?
-
There is an updated version of unbound available - 1.7.0
Amongst the features:
"Accept tls-upstream in unbound.conf, the ssl-upstream keyword is also recognized and means the same. Also for tls-port, tls-service-key, tls-service-pem, stub-tls-upstream and forward-tls-upstream."
http://www.unbound.net/download.html
-
This is also how some MITM attacks/behaviors look like.
Not saying that your ISP does something similar, but something/somebody is interfering with it. Maybe a service running on that same port?
Every other TLS connection works fine and has the expected certificate, a test with openssl s_client to 9.9.9.9:853 succeeded..
-
Hmm.. Maybe a packet capture can shed some light what on what is going on there.. have you tried that?
-
A few weeks back I was having the same cipher-drop issue, since then I've upgraded a few times and seeing this topic start I decided to give DNS over TLS another try. So far this morning it started out great and then I ran into a similar issue as others, the specific error is:
unbound: notice: ssl handshake failed 149.112.112.112 port 853
unbound: [pid:0] error ssl handshake failed crypto error:140020B5:SSL routines:CONNECT_CW_CLNT_HELLO:no ciphers available
I'm running:
OPNsense 18.7.a_186-amd64
FreeBSD 11.1-RELEASE-p8
LibreSSL 2.6.4
Unbound 1.6.8_2
My unbound custom options follows Calomel's Unbound DNS (https://www.calomel.org/unbound_dns.html) pretty closely:
server:
hide-trustanchor: yes
harden-large-queries: yes
minimal-responses: yes
harden-algo-downgrade: yes
qname-minimisation-strict: yes
ignore-cd-flag: yes
use-caps-for-id: yes
ssl-upstream: yes
private-domain: "example.com"
private-domain: "lab.example.com"
domain-insecure: "onion"
private-domain: "onion"
do-not-query-localhost: no
local-zone: "onion." nodefault
forward-zone:
name: "onion"
forward-addr: 127.0.0.1@9053
# forward-zone:
# name: "."
# forward-addr:9.9.9.9 #quad9 non-encrypted
# forward-addr:149.112.112.112 #quad9 non-encrypted secondary
#include: /var/unbound/ad-blacklist.conf
forward-zone:
name: "."
forward-addr: 9.9.9.9@853 # quad9.net primary
forward-addr: 149.112.112.112@853 # quad9.net secondary
forward-addr: 145.100.185.18@853 # Surfnet dnsovertls3.sinodun.com
forward-addr: 145.100.185.17@853 # Surfnet dnsovertls2.sinodun.com
Edit: Currently trying OpenSSL flavor, will report, currently capturing tcp/853.
Edit 2: After >1hr of testing on OpenSSL and LibreSSL, this error hasn't replicated. Still capturing tcp/853 and will post if err.
-
Keep in mind, something is going on with Cloudflare's DNS-over-TLS implementation.. sometime last night it stopped answering queries properly... can't find any info on the cause yet...
-
Still going strong here... absolutely no issues...
-
So, I initially had this working yesterday using directives that were given in a thread of the pfSense forum, using the following advanced options:
server:
ssl-upstream: yes
do-tcp: yes
forward-zone:
name: "."
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853
The primary difference here being that the instructions there also included the "do-tcp: yes" directive.. This mostly worked -- however my Unbound logfile was showing sporadic instances of "unbound: [50404:1] error: outgoing tcp: connect: Address already in use for 1.1.1.1"
I went back to enabling forwarding mode, and deleted the advanced options.. I have the 1.1.1.1 and 1.0.0.1 addresses in System:Settings:General, and in nonsecured mode - they work.
However -- if I now try to re-enable TLS using the configuration instructions here (or even the original one that was working yesterday), all of my DNS queries are failing. The logfile is showing entries like:
Apr 4 10:43:35 unbound: [81143:0] debug: tcp error for address ip4 1.0.0.1 port 853 (len 16)
Apr 4 10:43:35 unbound: [81143:0] debug: outnettcp got tcp error -1
Not sure what happened between yesterday and today.. Im on OPNsense 18.1.5-amd64
FreeBSD 11.1-RELEASE-p8
OpenSSL 1.0.2n 7 Dec 2017
Thanks,
Rick
-
Keep in mind, something is going on with Cloudflare's DNS-over-TLS implementation.. sometime last night it stopped answering queries properly... can't find any info on the cause yet...
Hmmm.. OK, this would make sense.. I just tried the configuration using just the Quad9 9.9.9.9 address, and TLS works.. Its just the Cloudflare addresses that are failing.
-
Two OPNsense devices running currently, one on LibreSSL and one on OpenSSL, both with DNS-over-TLS (see config above) and aside from the first glitch mentioned earlier all since then as been running smoothly.
Edit: Same error as in reply #16 to 9.9.9.9 on the LibreSSL system. No errors on OpenSSL yet.
Edit 2: Here's the last entries before Unbound (LibreSSL) crashed:
Edit 3: Removed output.
Unbound Debug
8<---->8
Packet Capture (short)
8<--->8
-
Much more to gain using Quad9 than Cloudflare anyway. Those 10-15 ms faster performance with Cloudflare is nothing compared to the security offered by Quad9. Regarding privacy.. that's something for you to decide.
-
Do I have to open any ports in NAT/Firewall to make this work? Just setting up as per OP did not work.
-
Do I have to open any ports in NAT/Firewall to make this work?
No.
-
The primary difference here being that the instructions there also included the "do-tcp: yes" directive..
This is a good observation, I noticed this as well when I was setting this up yesterday and reading the Calomel Unbound tutorial. However, I checked the default unbound.conf file and it already included "do-tcp: yes" in the config on my box so I assumed it was baked in to OPNsense already. It probably doesn't hurt to list it again in the advanced options but in my case, it was not necessary because it was already included in the baseline config.
For those interested, this is my unbound.conf file, you can see the Advanced options appended to the bottom by OPNsense for the DNS/TLS servers. I'm only using Quad9 at the moment.
Also worth noting, my unbound.conf also includes additional tweaks that were configured via Services/Unbound/Advanced. So it may look a little different that a 100% stock file but, the do-tcp: yes value was there even before customization.
##########################
# Unbound Configuration
##########################
##
# Server configuration
##
server:
chroot: /var/unbound
username: unbound
directory: /var/unbound
pidfile: /var/run/unbound.pid
use-syslog: yes
port: 53
verbosity: 1
hide-identity: yes
hide-version: yes
harden-referral-path: no
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
module-config: "validator iterator"
cache-max-ttl: 86400
cache-min-ttl: 0
harden-dnssec-stripped: yes
serve-expired: yes
outgoing-num-tcp: 20
incoming-num-tcp: 20
num-queries-per-thread: 1024
outgoing-range: 2048
infra-host-ttl: 900
infra-cache-numhosts: 10000
unwanted-reply-threshold: 0
jostle-timeout: 500
msg-cache-size: 100m
rrset-cache-size: 200m
num-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
auto-trust-anchor-file: /var/unbound/root.key
prefetch: yes
prefetch-key: yes
# Statistics
# Unbound Statistics
statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes
# Interface IP(s) to bind to
interface: 0.0.0.0
interface: ::0
interface-automatic: yes
# DNS Rebinding
# For DNS Rebinding prevention
#
# All these addresses are either private or should not be routable in the global IPv4 or IPv6 internet.
#
# IPv4 Addresses
#
private-address: 0.0.0.0/8 # Broadcast address
private-address: 10.0.0.0/8
private-address: 100.64.0.0/10
private-address: 127.0.0.0/8 # Loopback Localhost
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 192.0.0.0/24 # IANA IPv4 special purpose net
private-address: 192.0.2.0/24 # Documentation network TEST-NET
private-address: 192.168.0.0/16
private-address: 198.18.0.0/15 # Used for testing inter-network communications
private-address: 198.51.100.0/24 # Documentation network TEST-NET-2
private-address: 203.0.113.0/24 # Documentation network TEST-NET-3
private-address: 233.252.0.0/24 # Documentation network MCAST-TEST-NET
#
# IPv6 Addresses
#
private-address: ::1/128 # Loopback Localhost
private-address: 2001:db8::/32 # Documentation network IPv6
private-address: fc00::/8 # Unique local address (ULA) part of "fc00::/7", not defined yet
private-address: fd00::/8 # Unique local address (ULA) part of "fc00::/7", "/48" prefix group
private-address: fe80::/10 # Link-local address (LLA)
# Access lists
include: /var/unbound/access_lists.conf
# Static host entries
include: /var/unbound/host_entries.conf
# DHCP leases (if configured)
include: /var/unbound/dhcpleases.conf
# Domain overrides
include: /var/unbound/domainoverrides.conf
# Unbound custom options
ssl-upstream: yes
forward-zone:
name: "."
forward-addr: 9.9.9.9@853
forward-addr: 149.112.112.112@853
forward-addr: 2620:fe::fe@853
###
# Remote Control Config
###
include: /var/unbound/remotecontrol.conf
-
Trying to use cloudflare doesn't work for me. I tried six ways from Sunday and no luck.
I switched to 9.9.9.9 (Quad9) and tls works fine.
I also switched to OpenSSL from LibreSSL prior to switching to Quad9.
I verified with a WAN packet capture in Wireshark that it is TLS/encrypted.
I'm not sure why Cloudflare doesn't work.
-
Cloudflare is some sorts of proxy for anything behind them, they intercept all queries before reaching the destination. Including encrypted communication. I didn't try, but without dnssec this may work with Cloudflare as well (although dnssec is not encrypted DNS communication, it is a signed response, with which Cloudflare may interfere).
-
Is there anyone who only uses the Cloudflare DNS servers successfully in this setup? If they don't work that would explain why it did not work for me.
-
Is there anyone who only uses the Cloudflare DNS servers successfully in this setup? If they don't work that would explain why it did not work for me.
I was also trying to use Cloudflare DNS exclusively and wasn't having any luck with 1.1.1.1 or 1.0.0.1 via TLS.
Quad9 is working great though using the provided examples.
-
Yes, thats what I saw. Hopefully someone else can confirm as well, because according to Cloudflares website (https://developers.cloudflare.com/1.1.1.1/dns-over-tls/) they should support DNS over TLS.
But I'm pretty newbie in all this.
-
They do.. for 2 minutes ;D
-
Just an FYI -- Apparently there is an issue with 1.1.1.1 and Unbound that Cloudflare is aware of and will be resolved in their next update.. No ETA..
See attached
https://community.cloudflare.com/t/1-1-1-1-was-working-but-not-anymore/15136/4
-
Thanks for the report!
-
Looks like they have fixed the issue with Unbound already 8)
https://community.cloudflare.com/t/1-1-1-1-was-working-but-not-anymore/15136/7
So far so good testing on my side.
-
Just to be sure.
You specify the same DNS servers in the "General" settings, and then add this to the advanced section of Unbound?
-
For fallback cases, yes. If you delete these custom options (tls forwards) and re-enable forwarding mode, the DNS servers configured under "General" will be used.
-
Thanks.
Only had it running for a few minutes, but it looks Cloudflare DNS (only) is working. :)
-
Does seem to be working once again with TLS for me as well.. Also not receiving the "error: outgoing tcp: connect: Address already in use for 1.1.1.1" messages in the log (so far)
-
Great initiative. It would be amazing to have DNS-over-TLS support i Opnsense.
But just to be clear: the long term goal would be to support DNS-over-(TLS/HTTPS) on all links, that is
a) Client stub (desktop/laptop/smartphone) -> local forwarder (Opnsense)
b) local forwarder (Opnsense) -> resolver (external, eg 1.1.1.1/Quad9)
c) resolver -> authoritative nameservers
What we are focusing on right now is link b).
Link a) might be considered "private", since it's on our local subnet. But anyway, the configuration of any local clients can not be easily automated. (It must be done manually until a new DHCP-option is standardised some time in the future.)
Link c) we don't control (unless we run a resolver on Opnsense). Either way, the "resolver-to-auth" spec is still in early draft stage (1).
As for b):
Unfortunately, Unbound does not (yet) support authenticating the upstream TLS server (2).
Since the connection is not authenticated, it only protects against passive attackers (eavesdropping), not active on-path attackers (man-in-the-middle).
Unbound also does not support configuring the TLS client options(?) (specify supported versions, ciphersuites etc).
Stubby has partial support for this:
"Stubby supports TLS v1.2. In 'Strict' mode Stubby is limited to using the 4 Cipher Suites recommended in RFC7525, in Opportunistic mode is uses the default OpenSSL Cipher suites." (3)
One alternative listed by the dnsprivacy-project is to use Unbound+Stubby together (4):
local client -> unbound (caching proxy) -> stubby (running on same host as unbound) -> (DNS-over-TLS) -> external resolver (1.1.1.1/quad9 etc)
Stubby (aka getdns) can authenticate the upstream resolver, using the dnsName in the certificate, and by verifying that the certificate chains to a trust anchor (list of CAs) (5)
The dnsprivacy-project (6) is a great resource for understanding the challenges with DNS-privacy, and how DNS privacy is supported in various DNS software (10).
Just for reference, the relevant standards are:
"DNS-over-TLS" (7)
"Usage Profiles for DNS over TLS and DNS over DTLS" (8 )
- just published (march 2018)
- specifies 2 privacy profiles
- strict (authenticate upstream server either via pubkey fingerprint, or by trust-chain+dns-name)
- opportunistic (authentication of upstream server not required, basically what Unbound supports today)
"DNS-over-HTTPS" (9)
- still in draft, but supported by both 1.1.1.1 and GoogleDNS
(1) https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01
(2) https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658
(3) https://dnsprivacy.org/wiki/display/DP/About+Stubby
(4) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients
(5) https://github.com/juzam/docker-getdns-stubby/blob/master/stubby.yml
(6) https://dnsprivacy.org
(7) https://tools.ietf.org/html/rfc7858
(8 ) https://tools.ietf.org/html/rfc8310
(9) https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-05
(10) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
And while we are discussing Cloudflare DNS, privacy and sharing logs with others:
https://community.cloudflare.com/t/privacy-policy-link/14890/4
;)
-
Very nice summary, thank you!
Indeed, you're right. There's much to be done generally in order to get true security.
The only true security based on encryption is where you (to encrypt) and the decrypting party know the key. There is no other method. If you are not allowed to use your own key/password in any form and the decrypting party is not allowed to add that exact key to decrypt the communication, that's not true security.
For regular people, this is not an issue of course, most of the times.
Welcome to OPNsense!
-
Does anyone else get occasional entries like below in their Unbound logs?
unbound: [49413:0] error: outgoing tcp: connect: Address already in use for 1.1.1.1
-
I also saw this error in the Unbound logs but, it has only happened one time on each of the addresses. I was wondering if it has something to do with CloudFlare's anycast address changing during a DNS request?
Apr 8 08:50:15 unbound: [53283:3] error: outgoing tcp: connect: Address already in use for 2606:4700:4700::1001
Apr 7 23:45:06 unbound: [53283:1] error: outgoing tcp: connect: Address already in use for 1.1.1.1
-
Just thought I'd throw in that it's been working for me with Quad9 for a couple days with two different installations with no issues.
-
This seemed to work really nicely for a while, but after about 10 minutes unbound dies with:
Apr 11 15:14:17 unbound: [87750:0] notice: ssl handshake failed 1.0.0.1 port 853
Apr 11 15:14:17 unbound: [87750:0] error: ssl handshake failed crypto error:140020B5:SSL
Rebooted several times, result is always a dead unbound after a while
Logs did show requests going to port 853 though, this is really promising.
-
When I use the supplied settings nothing seems to resolve. I see the following errors in my logs:
unbound: [1433:0] error: ssl handshake failed crypto error:140020B5:SSL routines:CONNECT_CW_CLNT_HELLO:no ciphers available
and a bunch of these:
unbound: [1433:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
-
Works fine for me :)
My Settings:
(keep in mind i have setup up a Lancache with advertisement filtering)
harden-glue: yes
harden-short-bufsize: yes
harden-large-queries: yes
use-caps-for-id: yes
val-clean-additional: yes
cache-min-ttl: 3600
cache-max-ttl: 86400
num-threads: 4
msg-cache-slabs: 8
rrset-cache-slabs: 8
infra-cache-slabs: 8
key-cache-slabs: 8
rrset-cache-size: 256m
msg-cache-size: 128m
include: /var/unbound/ads_and_lancache.conf
unwanted-reply-threshold: 10000
qname-minimisation: yes
do-not-query-localhost: no
ssl-upstream: yes
forward-zone:
name: "."
forward-addr: 9.9.9.9@853
please excuse my bad English
Itow
-
Just wanted to post this interesting bit of info from Cloudflare regarding 1.1.1.1. I am still seeing occasional logs in Unbound showing the following.
unbound: [49082:2] error: outgoing tcp: connect: Address already in use for 1.1.1.1
unbound: [49082:3] error: outgoing tcp: connect: Address already in use for 1.0.0.1
It's very possible this could be related to the issues that Cloudflare is reporting here: https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
I have exclusively switched to Cloudflare and do not have any other DNS servers configured, just to verify if these errors seem to be impacting lookups. While I see these errors in the Unbound logs, I have no had any failures on DNS lookups. According to Cloudflare's findings, it looks bad for some AT&T users that are stuck with a Pace5268 modem/router.
-
Hello,
I'm a bit confused about the pros and cons of using this Cloudflare setup. Can someone enlighten me?
I thought the reason one might want to use unbound in resolve mode is so that all DNS queries would begin at the root servers, then resolve each step down so that you end up with a response that is for sure accurate. The downside is that this takes longer because you have to query multiple servers (and I guess the queries are not encrypted).
In forward mode, you're just querying your favorite server (e,g., OpenDNS) without going to the root servers. The pro is that this is faster. The con is that you're trusting that the server is not messing with the response (or tracking your queries). These queries are still not encrypted.
It sounds like this new server 1.1.1.1 is DNS using forward mode, with the same pros and cons, except they encrypt the queries, claim it's the fastest server, and claim to not log your queries.
Is the above summary correct in terms of the pros and cons?
-
Mostly - yes.
Some folks experience poor ISP provided dns (poorly maintained, outsourced to a data mining organization, etc) and are just looking for a fast reliable dns service. Several companies have stepped up to offer DNS, but people often don't take the time to understand what the motivation is for these companies.
Cloudflare has stated their motivation. I suspect it's what they've said plus that they can make a better content delivery decision when they know the real ip generating the query and not a intermediary DNS recursive server.
-
I have been running the original config with just quad9 on 18.1.7 (openssl) for more than 24 hours now and no problems. Great work, thanks!
-
Unbound still crashes after some minutes when using DNS TLS with Cloudflare.
Don't want to replace libressl for openssl, is there anything I could help to further investigate this issue?
-
For me it works for an hour or two, then it stops. The Unbound log is swamped with these. I'm on 18.1.7_1, LibreSSL flavour.
-
18.1.7 here with OpenSSL, no issues to report. Still using CloudFlare DoT settings from the first post, it has been rock solid stable. The only time Unbound restarts is when I reboot the router for an update. :D
-
Switching from LibreSSL to OpenSSL and DNS-over-TLS (Quad9 and Cloudflare) has been working for 48 h straight. Few and expected entries in the Unbound log during that time frame. I'm still on 18.1.7_1
-
Ive been using this configuration for a while, but I started getting the following errors in my Unbound logs recently.. Anyone know what they mean?
Jun 12 12:45:34 unbound: [79836:1] info: generate keytag query _ta-4a5c-4f66. NULL IN
Thanks,
Rick
-
I'm also seeing this.
Jun 13 17:30:52 unbound: [89359:2] info: generate keytag query _ta-4a5c-4f66. NULL IN
Jun 13 17:30:52 unbound: [89359:3] info: generate keytag query _ta-4a5c-4f66. NULL IN
Jun 13 17:19:54 unbound: [89359:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Jun 13 16:25:23 unbound: [89359:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Jun 13 15:28:45 unbound: [89359:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
-
I have these too without DNS TLS. Not sure what this is about.
Cheers,
Franco
-
Yes, a bit weird.
Also, lately it feels like the DNS has slowed down a bit. I get ~1000ms when I resolve a new domain. If it's cached I get 0ms.
drill -D norge.no @10.0.0.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36955
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; norge.no. IN A
;; ANSWER SECTION:
norge.no. 300 IN A 93.94.10.5
norge.no. 300 IN RRSIG A 14 2 300 20180628000000 20180607000000 52173 norge.no. hRF42hSawMhG8IpIEtOall6XPFV8n/MHKm6XyD4QrgIO+9z/NGa8MTRTItkdDEKksR4klEUGsDWKTkk/6hQ52BmZosAegVbbI13z4H4g3Hj3wJ7WxpJzfbTzWTdORrvG
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 1603 msec
;; EDNS: version 0; flags: do ; udp: 4096
;; SERVER: 10.0.0.1
;; WHEN: Mon Jun 18 20:02:52 2018
;; MSG SIZE rcvd: 189
drill -D norge.no @10.0.0.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 56876
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; norge.no. IN A
;; ANSWER SECTION:
norge.no. 265 IN A 93.94.10.5
norge.no. 265 IN RRSIG A 14 2 300 20180628000000 20180607000000 52173 norge.no. hRF42hSawMhG8IpIEtOall6XPFV8n/MHKm6XyD4QrgIO+9z/NGa8MTRTItkdDEKksR4klEUGsDWKTkk/6hQ52BmZosAegVbbI13z4H4g3Hj3wJ7WxpJzfbTzWTdORrvG
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; EDNS: version 0; flags: do ; udp: 4096
;; SERVER: 10.0.0.1
;; WHEN: Mon Jun 18 20:03:28 2018
;; MSG SIZE rcvd: 189
I feel ~1 second is a bit too much. Any input on this?
-
I had reported earlier that this was rock solid on 18.1.7 using OpenSSL. I also had no problems with 18.1.8. With 18.1.9 unbound stopped 3 times over the life of 18.1.9 (3 weeks). I just upgraded to 18.1.10 and unbound died within an hour. I am not sure what to post to help solve the problem, but this nice feature doesn't seem to work anymore.
-
Upgrading to 18.1.10 I stayed with the OpenSSL version for a few hours, my default. I had no issues. It was a plain upgrade from 18.1.9 without any changes to the configuration. I then switched to the LibreSSL version (I did not forget the compulsory upgrade) and for the first time, dns-over-tls worked equally well as with OpenSSL. At least as far as I can assess. It's been close to 24 h since I made the switch.
-
I tried again today without any config changes, and 18.1.10 openssl. Everything is running fine after about 15 hours. Not sure why it failed quickly yesterday and is fine today.
-
Anyone of you that experience ~1 second when you visit a new domain?
Sent from my iPhone using Tapatalk Pro
-
This is what resolvers do: ask DNS root servers for your query and it takes a while. Afterwards the answer is cached and considerably faster to respond on subsequent queries.
Cheers,
Franco
-
Yes, but a second per query? And the ttl does not exactly last long.
Sent from my iPhone using Tapatalk Pro
-
You ask "why", but it's easily possible to say "why not"?
It heavily depends on your network conditions and it's not super unlikely to be 1 second.
Cheers,
Franco
-
Thanks. I'm on a 260mbit / 20 mbit cable connection.
But this got me to dig a bit deeper, and it seems like an internal server (10.233.128.1) of the ISP is the problem. Apparently, it is their DHCP server (https://forum.opnsense.org/index.php?topic=7818).
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets
1 10.233.128.1 (10.233.128.1) 969.363 ms 363.980 ms 47.442 ms
2 cm-<redacted>.getinternet.no (<redacted>) 112.461 ms 102.901 ms 22.952 ms
3 ae6.no-323-rt1.get.no (185.1.55.18) 7.610 ms 16.708 ms 23.552 ms
4 185.1.55.41 (185.1.55.41) 27.113 ms 22.835 ms 26.102 ms
5 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 24.120 ms 23.919 ms 24.059 ms
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
1 opnsense (10.0.0.1) 1.053 ms 0.784 ms 0.743 ms
2 10.233.128.1 (10.233.128.1) 246.141 ms 13.284 ms 105.476 ms
3 cm-<redacted>.getinternet.no (<redacted>) 1147.611 ms 555.554 ms 462.964 ms
4 ae6.no-323-rt1.get.no (185.1.55.18) 10.045 ms 16.408 ms 24.218 ms
5 185.1.55.41 (185.1.55.41) 164.107 ms 21.188 ms 23.941 ms
6 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 270.039 ms 175.628 ms 12.147 ms
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
1 opnsense (10.0.0.1) 3.347 ms 0.780 ms 1.008 ms
2 10.233.128.1 (10.233.128.1) 47.112 ms 891.952 ms 297.987 ms
3 cm-<redacted>.getinternet.no (<redacted>) 288.130 ms 17.094 ms 126.216 ms
4 ae6.no-323-rt1.get.no (185.1.55.18) 89.709 ms 19.233 ms 16.726 ms
5 185.1.55.41 (185.1.55.41) 8.411 ms 13.376 ms 9.940 ms
6 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 19.957 ms 7.618 ms 16.547 ms
Not sure what's going on, but I guess I should contact my ISP.
-
Unfortunately some ISPs meddle with DNS resolution when you don't use their servers. :/
Cheers,
Franco
-
This helped me speed up DNS resolution.
Finally, Under Services, DHCP Server, set your DNS Server to your pfSense’s LAN IP. As your DHCP clients renew their lease they’ll start using pfSense for DNS.
As far as performance if you have low latency to your ISPs DNS you probably won’t notice anything. But if you’re on a high latency connection with 70ms pings like I am, this makes a big difference.
https://b3n.org/hijacked-slow-dns-unbound-pfsense/
-
My ISP scheduled maintenance in my area today, and that fixed the problem.
traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets
1 10.233.128.1 (10.233.128.1) 5.552 ms 5.609 ms 6.073 ms
2 cm-<redacted>.getinternet.no (<redacted>) 6.184 ms 5.962 ms 5.686 ms
3 ae6.no-323-rt1.get.no (185.1.55.18) 6.356 ms 6.060 ms 5.798 ms
4 185.1.55.41 (185.1.55.41) 6.215 ms 3.942 ms 6.099 ms
5 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 5.686 ms 5.894 ms 6.002 ms
Their "IT department" has tried to get a hold of me every day this week (except today), but I haven't been able to pick up the phone in time. Calling back I just get the default customer service, and they apparently sees that it's "IT" that tries to contact me, but they can't put me through since they are not allowed ("IT" decides for themselves when to call – pretty typical I think).
Anyhow, seems like my reporting lit a fire under their ass, and it seems fixed. :)
-
Cool, glad to hear! 8)
-
I'm OPNsense noob, but have few years behind as a sysadmin. Beware of Cloudflare DNS. They do CDN+SSL, effectively MITMing the client website, terminating SSL to plaintext at edge nodes, and inserting/modifying scripts and html. They can see your passwords for these sites as plaintext and you'll have no idea if the site is behing Cloudflare. Same as with Google DNS, your browsing history (DNS requests) is probably linked to your IP/fingerprint, and then to your profile.
-
I'm trying to setup DNS over TLS in unbound as per this thread and I don't get it working. So far I've tested with the custom options included by the OP and mjh, but as long as I enter any "forward-zone" or the line "ssl-upstream" it does stop resolving.
Also tried those instructions without success: https://forum.opnsense.org/index.php?topic=9197.msg41265#msg41265
Is it that something changed in opnsense recently or is my isp that is blocking TSL? I've tried with Quad9 non secure dns in general settings and does work.
An example of my custom options that doesn't work:
#include:/var/unbound/ad-blacklist.conf
#server:
log-replies: yes
# hide-trustanchor: yes
# harden-large-queries: yes
# minimal-responses: yes
# harden-algo-downgrade: yes
# qname-minimisation-strict: yes
# ignore-cd-flag: yes
# use-caps-for-id: yes
# ssl-upstream: yes
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 9.9.9.9@853
forward-addr: 149.112.112.112@853
Edit: The next day those settings are working. Don't know what could be, but it seems true that anything get fixed with some rest.
-
Did anybody try with newer versions of LibreSSL recently to make this work? Had to switch to openssl to make it work (again?) in summer...
-
OK, tried it myself, switched a completely updated x64 full install from openSSL to libreSSL, but within 3 minutes Unbound is ended, the general log says:
Oct 12 11:34:47 kernel: pid 50815 (unbound), uid 59: exited on signal 11
and unbound log says:
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:1] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:2] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
Oct 12 11:34:47 unbound: [50815:0] error: could not SSL_new crypto error:14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version
OPNsense (c) 2014-2018 Deciso B.V.
-------------------
Manually restarting unbound doesn't help for long:
Oct 12 11:40:51 kernel: -> pid: 28971 ppid: 1 p_pax: 0x850<SEGVGUARD,ASLR,NODISALLOWMAP32BIT>
Oct 12 11:40:51 kernel: [HBSD SEGVGUARD] [unbound (28971)] Suspension expired.
Oct 12 11:40:51 kernel: pid 28971 (unbound), uid 59: exited on signal 11
in the general log, but no corresponding entries in the unbound log.
-
Tried something new:
switched to DNS server
46.182.19.48@853
(Digitalcourage), commenting out the other TLS-DNS servers proposed above (Cloudflare...). Checked that it works.
Subsequently switched to LibreSSL and rebooted. Now working fine for some time, no crashes for unbound yet. :-)
-
...was running stable for weeks, yesterday I updated from 18.7.7 to 18.7.9 (LibreSSL 2.7.4), now I'm back to
System - Log Files - General
Dec 19 08:18:06 kernel: -> pid: 13623 ppid: 1 p_pax: 0x850<SEGVGUARD,ASLR,NODISALLOWMAP32BIT>
Dec 19 08:18:06 kernel: [HBSD SEGVGUARD] [unbound (13623)] Suspension expired.
Dec 19 08:18:06 kernel: pid 13623 (unbound), uid 59: exited on signal 11
...every 20 min or so... :-(
-
opnsense-revert -r 18.7.7 unbound
should help ...
-
yepp! thanks! time to lock the package?!?
-
Just updated to 18.7.10, same problem, DNS unbound dies after a few minutes. I reverted to unbound to 18.7.7 (1.8.1.)...