DNS Encryption and the future of PiHole

General
1

Concurrent reddit thread.

DNS requests are the mode by which PiHole does its blocking, but they are also the weakest link in the chain of internet privacy. As such many people are working to patch up this link, this jeopardises both the fundamentals of how PiHole works and the comparative privacy of its users.

DNS Encryption is here, it has hit the mainstream. Pixel phones now use it by default, as does the Firefox browser. The uptake of DNS encryption is expanding rapidly, it is already on its way to Chrome.

I think this poses two issues for PiHole.

The first issue is almost existential to PiHole - that individual clients using encrypted DNS bypass PiHole, we have already seen this with the aforementioned Firefox and And-roid. This, along with the hardcoding of DNS in Chromecast devices we can surmise that it will not be long before Google and other device manufacturers hardcode Encrypted DNS Clients into their devices. As this practice becomes more and more widespread PiHole's ability to block ads, malware and privacy issues in the household will become more and more patchy. There are methods to limit this behaviour, but they will require work and there is limited appetite to implement them.

But let's say that we find a way to prevent the above and make sure that all DNS traffic goes through our wonderful devices. That leads me onto the second issue. Which is that as the rest of the world gets DNS privacy we PiHolers may be left behind. It is difficult to configure DNS encryption on the PiHole, but there are some guides. This means for the vast majority of PiHole users their DNS requests are going out to the internet in plain text. What is more, if PiHole did want to implement an encrypted protocol, there are three (or more) to choose from: DNS-over-HTTPS, DNS-over-TLS and DNScrypt, each favoured and supported by a different one of the big 3 open DNS resolvers (see links for each one). This means that if PiHole were to choose one to support, it could be accused of favouritism. And that would be if this were even possible in PiHole. Since FTLDNS is built off of dnsmasq it is hard to implement one of these new encryption standards.

I do not have the answer to these problems sadly. However, as a keen PiHole user for mostly its privacy benefits, I feel this is bitter-sweet. It is important to me that my DNS requests aren't being logged, whilst I also love the ad-blocking features of PiHole. I just hope I can continue to have my cake and eat it.

Edit: Grammar
Edit 2: Moar links!!!
Edit 3: Slightly more dramatic language

1 Like
2

Still NOT sure this is the way to proceed. for example the google entries 8.8.8.8 and othersin the list. If that DNS server would only provide dns results and does NOT hold any unique zone information, this could work, however if a DNS server responds to both port 53 and DOH AND holds the information for a specific zone (example: has the records for google.com) you would definitely get in to trouble when blocking this on the firewall.

Still NOT sure using the cloudflare dns servers is beneficial for privacy, they can see everything you do, as opposed to the unbound solution, which connect to several server all over the world, leaving them with only a partial history.

The final solution, in my view will have to come from software like SURICATA, able to detect DOH. There is already a solution, but it needs to get into the upstream binary

3

The solution to that is providing an exception for your pi-hole and/or other DNS servers on your network, but otherwise denying. No other device needs to be doing DNS lookups, so they won't be impacted (only those attempting to circumvent will have problems).

4

Well... you can't have your cake and it eat, too.
I fear this holds true also in this regard.

The solution for encryption has to weigh your interest to securely look up proven authentic host name records against your interest to control and manage communication on your own network, and against your interest to retain privacy, preferably on private as well as public networks - and those three do not always agree very well.

You may be aware that this has been discussed here previously, e.g. in https://discourse.pi-hole.net/t/eff-view-on-doh-and-potential-privacy-problem-with-it/23524 or Blocking DNS-over-HTTPS (DoH).
The posts on those topics - as well as links provided among them - may help broaden one's views on the matter.

One cannot discuss encrpytion without paying attention to authenticity also.

Putting away my reservations about DoH and its tendency to further concentrating surveillance options to fewer locations (consider the Mozilla-Cloudflare deal), it is important to recognize that neither DoT nor DoH are able to supply sufficient authenticity within the scope of DNS.

This is so because the underlying transport layer security (as employed both by DoT as well as DoH) is concerned solely with the authenticity of the transport communication target, i.e. in DNS resolver itself (in DNS terms).
However, this does not imply any guarantees on the authenticity of the DNS records that are distributed by that resolver.

Only DNSSEC provides means to ensure the latter.

If we'd value proven authentic DNS records over privacy and manageability of DNS traffic, DNSSEC would be the tech to push.

Expanding on this, I 'd favour DoT over DoH personally, as it strikes the best compromise between privacy and local DNS traffic manageability (or observability, if you'd prefer).

However, in a total surveillance society, I would wish for DoH to be operational for me, as that would offer the best probability to escape surveillance where I don't want it (which does not mean to escape it by and large).

Shifting DNS control away from the network over to application level seems not desirable for me at all, yet it will come. In fact, it is already manifesting itself, pushed by the remaining two browser engine makers.

Quite probably, in a more ideal world, the answer to this should not be decided by some browser manufacturer or some mega company with their respective own agendas, but rather by an enlightened and educated public.
Yet I fear the public, as it is currently, is not very interested at all, and even if so, would find it difficult to fathom impact and consequences of this subject.

To be honest, I constantly struggle myself :thinking:

For once, the goals of the average home user (trying to employ adult content filtering) seem to align with those of companies of all scales, as usage of DoH causes quite some headaches among company network admins (trying to keep their networks secure).
Mozillas DoH probing meachanism may prove compatible with controlling your DNS traffic within your premises.

Apart from any ethical, political or profit-maximizing influences, Netmeister has assembled an excellent technical background overview of the current efforts to accomplish more secure DNS operations - if interested read more at DNS Security: Threat Modeling DNSSEC, DoT, and DoH.

8 Likes