Closed demarcush closed 2 weeks ago
And yet they're the most likely target by hackers and state actors. What a shame!
Certificates are different for dns.cloudflare.com
and the ones with IP SANs. Do both of them change all the time?
Maybe we can salvage one group by providing the hash.
@jedisct1
We should keep sdns://AgcAAAAAAAAABzEuMC4wLjEAEmRucy5jbG91ZGZsYXJlLmNvbQovZG5zLXF1ZXJ5
.
This is a special entry for dnscrypt-proxy
, and there's some history behind it, that goes back to before Cloudflare DNS was publicly announced.
https://www.reddit.com/r/dnscrypt/comments/1dxke0m/dnscrypt_stopped_working_on_multiple_docker/
Crap. Wondering if this is related.
Weirdly enough, I can't find the latest dnscrypt-proxy package for Debian stable (link). 2.0.45 (from 4 yrs ago!) is the latest version supported on Debian oldstable. Yet as this link suggests, default version was v3 for that.
So, user didn't bother to update the container or migrate to the native package by Debian. And probably copied the example config file from the latest release of the time during initial configuration (which was meant for a v3 supporting release).
I'm not convinced even a v2 user of the software would have problems with the changes made to Cloudflare.
Yeah, they had a Frankenstein configuration. IP addresses should indeed be fine even for v2 users.
But the problem wasn't the IP addrs used as hostnames. It was the fact that v2 didn't support multi stamps under one entry.
Yes.
Cloudflare certificates change all the time, and this is also inconsistent depending on the client location. Unfortunately, we can't include hashes for them, this breaks too frequently.