Using DNS over TLS on windows

RayG · July 21, 2019, 3:37pm

Hi,

I have configured things so far but I get these errors and I think the reason is the “tls-cert-bundle” setting.

``

16:10:16 C:\Program Files\Unbound\unbound.exe[1740:0] error: ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

21/07/2019

``

So to get this working I have to enable this setting:

``

tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

``

That example would seem OK for a UNIX install but where/how do I configure this for windows?

``

Can I use the windows certificate store? If so what would the entry read.

``

Thanks

Regards

Ray

``

yvoinov · July 21, 2019, 6:50pm

Just an example from working Windows setup:

Unbound configuration file on windows.

See example.conf for more settings and syntax

server:

verbosity level 0-4 of logging

verbosity: 0

if you want to log to a file use

logfile: “C:\unbound.log”

on Windows, this setting makes reports go into the Application log

found in ControlPanels - System tasks - Logs

use-syslog: yes
log-time-ascii: yes
num-threads: 4
cache-max-ttl: 14400
cache-min-ttl: 900
cache-max-negative-ttl: 60
infra-host-ttl: 60

root-hints: “C:\Program Files\Unbound\named.root”

hide-identity: yes
hide-version: yes
hide-trustanchor: yes

do-ip6: no

tls-cert-bundle: “C:\Squid\etc\squid\ca-bundle.crt”
tls-win-cert: yes
tcp-upstream: yes

harden-short-bufsize: yes
harden-large-queries: yes
harden-below-nxdomain: yes
harden-algo-downgrade: yes

1.5.7 feature. Yes recommended.

From 1.7.2 yes is default

#qname-minimisation: yes
aggressive-nsec: yes

select from the fastest servers this many times out of 1000. 0 means

the fast server select is disabled. prefetches are not sped up.

fast-server-permil: 0

fast-server-permil: 100

the number of servers that will be used in the fast server selection.

fast-server-num: 3

fast-server-num: 4

unwanted-reply-threshold: 10000000
do-not-query-localhost: no
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes

access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow_snoop
access-control: ::0/0 refuse
access-control: ::1 allow
access-control: ::ffff:127.0.0.1 allow

#include: “C:\Program Files\Unbound\unbound_local”
include: “C:\Program Files\Unbound\unbound_ad_servers”

Remote control config section.

remote-control:

Enable remote control with unbound-control(8) here.

set up the keys and certificates with unbound-control-setup.

control-enable: yes
control-use-cert: no

forward-zone:
name: “.”

forward-addr: 208.67.222.222@53

forward-addr: 208.67.220.220@53

forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net
forward-addr: 145.100.185.15@443#dnsovertls.sinodun.com
forward-addr: 145.100.185.16@443#dnsovertls1.sinodun.com
forward-addr: 185.49.141.37@853#getdnsapi.net
forward-addr: 89.233.43.71@853#unicast.censurfridns.dk
forward-addr: 158.64.1.29@853#kaitain.restena.lu
forward-addr: 145.100.185.18@853#dnsovertls3.sinodun.com
forward-addr: 145.100.185.17@853#dnsovertls2.sinodun.com
forward-addr: 199.58.81.218@853#dns.cmrg.net
forward-addr: 94.130.110.185@853#ns1.dnsprivacy.at
forward-addr: 94.130.110.178@853#ns2.dnsprivacy.at
forward-addr: 99.192.182.200@853#iana.tenta.io
forward-addr: 99.192.182.201@853#iana.tenta.io
forward-addr: 99.192.182.100@853#opennic.tenta.io
forward-addr: 99.192.182.101@853#opennic.tenta.io
forward-tls-upstream: yes

OpenDNS is NOT DNSSEC enabled

server: auto-trust-anchor-file: “C:\Program Files\Unbound\root.key”

RayG · July 22, 2019, 12:38pm

Hi Yuri,

Thanks for the config file very useful, but I still have the issue of:

tls-cert-bundle: “C:\Squid\etc\squid\ca-bundle.crt”

I do not have the file: “C:\Squid\etc\squid\ca-bundle.crt” on my system.

So my original question was were do I get that or a suitable file from?

Regards

Ray

yvoinov · July 22, 2019, 12:41pm

22.07.2019 18:38, rgsub1@btinternet.com пишет:

Hi Yuri,

Thanks for the config file very useful, but I still have the issue of:

tls-cert-bundle: "C:\Squid\etc\squid\ca-bundle.crt"

I do not have the file: "C:\Squid\etc\squid\ca-bundle.crt" on my system.

