A lock with many keys: Spoofing DNSSEC-signed domains in 8.8.8.8
sidnlabs.nl
sidnlabs.nl
Upon further testing, only Google was found to have had this problem.
There's also a comprehensive list and comparison of various DNS providers at PrivacyGuides[1].
[0]: https://adguard-dns.com/ [1]: https://privacyguides.org/providers/dns/
Only if you have a local network of machines can you consider making one of these machines the resolver for the local network. A typical example of this might be your router. This machine should then not forward the DNS requests to some centralized resolver, it should resolve DNS queries itself.
I use cloudflared to do DNS lookups via Cloudflare’s Tor onion. It’s weak to vulnerabilities like this one, but it disassociates my DNS lookups from myself, and TLS certificates mitigate the risk of hitting spoofed sites.
The longer-term solution is to wait for DoT to become prevalent in authorative servers.
But, realistically, won’t you “leak” your IP anyway when you make your actual connection? I mean, why are you looking up things in the DNS if not to connect to them? And if you make a connection, you leak your IP.
If you’re not concerned with the other party’s DNS servers, but with the root servers and TLD DNS servers snooping on your queries, I think you’ll have to wait for QNAME minimization to arrive.
> The longer-term solution is to wait for DoT to become prevalent in authorative servers.
That has a serious deployment problem, far more so than ECH. It’s going to be years (and years and years) before a person can successfully do recursive resolution via TLS. Is that even on anyone’s roadmap?
It is not the only way. I use scan.io as one source of DNS data. No need for resolvers. The needed data can be saved to a zone file for a local authoritative server or a map file for a forward proxy. The later option requires no DNS at all.
1. A pi-hole on my local network for most devices. I configured my router to forcibly capture all (unencrypted) DNS queries and forward them to my pi-hole, which then forwards them upstream to Cloudflare's DNS (over TLS).
2. I wrote a simple DNS forwarder (over TLS) that uses a 'shotgun' approach to ensure timely query responses, among other performance-sensitive features. I use this on all my Linux machines. It runs as a service and never fails, mean latency is much lower than other forwarders I've tried, including systemd-resolved, unbound, etc.
1.1.1.2 & 1.0.0.2 are their malware-blocking servers.
https://blog.cloudflare.com/introducing-1-1-1-1-for-families...
It's been discussed before
https://news.ycombinator.com/item?id=19828317
I use that site quite often so it makes it a bit of a no-go.
apt-get install unboundExcuse me?
That's quite an urgent and serious bug and I'm afraid that is too low, especially from a $1TN dollar company with billions of users.
Not many things rely on DNSSEC. Things that do rely on DNSSEC usually tend to have their own verifying resolver. (Because the idea of "we need signed DNS records, but we'll let google check that and maybe not even encrypt our connection to google" is not a very good one.)
This sounds like hyperbole, but it's not. That's how much of a mess DNSSEC is. Try to reason through what kind of entity would need to get paged over a DNSSEC breach, and tabletop it. It's hard for me to think of anybody who would need to care; even the people who "use" DNSSEC could wait until their next maintenance window to respond.