That’s annoying yet pretty predictable, at least we’ve still got https://pi-hole.net/ as an option until DNS encryption becomes widespread :/
replies(4):
I don't think encryption matters because you control the sender (your PC), the first hop (the pi-hole), and the next resolution destination (Cloudflare/Quad9/Google/OpenDNS/etc.).
What key store? User-hostile apps (like Chrome) already use their own key store because they know better than the user :^)
I think you're remembering what firefox is rolling out: Firefox will by default, if DoH is enabled for your country by default use a specific provider that subjects to additional privacy controls. However, firefox respects network level settings (for example a specific canary domain that should resolve) and will disable DoH, even if the default is enabled - unless again, the user has overwritten that in a setting. That means that the network owner is still in full control of the network-wide default and PiHole supports this approach. So a stock firefox in a network that uses pi-hole will not use DoH.
I'm guessing the solution to that is to firewall various DNS IPs to force the app to use your local DNS. I could forsee apps going to random IPs for DNS and making it look like https, which will be hard to deal with.
First, I created my own recursive resolver in the cloud using 'unbound'. You can do this quickly and easily with an EC2 instance or whatever (mine is a FreeBSD jail on my own server).
Second, I got a paid nextdns.io account and enabled the basic blocklists which are, essentially, the same as ublock origin would have locally.
Third, I set my recursive resolver to use the nextdns.io endpoint as its upstream source of DNS.
Finally, I set all of my networks to assign my personal DNS server (and no others) for all DHCP requests and I hardcoded it into my own machines.
So now I control my own dns, globally, and my upstream source of name resolution is "sanitized". Theoretically, I could just remove ublock origin from my browsers now ...
Then I
DoH isn't really going to look like https, the requests and responses are going to be too small.
If you're serious about it, you don't allow any random IP connections, only allow connections to IPs that were received by DNS, and only return proxy addresses that you NAT to the real thing. It's more work, but it's still trivial.
Doesn't that relegate your recursive resolver to a stub?
You could run pi-hole on fly.io for free if DoT/DoH is all you need: https://fly.io/blog/stuff-your-pi-hole-from-anywhere/
I run a public DoH resolver with 170+ blocklists on Cloudflare Workers. Might open source it soon.
Works for a home / office setup. I think the main use of DoH is circumventing government enforced censorships, to an extent that it can.
For ISPs to use "packet sizes" they'd need to run stateful firewalls at scale, which is unheard of, and possibly very expensive to run at that scale.
IIRC, the vision with DoH is that eventually even browsers would do DNS as part of a bunch of pipelined HTTP requests. So you call up https://www.example.com/page.html and www.example.com resolves img.example.com for you since it's used on the page. The downside is www.example.com could also resolve tracker.adnetwork.com for you, too.
IIRC, DoH is there to defeat MITM attacks, but stuff like Pi-Hole is basically a MITM attack, so it's kinda collateral damage.
I bet network-level ad-blocking will eventually have to evolve into literal firewall rules on the gateway.
According to the stats, about a year ago, I used to block around ~40% of traffic via DNS. Recently, it's only about ~10% of traffic that gets blocked.
Despite disabling application-level DoH in favor of network-level DoH on every device and app I could, I suspect streaming devices and various Android apps are using DoH at the application-level and are bypassing my DNS entirely.