Certificates are now usually tested just for matching name and signature from trusted CA present on the system. I think that exactly should be used by dnssec-trigger. Unbound supports specification of "ip#tls-servername" format for some time. It should be used instead of weird SPKI hash digests of self-signed certificate. That is already accepted by unbound, but is not used by dnssec-triggerd. Also I think we want to use port 853 if that is not blocked by the network. Fallback to ssl443 should be only last resort, if nothing else has worked. Unfortunately no decent public server offers DNS over TLS on port 443. And unbound cannot forward DNS over HTTPS, although it can serve queries to it. Reproducible: Always Steps to Reproduce: 1. for NS in $(grep ^ssl /etc/dnssec-trigger/dnssec-trigger.conf | cut -d' ' -f2 | head -1); do openssl s_client -connect $NS:443 < /dev/null; done 2. dig +tls +tls-ca -p 443 -4 @unbound-ib01.fedoraproject.org 3. Actual Results: ;; TLS peer certificate verification for 152.19.134.150#443 failed: EE certificate key too weak Expected Results: Something like: dig +tls +tls-ca -p 443 -4 @zus.nlnetlabs.nl Upstream ticket: https://github.com/NLnetLabs/dnssec-trigger/issues/12 Fedora infra ticket: https://pagure.io/fedora-infrastructure/issue/11415
Note: On page https://dnsprivacy.org/public_resolvers/ all production grade services do not provide SPKI hashes. That leads me to conclusion their use is deprecated in favor of classic TLS certificates, possibly maintained by ACME protocol refreshes.