Best for Privacy: Local Recursive DNS vs Cloudflare's DNS over HTTPS
I'm trying to decide what option I prefer here in terms of privacy. I'm curious of other's opinions on the issue, and if anyone has a better solution to offer more privacy.
Option 1: Hosting a local recursive DNS
I currently have a device running Pi-hole on my local network. I recently set it up as a recursive DNS server using unbound. This allows me to no longer rely on a public DNS such as GoogleDNS, OpenDNS, Cloudflare, etc. for my queries, and just point straight to the root servers.
Pro: I removed a "pair of eyes" (Public DNS) out of the equation
Con: All my queries are not encrypted so my ISP (and potentially others) can still see my DNS queries
Option 2: Using DNS over HTTPS (DoH) using Cloudflare's client
With this option I would use Cloudflare's cloudflared daemon they provide on their website. This would allow all my queries to be encrypted when sending them to Cloudflare.
Pro: Encrypted DNS queries from my local network -> Cloudflare's servers. My ISP can no longer see my DNS queries
Security Pro: Helps prevent MitM attacks
Con: I now have a Public DNS back in the equation, which I have to put some trust into. Also, my queries are most likely only encrypted from my local network -> Cloudflare's network. When Cloudflare has to do the recursion, those queries may be not encrypted (my assumption is they will most likely be not encrypted)
Possible Con: Does Server Name Indication (SNI) "leaking" apply to DNS queries at all? If so, then my query is revealed anyways right?
As a note, I am nowhere near an expert on the specifics of DNS, so some of my assumptions on how things work may be super wrong!
Why not just get a VPN?
I have been toying with the idea of making a Pi-Hole just to block ads on my network, VPN doesn't help with that unfortunately.
While a VPN will allow you more privacy from your ISP, there are loads of downsides. Many of the VPN providers are shady (I would probably trust them less than I trust my ISP). VPNs can also drastically increase latency in a connection as well, and may throttle your throughput.
I am a fan of ProtonVPN, and ProtonMail, they are not shady and I actually trust them more than my ISP.
A router-level OpenVPN client with Pfsense should allow you to also block ads on a DNS level if configured right.
SNI is not part of DNS, but rather part of TLS, so the answer is that it depends on the application you're using and whether or not it sends an SNI.
If you're using your web browser to access a web page over HTTPS, your browser will first ask your system to do a DNS lookup on the domain name of the site you're trying to access. DoH will prevent any data here from being leaked, except that you're connecting to your DoH provider.
The next step, after the browser has the IP address of the site you're trying to visit, is to establish a TLS connection to the site, and the first step of that involves sending the domain name of the site you're trying to access as the server name. This is done in plaintext, so anybody listening in on your connections knows which site you're trying to connect to.
There's no getting around SNI at the moment. The TLS 1.3 spec had some discussion of encrypting the SNI, but that requires a separate TLS connection to be made and therefore pretty much doubles the round trip time of the connection.
Personally, I use DNS over HTTPS by using
cloudflared, as I'm ok with Cloudflare seeing my DNS queries and even DNS over HTTPS seems faster than using my ISP's DNS servers. Being protected against MitM attacks is also a bonus.Encrypting DNS lookups really does nothing to protect against MITM attacks; that's not really how they work. You're maybe thinking of cache poisoning, which hasn't been a meaningful problem is about a decade.
If you're not using a proxy or VPN, your ISP can still see what you're doing, or at least with whom you're doing it. "Privacy" is noble, if incredibly vague, but it's not really helped in this instance by trying to obfuscate your DNS lookups. (I mean, not to be funny, but spoiler alert, even if they don't see the DNS query, your ISP can still tell when you visit, say, Xhamster, or Reddit, or Ashley Madison...)
The main benefit to running your own local recursor isn't a matter of privacy but of reasonable assurance that you're getting unfiltered DNS replies. Google, Cloudflare, OpenDNS, and HE have all altered responses to greater (OpenDNS, Cloudflare) or lesser (HE) extents in the past, to say nothing of all the times they've broken over the years.
I'm going to have to disagree with you there.
A standard DNS lookup sends an unencrypted UDP packet containing the query to wherever the nameserver is configured to be. This packet is forwarded by several routers/switches/middleboxes, any of which can decide, if they're malicious, to reply instead of forwarding the packet on. The response packet is also unauthenticated and unencrypted.
For a simple real life scenario, let's say I setup an unsecured wifi access point in Sue's Coffee Shop and I name it "Sue's Coffee Shop Wifi". Some people might connect to this access point. I'll configure it to act mostly normal, but for DNS queries to example.com I decide to return the IP address of a server I control instead. Patrons of this coffee shop who are connected to my wifi access point and who go to example.com will reach a server I control and will have no idea that anything is wrong.
DNS over HTTPS is not only encrypting the DNS lookups, but also authenticating that the DNS server you're connecting to is the one you expect to be connecting to. https://1.1.1.1 has an SSL certificate that your DoH application will attempt to verify before sending the query. A malicious router doesn't have the private key necessary to sign a response to appear to be that service, so the application will throw an error and not proceed any further.
If you're connected to a hostile network, it's no more difficult for "Sue's Coffee Shop Wifi" to simply silently redirect requests for example.com to the nefarious server based on IP than to fake DNS queries. DNS records are public; that's kind of the point. And nobody MITMs random K-pop fangirl blogs, they MITM Facebook or Paypal or... some similary specific, popular, site. If you have a nefarious router, redirecting requests for the (public, easily discoverable) IP addresses for Facebook or Paypal to your malicious server is just as easy as, if not actually easier than, faking DNS responses, and harder to detect. DoH might offer some measure of protection for smaller sites behind Cloudflare, but larger ones get their own IPs, and I suspect the case is similar at most other CDNs.
So I stand corrected; I mis-spoke, and I apologize. Encrypting DNS lookups does very little to "prevent MITM attacks".
You're right. In the instance that you're connected directly to a malicious node, there's lots of different things it could do to MitM you. You've convinced me that DoH isn't as useful as I thought it was.
There is the possibility that the MitM exists between you and the DNS server and not between you and the host you're trying to access, in which case they could only attack you by switching out IPs rather than rewriting the IP addresses of the packets, but now we're getting into much more complicated attacks.
Get a machine in the cloud. Run a SOCKS5 proxy on it. Have your system connect to that proxy.
Use some trick to verify that your SOCKS software is forwarding the DNS requests, because that is implemented in SOCKS, but not clients are not required to use it. Regular Openssl
sshcan be a no-frills SOCKS proxy (handling both ends of the connection):ssh -D 127.1:4321 user@yer.cloud.machineRuns the proxy on port localhost port 4321.
Cloudflare is never a solution that will increase your security or privacy to a sane level. Cloudbleed already showed the world that they do process all the requests they handle, and that they can't securely deal with the data they acquire.
I also don't see any references to sourcecode for their DoH client, so that can't be trusted in any way either. I also don't see why you would want to run DNS over HTTP(S) to begin with. There's a certain thing with the new generation of webdevs to want to push everything over HTTP(S), even when there's no sane reason for it.
On the other hand, there's DNSCrypt with a pi-hole specific guide. That project is free software, doesn't require you to abuse HTTP(S), and doesn't depend on a known bad actor like Cloudflare.
Even there, you have to configure dnscrypt-proxy to not use DoH, which it does by default (and defaults to cloudflare on my end at least).
It can optionally make use of DoH as of version 2, which is enabled by default. It can be disabled with a single configuration key. I believe Cloudflare is the only DoH provider right now, so it can only use DoH with Cloudflare.
dnscrypt-proxyitself isn't technically limited to just Cloudflare, unlikecloudflared, though.