Because a ISP that can compromise any one of those 140 different single points of failure can now make that one have the lowest latency and give you malicious DNS results just like you never secured anything.
This is the same problem as allowing 140 different CAs to issue certificates for subdomains of com, rather than forcing the fucking registry to do it when you get a domain name in the first place.
>minisign_key is a public key, used to verify that the content is legitimate. Lists can thus be served from any location, even from an untrusted ISP: dnscrypt-proxy will immediately detect and reject something that has been tampered with.
>https://dnscrypt.info/stamps-specifications/ >https://dnscrypt.info/faq
An ISP will not be able to spoof the sources or these stamps. They wouldn't put the effort in. Even if they did, it is factored and thought about.
More harmful would be a malicious DoH relay but I trust the devs.That I think is fixed by mandating the use of DNSSec too for my relays.
It also picks from 140 or so anonymous DoH relays, with specifics for nologs and dnscrypt support.
Why would I go for just 1 arbitrary provider rather than the lowest latency choice out of 140?
I also think the latter point is a bit overblown. So long as you keep your kernel updated and you only expose a single high UDP port, it should all be fine. I have ufw enabled on each pi, along with various logging mechanisms in place to see if things seem reasonable. That and 2fa for actual ssh access.