this issue can be reproduced with the unicast instance of that provider as well:
[root@maverick ~]# kdig @89.233.43.71 +dnssec +bufsize=1232 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-hostname=unicast.censurfridns.dk -d
;; DEBUG: Querying for owner(.), class(1), type(2), server(89.233.43.71), port(853), protocol(TCP)
;; DEBUG: TLS, imported 138 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG: #1, CN=unicast.censurfridns.dk
;; DEBUG: SHA-256 PIN: INSZEZpDoWKiavosV2/xVT8O83vk/RRwS+LTiL+IpHs=
;; DEBUG: #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG: SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded.
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 89.233.43.71@853(TCP)
Interesting to see, will dig deeper in order to find out what exactly goes wrong here…
EDIT: This looks like the certificate comes with the “OCSP must staple”-flag set, but the OCSP information provided is too old - perhaps a broken cron job at the operators’ side?
I thought maybe I had just been too quick with my testing of the anycast option. So I have waited to the following day but on my system it still comes up showing Error against the anycast but works fine for the unicast.
I will feed it back to censurfridns but I have enough other tls based options running fine in my list.
since the anycast instance of this service most possibly redirects you to different systems based on the location your query comes from, it seems like some of those systems still server outdated OCSP information, while some do not.
The user experience will therefore depend on the users location… Did I mention I do not really like anycast?
For the anycast Peters explanation would fit. Less sure about the Unicast, that “should” stay consistent.
Anyway with the error occurring on and off, I removed Censurfridns from my list. I have not had any errors with the ones I have left running and I don’t have any Anycast ones on the list now.
indeed, it is strange to see this problem flapping on the unicast instance.
A load-balancing setup (with one broken machine behind it) would be a plausible
explanation. Anyway: Has anybody tried to contact the services’ operator on this?
Today I saw that the censurfridns unicast dns server address had an error status. Checking with dig showed it was the same OCSP issue.
I have communicated this to Thomas Rasmussen at censurfridns.
I also saw that I had an error with the Freifunk Munich DNS server. Their problem seems to be related to their certificate chain using an expired certificate. So I have also let them know about what I have found.
I have had feedback from Freifunk Munich. They changed their DNS Server IP address some while back. It is an anycast server. I used the new IP Address and the anycast hostname and there is no error but reverse lookup fails.
I will update the wiki page on DNS over TLS servers.
The reason for the Reverse Lookup Failure is that due to a lot of relocations of servers recently they have not been able to maintain all PTR zones but it is on their agenda to be updated.
Right now these servers keep showing Error for a while, it could be because of recent holidays and operators were busy with other stuff or because of new year and Certificates expired?