TLDR: Google Public DNS would, until 23 February, not check that the ZSK (signing key used to sign DNSSEC DNS responses) was in turn signed by the KSK. Google would accept any signed response, by any ZSK. Even worse, they would cache this response, and present it to end users as being non-DNSSEC signed.
Upon further testing, only Google was found to have had this problem.
Very cool to see a SIDN labs post here. SIDN operates the .nl extension and puts the money earned into these kinds of research projects that benefit everyone.
Cloudflare's malware blocking service is my go-to. 1.1.1.2, supporting DoH and DoT. I prefer them over Quad9 because Google blog post listed several malware domains and Quad9 only caught half, while Cloudflare caught them all.
https://www.reddit.com/r/Quad9/comments/t9b9v1/quad9_not_cat...
I am on 1.1.1.1 and it resolves archive.is just fine. I seemingly can't view a number of pages there because of "no cipher overlap" if I turn on https-only but that is not a cloudflare dns problem.
Run your own resolver, on your local machine. It’s the only way.
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.
"Run your own resolver, on your local machine. It's the only way."
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.
But that would leak all of my DNS queries in cleartext.
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.
> But that would leak all of my DNS queries in cleartext.
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.
Recursive resolution leaks all my DNS queries in plaintext to my ISP, the nameservers, and everyone in between; on top of that, my ISP can monitor what sites I’m viewing through SNI and server IP. If my DNS queries are encrypted and anonymized, my ISP only gets SNI and server IP. And ECH seems to be moving quickly, so within a couple of years I expect the SNI leak to be plugged.
> 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?
AdGuard[0]. Ad-blocking included :)
It's on 94.140.14.14, 94.140.15.15 (know them by heart now) if you want to try it. I've never had a problem with them.
There's also a comprehensive list and comparison of various DNS providers at PrivacyGuides[1].
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.
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.)
Google overbid this bounty by something like $4,999. The root DNSSEC keys could land on Pastebin tomorrow and almost nobody in the entire industry would need to be paged, because virtually no one relies on DNSSEC --- even the people who performatively enable it aren't actually relying on it.
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.
Upon further testing, only Google was found to have had this problem.