To the extent feasible, I'd like to be able to use a Pi-hole to block DNS over HTTPS (DoH), using approaches similar to those outlined here:
Why are you submitting this a a feature request? The GitHub site appears to have the information you need to set this up locally on your network.
2 Likes
To elaborate, the feature request would be for anti-DoH to be a high-level, UI-driven option within the Pi-hole itself - an easy, one-click enabling (that would be fully integrated into the Pi-hole, persist across upgrades, etc.).
I predict that adware and malware are likely to start using DoH to evade DNS blacklisting. I see countermeasures for that as part of the Pi-hole's core value proposition.
[Edit: an example of malware using DoH]
2 Likes
Please also note that I understand that some types of use of DoH would not be "intercept-able" by the Pi-hole itself (as you noted here). But for the types that the Pi-hole can see, I think it's worthwhile to make it easy to do so.
This feature is out of scope for Pi-hole.
1 Like
I respect the decision. Could you elaborate a little bit about why, to better inform future feature requests?
Pi-hole is focused on being a DNS server which can block DNS queries based on predefined filters. It is not meant to be a security product, although it may be used to block malicious domains with certain blocklists.
Pi-hole is also a project run by volunteers, and we do not have the manpower to extend Pi-hole's scope further than it is currently.
1 Like
Read my feature request here, my argument here (referring this feature request - fully supporting options to add security features), to reconsider the IP blocking feature, and vote for it, to increase chanches to get more options to protect your network.
2 Likes
+1. See also this active work to disable Firefox's DoH.
As I understand it, DoH in itself cannot be blocked by Pi-hole.
Pi-hole is build to handle DNS requests only, and as such, it never sees anything else than DNS requests.
This is achieved by configuring your router (or your Pi-hole, if you chose to setup your Pi-hole as your local network's DHCP server) to tell all machines in your network to use Pi-Hole as DNS-Server. This instructs all your machines to direct their DNS-Requests (UDP/TCP port 53) towards your Pi-hole.
All other requests are not handled by Pi-hole, but rather by the client and your network's router/gateway (before the requests leaves your local network).
As DoH is using HTTPS (TCP port 443), Pi-hole will never see those requests in the first place.
So the most efficient way to block DoH would seem to be blocking DoH at your local router/gateway level (which likely would involve additional hardware like a custom router that can be tailored in such a way).
But alas, there would be no way to reliably distinguish DoH-DNS queries from normal HTTPS requests without inspecting packets, and inspecting packets would mean to somehow compromise and break HTTPS encryption first. In addition, doing that in real time would quite possibly involve a more beefy piece of hardware than the Pi Zero that is currently handling my DNS, even a Pi 4 might fall short here.
Possibly the only leverage Pi-Hole could use is to block access to domains whose sole purpose is likely to provide DoH services. i.e. by blocking the traditional (port 53) DNS lookup of a known DoH server.
But note that by employing HTTPS as transport protocol, ANY webserver could receive and directly digest or forward DNS requests. E.g. technically there is nothing that would stop Google from accepting and processing a request like 'https://www.google.com/dns-query'. Trying to block DoH by blocking the associated domain thus may result in loss of access to the very content you are trying to get to.
I see further shadows lurking when employing DoH with regards to phishing attacks (they can hide all the more comfortably in an HTTPS data stream) and the reliable authentication of trustable DNS servers - if DNSSEC isn't applied in conjunction with DoH, it'll be all the easier to spoof and redirect valid domains to malware sites, being indistinguishable within the browser, all possible by shifting DNS from a network to a client-side feature. I fear chosing DoH over DoT (which was also discussed and tested by browser makers last year) has to do more with Pi-hole, Blokada and similar DNS-blockers gaining momentum outside the internet's geeky corner than the (also somehow valid) increase in privacy. Security-wise, DoH might turn out to be a painful experience for most network admins.
But I've drifted a bit off-topic, sorry 
For now, Pi-hole users could try adding DoH servers to their block lists should they wish to thwart DoH.
Fortunately, this should work out of the box, without any need to alter Pi-holes current implementation - granted the known DoH domain names find their way in some well-maintained blocking lists.
But protection or blocking success will never be as complete as without DoH, as DoH is shifting the very mechanics of DNS resolution away from the network to the client. If this shift is to become widely accepted in the future, network wide DNS blocking will become very hard to achieve for anyone, not only Pi-hole.
2 Likes
Why should they query for the IP addresses of DoH servers? This would be the most obvious vulnerability I could imagine in such a system. Hard-wiring the IP addresses of DNS servers is something that has always been done.
You are right- assuming a sufficient amount of malevolence, any application or browser script could employ a hard-coded IP for DNS queries or even access content from a hard-coded IP directly, and neither Pi-hole nor any other DNS-based filtering software would notice it (and I wouldn't expect them do so, as they do not claim or fulfill the role of IP traffic firewalls).
However, in such a scenario, at least stray DNS queries could have been intercepted by local measures, e.g. the only device in my network allowed to make outside connections to port 53 is my Pi-hole. My client-side firewall is configured to block applications from accessing the network, and browser scripts are also disabled by default in every browser I use.
But I was rather thinking of recent reports of the two main browser manufacturers in the DoH area: Firefox has supposedly pushed DoH to some 70k users in the US, and Google just announced it will enable DoH resolution within Chromium. Currently, Google claims to be probing the locally provided DNS server for DoH support, only switching to DoH if that server supports it.
But throw in the Chromium "Use a Google DNS service to Help Resolve Navigation Errors" flag, and you'll have a perfect way to sneak by Pi-holes domain blocking and escape any firewall or DNS port blockings, and voila your ad revenue stream keeps flowing into the user's browser: Pi-hole does not see the request, a browser is allowed to access the internet through the firewall, and DoH does not require scripting.
As long as classical DNS resolution is still the basic default, blocking access to Cleanbrowsing, Cloudflare, DNS.SB, OpenDNS, Quad9 and Google DoH servers could force the browsers to fall back to classical DNS.
Sadly, this does not invalidate your objection in the least: The browser could still be made to contact a hard-coded IP address for initial DNS resolution over DoH, potentially paving the way for all successive DoH DNS requests over port 443, out of reach of Pi-hole - if the browser companies should resort to such measures, which they most certainly would never do, would they?
As long as we'd know that the server in question has a fixed IP (and is not offering any wanted content) such as 8.8.8.8, blocking would be possible on a firewall level. I don't think Google really cares about us as long as it works for the majority of users which I may call "plug-and-play" users.
I don't see all that much of an issue right now. We have:
- Firefox: Mozilla told us how to disable DoH and we're looking at providing this as an out-of-the-box solution. The reason for doing this is because we provide "special local service". This is exactly true.
- Chrome: They apparently want to
It is entirely unclear upt o now how they want to do this right? Will there be a specific domain like
do-I-Like-DoH.comand if this isNXDOMAINthan assume it cannot do it? When it instead results in an IP, does the browser use this one? This approach would at least be similar to what Mozilla does and could be controlled by us in a similar way.
I personally do not see any privacy benefit of DoH over DoT. The only thing that I see is that the application is now able to perform DNS queries without the oversight of the operator.
In Android the ability to modify HTTPS traffic on the fly was neutered some time ago with the introduction of only trusting system certificates by default for published applications. this was touted at the time as a security measure to stop eavesdroppers or those looking to modify legitimate application traffic. the result it had though is that the user themselves is no longer able to read the HTTPS traffic leaving their device without having to either patch each application or root their device. At the time not many people considered this to be an issue because really who wants to inspect all the HTTPS traffic on their device - a pen tester would be able to get around this and the layman would never need to do it anyway.
Since the advent of Pi Hole and DNS privacy as a concept the first thing people look to do is to block access to those revenue generating domains for Google (in the case of Android) and others.
The solution on their part is simple - 1. move the DNS queries in to a layer where they can no longer be eavesdropped (the laymans HTTPS) and 2. move the resolution away from a process that the owner has control of (OS DNS resolution, or delegated to the local DNS server).
You could set up some redirect for DoH servers to one on your local domain, implement a self-signed root certificate, add it to your devices and the DoH server and let it run its course but this wouldn't stop the problematic element whereby a rogue process queries an unknown HTTPS site to resolve DNS and also wouldn't stop mobile OS's which employ certificate pinning and non-trust of user certificates.
You could perform deep packet inspection at the router to drop traffic which contains DoH requests but this requires hardware and still the root certificate on all your devices.
Finally the solution is to run a blocklist for known DoH servers so they do not resolve in the first place and to hope that any rogue DoH servers end up on one of the malware blocks you have going.
For now though I am dropping packets for ports 53 and 853 at my router unless they originated from my Pi Hole.
tl;dr: I do not like DoH. It is being being employed to move control of network traffic back to device/application manufacturers and away from owners.
1 Like
Whether anyone likes DoH or not, it is here and its usage will only grow. Android 9 and 10 already have the client built in and win10 has it coming very soon. iOS is going to support DoH this fall.
If Pi-Hole is not going to support DoH any time soon it will simply become irrelevant to users.
In the meantime, the only option I have to keep using Pi-Hole relevant is blocking DoH on my FW. But this is not a sustainable strategy in the long run.
Please, face the reality and do not let this project to die in 6-12 months.
Don't worry, it won't.
Edit: No, that isn't saying that we will support DoH.
Due to the complexity of DoH and the fact that upstream dnsmasq is not going to support it, they will not implement it out-of-the-box. However, it is only a few clicks away.
Five years ago, this was the discussion about implementing DoT: DNS-over-TLS
There probably is no right or wrong about DoT or DoH. Certain people believe in certain technologies.
@DL6ER had a description somewhere how to add DoH to Pi-hole with a few easy commands. The guide on the docs currently talks about Pi-hole --> Cloudflare, what is requested here is to support Client --> Pi-hole.
1 Like
Now the interesting question: Do they actively probe the network for DoH servers? Or how do we tell them to "taste" my Pi-hole?
I interpret your answer as: Pi-hole should support DoH down to the client, not block it (as was the original request). Is this correct?
and will likely be what users actually want. They may want to have it configurable in a lot of ways and if this can be done with another, already existing project, this is the best solution. No work to make yet another implementation of this complex feature for the Pi-hole core team.
Else, if someone volunteers to add this to dnsmasq, they will very likely inherit it.
To be honest, I'd prefer it if this functionality was offered by Pi-Hole iso another tool to be configured - but that's just my opinion...
Taking it currently isn't, is there then a way to realise this functionality already e.g., using a proxy? And if so, could you perhaps point to some useful reference material?