Bug: DNS forwarder / DNS sec checkboxes - error: ssl handshake failed crypto error:1

4o4rh

I have the clouflare services 1.1.1.3 and 1.1.1.2 in the general tab. With the default use localhost, fallback to remove.

in dns resolver i have
Enable DNSSEC Support - ticked
DNS Query Forwarding - ticked
Use SSL/TLS for outgoing DNS Queries to Forwarding Servers - ticked

i get no dns resolution on the clients

If i add the below to custom config it works. I thought the checkboxes, were supposed to replace the below requirement

forward-zone:
forward-ssl-upstream: yes
name: "."
forward-addr: 1.1.1.3@853 #Cloudflare ip4
forward-addr: 1.1.1.2@853 #Cloudflare ip4
forward-addr: 1.0.0.3@853 #Cloudflare ip4
forward-addr: 1.0.0.2@853 #Cloudflare ip4

johnpoz

@gwaitsi said in DNS forwarder / DNS sec checkboxes don't work:

Enable DNSSEC Support - ticked

If your going to forward.. There is NO point of ticking this.. Where you forward either does dnssec out of the box, or it doesn't - asking for dnssec when you forward doesn't accomplish anything.

Did they announce that dot is available on 111.2 and 111.3 yet? If not then no dot is not going to work for them. BTW those lists are different .2 does just malware, and .3 does malware and adult.. So your going to have issues - if .3 is ask site xxx.tld might be blocked, but if you ask .2 it wouldn't be.

If you want to block malware and adult then use .3 only.. It is anycast - there is no point to using more than just the single IP.

4o4rh

@johnpoz the reason I have 4, is that there are two WAN and two VPN connections and the text says that each gateway should have a unique DNS.

I setup below, so the gateway pools will always get the same results.
WAN1 1.1.1.2
WAN2 1.0.0.2
VPN1 1.1.1.3
VPN2 1.0.0.3

but neither that, nor the Enable DNSSec Support are the reason that forwarding check box is not forwarding i think

johnpoz

@gwaitsi said in DNS forwarder / DNS sec checkboxes don't work:

the text says that each gateway should have a unique DNS.

This is so you can get there if pointing to isp dns, since isp A isn't going to allow you to use its dns if your coming from isp B.

But this has nothing to do with your pointing to dns that uses different block lists.. Which is going to be problematic in actually getting the filtering you want.

What I would suggest you do is get 1 working, with you 1 connection before you start playing with multiple.

4o4rh

@johnpoz but each rule i have has the gateway pool specified.
eg.
WAN1/2 are both Tier1 and
VPN1/2 are Tier 1 and 2
so there won't be any cross pollinating so to speak

4o4rh

@gwaitsi i removed the two VPN ones, and that fixed it. thanks

4o4rh

@johnpoz John, i need to revise my original post. Removing the DNS from the VPNs, and disabling DNSSEC fixed the checkboxes not working at all, but there is definitely a functional issue here.

Using the checkboxes to do the forwarding, the below error appears in the logs

Mar 4 21:29:24 	unbound 	29887 	[29887:3] notice: ssl handshake failed 1.1.1.3 port 853
Mar 4 21:29:24 	unbound 	29887 	[29887:3] error: ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

disabling the two check boxes, and adding the below in the customs box, the log is clean

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.3@853
forward-addr: 1.0.0.3@853

so, there is something funny going on with these checkboxes