Sure. This is my system-specific.

In you case, you can download Mozilla's CA bundle from

https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt

and use it on similar manner (just specify correct path-to-file) on your
setup.

RayG · July 22, 2019, 2:21pm

Hi Yuri,

OK I see what was happening now. I can use either

tls-cert-bundle: ””

or

tls-win-cert: yes

or both

So now I can see:

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: SSL connection to cloudflare-dns.com authenticated ip4 1.0.0.1 port 853 (len 16)

So it looks like that bit is working OK but then when I go to:

http://1.1.1.1/help

to check that DNS over TLS is working it says “NO”

Looking at the log file further I see this where things appear to be blacklisted (see below) I have attached the log file and it is from the start of the unbound service to the end of the query to http://1.1.1.1/help I then stopped the unbound server to flush the log.

Any further insights would be helpful, thanks

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: resolving 8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. DS IN

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: request has dependency depth of 0

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: msg from cache lookup ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0

;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:

8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. IN DS

;; ANSWER SECTION:

;; AUTHORITY SECTION:

cloudflareresolve.com. 59 IN SOA cloudflareresolve.com. dns.cloudflare.com. 2018100101 21600 3600 604800 0

cloudflareresolve.com. 59 IN RRSIG SOA 13 2 3600 20190730125237 20190722095237 64088 cloudflareresolve.com. TQObnCdfCziZUkBWjUaAUFeU0iXbC7QK9tMC59qJqYZa8ntTdOHCmuWgUgRvVtaLK/l3GhNk65Jr+wHzs3Qnhg== ;{id = 64088}

8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. 60 IN NSEC \000.8946ae4B-99eC-4925-A951-078129AE2Afe.IS-cF.CLouDFlArerEsoLvE.Com. A HINFO TXT AAAA LOC SRV CERT SSHFP RRSIG NSEC TLSA HIP OPENPGPKEY SPF

8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. 60 IN RRSIG NSEC 13 4 3600 20190730135835 20190722105835 64088 cloudflareresolve.com. 1EhhluR/cdwni2q9HCdPmAazhlq/rwiOPAWytdeR8pPcNLjlpwphAoULC0tZ2BSZw2UC3P6vlgTHruBL+jpTRQ== ;{id = 64088}

;; ADDITIONAL SECTION:

;; MSG SIZE rcvd: 462

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: msg ttl is 60, prefetch ttl 54

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: returning answer from cache.

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: iter_handle processing q with state FINISHED RESPONSE STATE

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: finishing processing for 8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. DS IN

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: mesh_run: iterator module exit state is module_finished

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: validator operate: query 8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. DS IN

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: validator: nextmodule returned

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: not validating response, is valrec(validation recursion lookup)

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: mesh_run: validator module exit state is module_finished

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: validator: inform_super, sub is 8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. DS IN

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: super is 8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. A IN

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: NSEC RRset for the referral proved not a delegation point

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: validator[module 0] operate: extstate:module_wait_subquery event:module_event_pass

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: validator operate: query 8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. A IN

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: val handle processing q with state VAL_FINDKEY_STATE

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] info: validator: FindKey 8946ae4b-99ec-4925-a951-078129ae2afe.is-cf.cloudflareresolve.com. A IN

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: Cannot retrieve DS for signature

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: val handle processing q with state VAL_FINISHED_STATE

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: validation failed, blacklist and retry to fetch data

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: blacklist ip4 1.1.1.1 port 853 (len 16)

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: blacklist ip4 1.0.0.1 port 853 (len 16)

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: blacklist cache

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: blacklist ip6 2606:4700:4700::1001 port 853 (len 28)

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: blacklist add ip6 2606:4700:4700::1111 port 853 (len 28)

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: pass back to next module

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: mesh_run: validator module exit state is module_restart_next

22/07/2019 14:58:35 C:\Program Files\Unbound\unbound.exe[13564:0] debug: iterator[module 1] operate: extstate:module_finished event:module_event_pass

(attachments)

unbound.zip (225 KB)

yvoinov · July 22, 2019, 3:54pm

Either-or. I use first by historical reasons.

yvoinov · July 22, 2019, 3:57pm

Either-or. Im using first by historical reasons. Works fine my side.

(attachments)

yvoinov · July 22, 2019, 4:07pm

And, BTW.

When using Unbound + DoT on localhost, this test tool should not detect DoT, because you browser connects via Unbound on 127.0.0.1:53:

https://i.imgur.com/dHPVy0G.png

(use different way to check working).

This testing tool designed to detect DoT/DoH usage via smartphone with 1.1.1.1 mobile application:

