Not a pi-hole user, but what is the plan for pi-hole once encrypted dns is everywhere? Will it just be dead? I can’t really think of a way for it not to be.
The pi-hole software turns the Raspberry Pi into a DNS server, so you can point your own DNS server (i.e. the raspberry pi) at the DNS provider of your choosing so that it can resolve uncached queries.
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.).
He is referring to the fact that apps will start ignoring local network DNS config and directly talk to their own hard coded DNS IPs.
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.
> I could forsee apps going to random IPs for DNS and making it look like https, which will be hard to deal with.
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.
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 ...
DoT isn't a big problem for a pihole, but it doesn't look like things are going that way. DoH can only be blocked by a mitm proxy. You would have to take a pretty serious security hit to do something like that with a pihole.
My understanding is the concern would be that closed source applications would use a hardcoded DoH resolver and pinned certs to bypass any unwanted blocks of ads/telemetry which could only be resolved with decompilation and patching with varying degrees of difficulty.
> My understanding is the concern would be that closed source applications would use a hardcoded DoH resolver and pinned certs to bypass any unwanted blocks of ads/telemetry which could only be resolved with decompilation and patching with varying degrees of difficulty.
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.
Sure, but if you're worried about them using a specific DNS, aren't you already worried about them not using DNS; resolving `phonehome.evil.co` once per release and shipping the baked-in IP? Stops working if it can't reach that IP, 'xx needs to update', gets new IP?
Whitelisting would make it much more difficult for wildcat DoH. On the gripping hand, whitelisting is extremely annoying and tends to block more work-related-and-useful than software that is actually malicious.
But DoH is just any other HTTP request. This is the downside of networks blocking everything except 80/443 outbound and browsers not supporting SRV records.
I think you're misremembering. This is the most official documentation of the rollout plan for DoH that I can quickly ddg: https://www.chromium.org/developers/dns-over-https - in a gist: If the systems resolver is known to support DoH, the DNS query will get upgraded to DoH. That means chrome will still be using the configured systems resolver, but the connection will be encrypted.
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.
