You actually bring up a good point and I've taken a step back to re-evaluate my view on this topic and approach. My concern has been privacy which includes DNS snooping by my ISP, along with some DNS hijacking concerns. After I posted the discussion here, I dug more into the topic of DOH from my router manufacturers POV and these points were covered well. While DOH would provide a level of security for the DNS request, from there, the ISP can still see everything HTTP and enough leaked info using HTTPs to in essence, have enough to track your browsing habits. DOH is not the catch-all that I had initially read about, although it would be a incremental improvement given the plain text DNS services that we live with today. Having that HTTPS tunnel back to the DNS service is at some level, piece of mind for DNS security.
In our household, I run two PiHoles. One to provide our kids network family filtering, and the other for the rest of our DNS traffic, a router level approach to DOH would be complicated. Hence the reason I'm looking at PiHole level DOH.
Customarily, your ISP may analyse your DNS traffic and try to monetarise on it.
When using Pi-hole (or your router config) to bypass your ISP's DNS servers, your ISP won't be able to log your requests directly at their DNS server, but they still could filter port 53 to much the same effect.
Encrypting DNS traffic would shield the DNS requests from 3rd party prying and make it much harder to filter them (with DoH) or to tamper with them (with both DoH and DoT), but now the receiving DNS server of your choice will have full access to your DNS history, and that may still be corrupted and deliver wrong DNS answers without you realising it does (unless you are also using DNSSEC).
So it comes down to a matter of whom you trust more.
Encrypting your DNS requests does make sense to disallow third party sniffing and manipulation, but a privacy gain would most obviously apply when you use it in public networks like a WiFi cafe.
When trying to make it harder for your ISP (and anyone else) to assess your DNS history, you may also consider using unbound with Pi-hole.
All correct. But at the end the day, I get to tighten the reigns a little and determine who I trust most by having that DNS level of control and HTTPS connection security. Setup correctly, I'd know I'm only connecting to the DNS of my choice.
For me, using DNS level filter for the kids accomplishes a lot and to be able to securely tunnel to the DNS provider I chose, provides that extra handshake. Especially since the DNS provider is doing the filtering, any leaks and I'd lose that.
The way I look at it, imagine yourself in a crowded room. I scream "hey Google, where is...?" Everyone hears, even if they're not interested. This could be your ISP, etc... This is analogous to DNS today.
Now if I use a phone connected directly to Google, well, it makes it a lot more difficult for someone to listen in as now I have that direct line. Analogous to DoH.
As for the privacy gain while on the road in a cafe or a hotel, well that's why I have a VPN, but with the understanding that I'm going to take a throughput hit.
Thanks for the suggestion for Unbound. I'll have to take a look at this.
I'm currently using, but I'm wondering if it isn't possible to use (non logging) DOH as upstream instead? There exists a guide for cloudfare, but their reputation isn't that good. I would like to use a trusty non logging/non US DOH instead. How can this be achieved?
Many thanks for the explanation.
You should inquire about this with your chosen trusty provider.
They should be able to point you to the appropriate DoH software packages.
Once installed, configure Pi-hole to use only that as upstream DNS server.
I guess that's the issue. So far, I didn't see no non logging DOH services having the same functionality as cloudfared. I was wondering if there wasn't something general that could be used as DOH 'proxy'
As Dan noted, DoT is a better option than DoH. Both provide the encryption you seek.
If you want an upstream server that has a good privacy policy, consider Quad 9. These configuration lines in unbound will get you going with DoT to Quad 9.
I tested this setup and found it was fairly slow (queries typically took 3.5 times as long as recursive unbound), but you may see different performance.
I'm just interpreting what jfb saided in the last sentence of his post. I might be wrong in that interpretation, but I'm not an expert concerning that matter and rely on what others say.
To clarify, is this why we would use a custom port for DNS?
My pihole is currently configured with both Quad9(unfiltered) with a custom dns (OpenDNS).
@jfb the configuration provided for DOT is only provided for Quad9. Would I be able to support both OpenDns and Quad9? Would they just be coma separated in the configuration file?
@DanSchaper stated to use DoT and shared a github link and @jfb you shared the configuration for unbound to get started with DoT - would we need to be running both Stubby and unbound?