George_Yorgos_Thessa · July 22, 2019, 4:21pm

Hi Ray,

It seems that cloudflare is using special subdomains (answered only from
their 1.1.1.1 resolvers) for the online checks and they are not handling
DNSSEC properly in regards to answers for these special subdomains.
Unbound is complaining about not being able to build a trust chain
because it can't get the DS information.

I suspect that if you turn off DNSSEC validation on your unbound
module-config: "iterator"
the online check should work. Although I would advise to turn it on
again after you do the online check.

And just to be clear, this does not mean that 1.1.1.1 cannot do DNSSEC.
I am only talking about the subdomains used for this specific online check.

-- George

yvoinov · July 22, 2019, 4:24pm

Yes, George,

probably you right. DNSSEC is separate issue.

22.07.2019 22:21, George Thessalonikefs via Unbound-users пишет:

RayG · July 22, 2019, 5:15pm

Hi George,

Thanks for that (I hope)

Having added that line into the configuration I see a different result. See the two attached images

Not Active: # module-config: "iterator" - DNSSEC enabled

Active : module-config: "iterator" - DNSSEC disabled

In the config file.

So if I leave DNSSEC enabled, whilst the test a https://1.1.1.1/help shows DOT is not enabled it is in fact all working OK as expected, is that correct?

I just wanted to make sure I was understanding what is happening.

So all in all I think I have it all working...

Just as an aside Firefox (if you use that) does DOH directly to the cloudflare servers and that also works OK.

Some other test servers that may be useful:

https://rootcanary.org/test.html

(attachments)

George_Yorgos_Thessa · July 23, 2019, 9:00am

Hi Ray,

RayG · October 3, 2019, 3:13pm

Hi George,

I have been reading this page:

https://support.cloudflare.com/hc/en-us/articles/360021111972-Troubleshooting-DNSSEC

Taking this error from the log file using Unbound V1.9.4:

03/10/2019 15:29:45 C:\Program Files\Unbound\unbound.exe[11788:0] info: validation failure <5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. A IN>: DS got unsigned CNAME answer from 2606:4700:4700::1001 and 1.0.0.1 for DS is-cf.cloudflareresolve.com. while building chain of trust

George_Yorgos_Thessa · October 4, 2019, 11:02am

Hi Ray,

I think that in all this you forgot that:

1.
The zone `is-cf.cloudflareresolve.com.` does not exist on the internet.
Only the 1.1.1.1 resolvers (and the resolvers that forward to those
resolvers like your unbound) will know of that zone and give a different
answer. This was specifically crafted for the online test you showed in
your previous emails. Everything else will just get the NSEC answer that
you posted below.

2.
As stated in previous emails the answer you get from the 1.1.1.1
resolvers is not signed properly. This is also what unbound is logging.
Unbound gets an unsigned record (CNAME) in a supposedly signed zone and
this fails validation. That is why you see the SERVFAIL answer.

Also see some answers inline where I try to clarify your comments.

-- George

Hi George,

I have been reading this page:

https://support.cloudflare.com/hc/en-us/articles/360021111972-Troubleshooting-DNSSEC

Taking this error from the log file using Unbound V1.9.4:

03/10/2019 15:29:45 C:\Program Files\Unbound\unbound.exe[11788:0] info: validation failure <5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. A IN>: DS got unsigned CNAME answer from 2606:4700:4700::1001 and 1.0.0.1 for DS is-cf.cloudflareresolve.com. while building chain of trust

================================

There is no 'ad' flag present in the response so DNSSEC has failed using unbound and it returns no data hence the error message in the log file.

C:\>dig 5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. +dnssec

; <<>> DiG 9.14.6 <<>> 5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37604
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. IN A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 03 15:50:46 GMT Summer Time 2019
;; MSG SIZE rcvd: 93

================================

Using my ISP's router I get this returned with an NSEC record to say the name queried does not exist (have I got that correct?)

Yes, your ISP router is probably using your ISP's resolvers (or other
resolvers but not the 1.1.1.1 resolvers for sure) which do not know
about the `is-cf.cloudflareresolve.com.` zone.

C:\>dig @192.168.1.254 5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. +dnssec

; <<>> DiG 9.14.6 <<>> @192.168.1.254 5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10727
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0384, udp: 4096
;; QUESTION SECTION:
;5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. IN A

