Has anyone been able to use DoT upstream with a LetsEncrypt certificate? I know they don’t issue certificates on bare IP addresses and therefore the upstream server may not be able to verify Unbound’s signature based only on the domain name.
Do I need a certificate for Unbound’s IP address for DoT to work? If so, is there a free CA that emits those?
:Has anyone been able to use DoT upstream with a LetsEncrypt certificate? I know they don't issue certificates on bare IP addresses and therefore the upstream server may not be able to verify Unbound's signature based only on the domain name.
:
:Do I need a certificate for Unbound's IP address for DoT to work? If so, is there a free CA that emits those?
I am doing DoT with a hostname, but sadly no bare IPs in the
certificate. I just got a regular certificate using ACME, saved it to a
spot unbound can read and just send a reload when it changes.
RIPE NCC did try to deploy Discovery of Designated Resolvers (RFC9462),
which depends on bare IPs in the cert, at the RIPE 87 meeting in December
2023, but found that LE does not support bare IPs.
For more details:
https://ripe87.ripe.net/archives/video/1267/
Starting at Page 15 of the slides
Starting at 9:00 of the video
Thanks for the video link. I am wondering how you managed to get DoT working with a hostname. I get the following error when trying to do DoT upstream:
notice: ssl handshake failed 8.8.8.8 port 853
[1706721743] unbound[15556:2] error: ssl handshake failed crypto error:0A000086:SSL routines::certificate verify failed
I don't use upstream forwarding or anything like that. I only use DoT
as a server.
But that error suggests that unbound doesn't know how to verify the
certificate given by Google. 1) make sure you are running ntp and have
correct time, and 2) add the cert bundle with
'tls-cert-bundle: "/etc/ssl/cert.pem"'. The path is correct for OpenBSD,
if you are using a different OS then adjust to the relevant path.
-peter
I was using my LetsEncrypt certificate bundle as tls-cert-bundle, fixed it by using the default SSL bundle, as per your instructions, however since I activated tls-upstream, I've been getting SSL handshake errors:
[1706962424] unbound[17322:2] error: str: channel closed
[1706962424] unbound[17322:2] notice: ssl handshake failed 2001:500:a8::e port 53
[1706962424] unbound[17322:2] error: str: channel closed
[1706962424] unbound[17322:2] notice: ssl handshake failed 2001:500:a8::e port 53
[1706962437] unbound[17322:2] error: str: channel closed
[1706962437] unbound[17322:2] notice: ssl handshake failed 2001:500:200::b port 53
[1706962438] unbound[17322:2] error: str: channel closed
[1706962438] unbound[17322:2] notice: ssl handshake failed 2001:500:200::b port 53
Aren't this requests supposed to be going out to port 853 instead of 53? I tested it with a stub server configured towards 8.8.8.8@853#dns.google and it worked fine so I don't think the certificate is the issue here.
As per RFC 9462, Unbound should include in the additional section, both the A and AAAA records for the name of the Designated Resolver when responding to queries for "resolver.arpa". However, I couldn't get this to work on my server. I have created a local zone file for the domain and it is replying properly to the SVCB queries, except for the additional section. Has anyone encountered this issue?