With problems and suggestions already posted I wanted to post something good. After updating my core system (ubuntu 18.04 in VM) and making sure pi-hole wasnt out of date. I went ahead and processed the update.
Everything went great including carrying over my cloudflared configuration. Which I built from the guide below (even though I use quad 9's addresses).
Just thought I'd inform those that may be curious while searching.
Honestly, I'm pretty disappointed that Cloudflared didn't get baked into the 5.0 release.
DoH is about to become big and it would have been nice to see Pi-Hole lead the way.
It's a bit of a missed opportunity IMO.
I don't think you are ever going to see Pi-hole include a DoH function.
Thanks for the quick reply! Can I ask how come? Would love to understand why.
Personally I don't like DoH, it's not the right solution.
As far as Pi-hole, including another projects code and having to maintain it just isn't feasible for us.
Fair enough. I completely understand your second point and that does make sense. Your guide, linked above, works perfectly so why add more code to maintain.
Are you more an advocate of DoT then or just not encrypting DNS at all? Why would one not? Sure, it all ends up with one provider, Cloudflare in this instance, but if not encrypted then your ISP and others profit from your data. Using DoH or DoT at least allows one to be selective about who gets the data, taking into consideration privacy and data retention policies, etc.
Use Unbound then.
My problem is DoH is the obfuscation. It's malware command and control's dream come true.
I dropped cloudflared as it ran poorly on pi zero (100% CPU). I found dnscrypt-proxy which in my opinion is much better - as well as being able to use DoH and DNSCRYPT with different providers, it has more features like preventing AAAA queries going out/caching, min cache times etc.
I personally use DNSCRYPT over UDP with adguard servers which block the queries my pi hole block list misses.
Very true. Once DoH is enabled by default on all browsers however, and I do think this is where we are heading, it does mean that a user will actively have to disable it to use a Pi-Hole.
But, if the DoH or DoT functionality can be performed after the Pi-Hole and is just a checkbox, I do think this works in your favour, despite the additional codebase.
My two cents, and thanks for the replies.
Firefox is already prevented from doing that with Prevent Firefox from automatically switching over to DNS-over-HTTPS by DL6ER · Pull Request #2915 · pi-hole/pi-hole · GitHub
Upstreams and protocol choices should be made by the users. We can provide guides on how to implement your favorite cloudflared/stubby/unbound/dnscrypt/whatever but including all that in the core package would require a full time team, something we can't do.
Discussion about this is healthy, we try to be as transparent as possible with the project!
Nice! Good to see Mozilla taking this approach.
As someone said in the comments, let's see how open to something like this Google are with Chrome.
Edge, if you want something Chromium based, might be more open to it.
Ha, who ever thought we'd be saying that in 2020.
Don't confuse inbound DoH (which would be required if DoH is standard on all browsers), and outbound DoH (which is what Cloudflared does).
Pi-Hole replies to incoming port 53 requests, and not to incoming 443 requests. If you use Cloudflared or DoT as an upstream server to Pi-Hole, this doesn't change.