;; AUTHORITY SECTION:
cloudflareresolve.com. 0 IN SOA cloudflareresolve.com. dns.cloudflare.com. 2018100101 21600 3600 604800 0
5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. 0 IN NSEC \000.5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. HINFO TXT AAAA LOC SRV CERT SSHFP RRSIG NSEC TLSA HIP OPENPGPKEY SPF
cloudflareresolve.com. 0 IN RRSIG SOA 13 2 3600 20191011133931 20191003103931 64088 cloudflareresolve.com. ipLptq2Quw5wHXI5i09sydRWMJXiPVEP7F0jTuFsxvIYrgo/KW1mLbMV 30Iqokf79cF+Ruwhsg6D+cv+6klZ5A==
5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com. 0 IN RRSIG NSEC 13 4 3600 20191011144045 20191003114045 64088 cloudflareresolve.com. VChj42IfF+549QC1k/q8NJglytBVYZOXovTENcIqRQ5YWkvdrJrC+07a zvX7lcTeI092wIfYIHl6pImhKDABzA==

;; Query time: 152 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Thu Oct 03 15:52:24 GMT Summer Time 2019
;; MSG SIZE rcvd: 473

================================

The NSEC I think says remove the first subdomain (if doing a DNSSEC chain of trust walk) and try again. Repeat as many times as required.

In short the NSEC proves that the domain you asked for does not exist.

So, if I knock off the first part of the subdomain: 5a196f4c-afe8-442e-b258-ee7373f136a5 I get the same results

I am assuming you are referring to unbound and the SERVFAIL answer. Yes,
the reply has the same DNSSEC problem (unsigned CNAME record).

If I then knock off the: is-cf I see this result:

C:\>dig cloudflareresolve.com. +dnssec

; <<>> DiG 9.14.6 <<>> cloudflareresolve.com. +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36595
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cloudflareresolve.com. IN A

;; AUTHORITY SECTION:
cloudflareresolve.com. 60 IN SOA cloudflareresolve.com. dns.cloudflare.com. 2018100101 21600 3600 604800 0
cloudflareresolve.com. 60 IN RRSIG SOA 13 2 3600 20191011133931 20191003103931 64088 cloudflareresolve.com. ipLptq2Quw5wHXI5i09sydRWMJXiPVEP7F0jTuFsxvIYrgo/KW1mLbMV 30Iqokf79cF+Ruwhsg6D+cv+6klZ5A==
cloudflareresolve.com. 60 IN NSEC \000.cloudflareresolve.com. NS SOA HINFO MX TXT AAAA LOC SRV CERT SSHFP RRSIG NSEC DNSKEY TLSA HIP OPENPGPKEY SPF
cloudflareresolve.com. 60 IN RRSIG NSEC 13 2 3600 20191011143217 20191003113217 64088 cloudflareresolve.com. +xoOFZv/dFhYHHrkzdZtCY2RXv3VKLXwrHkQcp2pQFuQQc49lgj7QIy4 WoD6OqvJy0oyRclznazLBpYu5kXNjQ==

;; Query time: 211 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 03 15:57:09 GMT Summer Time 2019
;; MSG SIZE rcvd: 387

Which does have the 'ad' flag set and unbound returns the data. The same is true for the ISP's router.

The cloudflareresolve.com domain is properly answered by the cloudlflare
nameservers. No special answering from the 1.1.1.1 resolvers required
for this one.

So in this instance the domain name validates and therefore all is OK.

Using:

http://dnsviz.net/d/5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com/dnssec/

DNSSEC is validated and all looks just fine.

The same is true for:

https://dnssec-analyzer.verisignlabs.com/5a196f4c-afe8-442e-b258-ee7373f136a5.is-cf.cloudflareresolve.com

These tools don't use the 1.1.1.1 resolvers for these domains so they
just get the NSEC answers above which are properly signed.

These words I think explain what is happening:

"Dig also retrieves the public key used to verify the DNS record. A domain's DNS records are all signed with the same public key. Therefore, query for the root domain's public key, not the subdomain's public key:"

They are on this page (mentioned at the start):
https://support.cloudflare.com/hc/en-us/articles/360021111972-Troubleshooting-DNSSEC

So unless my reading and understanding of what should be happening is totally incorrect Unbound should be ignoring subdomains and tracking back to the actual domain name and if that validates then it should return the appropriate data.

The DNSSEC chain of trust is from the trust anchor (usually the root)
down to all the records required until you get your final answer. If
anything cannot validate in that path, then validation fails.

If I have this wrong then dnsviz and verisign should also fail the DNSSEC checks but they don’t appear to do so.

DNSviz and verisign's tool do not fail the DNSSEC validation because
they get the properly signed NSEC answers above.