Implement DNS-over-TLS capability in Pi-hole

Feature Requests Closed or Out Of Scope
22

We have not even finished the step of integrating dnsmasq into the core of the project. However, it is now mostly done and we are slowly approaching the final release of Pi-hole v4.0. So, I'd say "Yes for the short- and mid-term evolution". I cannot speak for what might be driving Pi-hole in five or ten years time. It may be that we decide to switch to another resolver. However, dnsmasq is very convenient at the moment mostly due to three reasons (there might be more I'm just not thinking about right now):

  • We used to use dnsmasq since a long time. All users that liked to customize their setups are well familiar with the config syntax and how to do things.
  • We have several developers who are familiar with the source code of dnsmasq but none who are (very) familiar with the source code of bind, unbound, etc.
  • dnsmasq gives us just what we want (integrated DHCP server, etc.) If we would switch to, let's say unbound, then we would not only have to recode everything of FTL, but we would also have to look at sticking together different projects into one for being able to offer both DHCP and DNS services.

In this light, I'd say it is safe to say that dnsmasq is the optimal choice for now and at least a few years (when we might re-evaluate things). It "just works" and as a very flexible DNS forwarder it can easily be set up in combination with, e.g., a resolving server like unbound (I have such a setup at home and described it in a very easy wiki article) and benefit from all advantages such a resolver has.

3 Likes
23

I will take a look at your wiki article about unbound. I hope that the Pi-hole project will reconsider the application model at some time in the future to be more flexible w.r.t. integrating new functionality such as DNS over TLS in a way that is easy and friendly for the end user. I like recommending it to people, but also am a strong believer in DNS over TLS and I think it's easy to understand why someone interested in Pi-hole might also be interested in leveraging that technology.

Can't say I understand the decision on the part of the dnsmasq devs to just not integrate DNS over TLS, but hey... there are always alternatives.

24

I think this is more a problem of dnsmasq's current design and way of realizing concurrency. TCP is inherently blocking (at least if you want to use the same connection for request and reply) whereas UDP isn't. In dnsmasq, incoming TCP queries are handled by individually forked workers who themselves forward the queries using TCP to the upstream server and vice versa. However, incoming UDP queries are also forwarded using UDP and are then not looked at again until the response arrives from the upstream server. The major difference is that dnsmasq would have to keep a connection to the upstream DNS server open all of the time and send all queries though this (secured) channel.

Hence, I don't interpret the reply of the developer as being ignorant or not wanting to implement DNSoverTLS at all, but rather that they don't see it worth (or don't have the financing to be able) to do this major redesigning of the DNS handling routines to be suitable for such an implementation.

3 Likes
25

Quick question - I followed your wiki for setting up unbound on my Pi-hole server, but when I try to enable DNS over TLS using it, I only get A records back, no AAAA. Any insight on how I would tweak your config to use DNS over TLS and still get AAAAs?

26

This is very odd, did unbound work without DNSoverTLS? Can you try this? Also, is there anything in unbound's logs showing a difference between A and AAAA requests?

27

It works great when I stop at the point your wiki does - returns all the records as expected. As soon as I set upstream-ssl: yes and set forward DNS servers using port 853 it only returns a single A record. At first glance I didn't see anything unusual in the logs but I will need to dig a little deeper.

28

With the complexities of adding this directly into dnsmasq, its clear that a proxy-based solution is going to be the optimal solution. Backed up by Simon Kelley himself saying so.

Looking forward, I could see an install-time option to configure and install a TLS proxy for DNS-over-TLS. As far as that goes, it wouldn't even have to be part of pi-hole, but I would much rather it be.

Whatever the solution - it needs to be dead-simple to enable it, much like installing pi-hole. I think there is a clear demand for DNS privacy, but the entry requirements are so high that only a few get there. I think same issues exists with DNSCrypt - but compounded by fewer large and well-known providers supporting it. Just because the implementation of this feature won't be built into dnsmasq, but rather on-top of it, I'm not sure that warrants it to get marked as closed. Implementation details are not part of this feature request.

29

I think I agree about the status of the FR. The problem I have with the implementation is the difficulty in making it easy. You make some very good points and I'll add that including 3rd party packages that aren't part of the main distribution repository is something I'm personally against. I don't think we should be adding in code, either vetted or unvetted, that would require us to actively update and monitor in addition to the code we write. I'll re-categorize this back to Open, as I think it's within the scope of the project, but it has a very high barrier to implementation in the current state of the technology.

30

We see this with dnsmasq where we have no control over which version is available on the variety of operating systems our users install Pi-hole on (whether officially supported or not!). Adding another package on top doesn't seem to be a good idea.

We are currently working on a very new and much improved help/tutorial/guides/... system where we will collect tutorials such as the one I wrote for how to install a recursive DNS server with inbuilt (and working!) DNSSEC protection. I can see a tutorial for installing DNS-over-TLS or dnscrypt as a perfect match for this new category of things.

I think we should reduce hand-holding of our users. Rather than adding more one-click solutions, which may become hard to maintain and how their real difficulties only once released to our user base, we should add more and easier guides that do not only explain how to implement something in a few basic and simple steps, but also makes the user aware of what the implications are (e.g. benefits in terms of privacy, drawbacks in terms of speed, ...) and how it works (at least roughly). This will not only be easier to maintain for us, it will also offer users to learn something and I consider knowledge an essential thing if you want to really take care of your own privacy.

An essential part would for me be to describe exactly that, although the transport stream will be encrypted, the service you're connecting to (maybe 1.1.1.1) can still see everything. This fact might otherwise be hidden if there is just a button saying "encrypt my upstream DNS requests"!

4 Likes
31

I realized DNSoverTLS using stubby as local resolver.
This was man guide: https://blog.sandchaschte.ch/en/pi-hole-with-dns-over-tls

All works fine.

1 Like
32

I've read (at least I assume this is the one) your wiki, regarding ubound.

My assumptions may be wrong, I'm NOT an expert, here are my thoughts:

the Google DNS servers will only be asked if you want to visit a Google website

This still implies google knows everything you are requesting from google.

Your recursive server will send a query to the DNS root servers (.net)
Your recursive server will send a query to one of the TLD DNS servers for .net
Your recursive server will send a query to the authoritative name servers

This implies port 53 (UDP & TCP) must be open, to be able to reach the all these dns servers.
A provider may be tracking all port 53 activity, even if the destination is not their own dns server.

I'm using pfsense, port 53 is opened for the opendns servers only (may not be the best choice - used only to allow a reinstall of pihole). There are multiple known scenarios where port 53 can be abused (malware, viruses, applications), so I'm not convinced opening port 53 is wise.

The authorative server will answer with the IP address of the domain

This server may have logging enabled, your request can lead back to you, your location, based on the ip address may be abused.

I'm using dnscrypt-proxy, port 443 is used to perform dns requests. I assume my dns requests are nearly invisible, masked by all of the port 443 traffic. I'm using only dnscrypt-proxy servers that have no logging, true, it's impossible to verify.

If I'm not wrong in my assumptions, you may want to considere adding these thoughts to your pro/con evaluation.

The problem: Whom can you trust?

In the end, your always right. Using dnscrypt-proxy implies I trust the dnscrypt-proxy server to keep the promise to not log anything.

Just my two cents....

1 Like
33

Erm ... yes ? But when I open, e.g., mail.google.com then they don't need to look at their DNS logs, they can just look at their server logs, so it isn't clear to me under which aspect this is a drawback...

Yes and No. First: They must obviously just be open in an OUT direction (this is what you meant, but not wrote). How you wrote it users might misinterpret this and think you mean port 53 must be opened from the Internet TO your Pi-hole. This is not the case.

Why could port 53 be used any worse than e.g. port 80? I guess you don't limit this one, right?

You can also still setup a refined firewall (like I have) that does not permit outgoing port 53 activity from any device except the Pi-hole. On the Pi-hole, I don't run any additional software (only Linux + Pi-hole) so I feel okay with allowing this device to contact anyone over port 53.

Well, yes, but, e.g. google.com will anyhow know who you are as you will connect to one of their servers just a second later anyway. But if you query pi-hole.net, Google won't know about it in contrast to when you're using their upstream servers for everything.

Yes ... I trust my ISP good enough (but in Germany the privacy laws are also very strict). If you don't trust them, I think you are anyhow in trouble and don't gain any security by using dnscrypt. Surely, the ISP wouldn't be able to intercept and read your DNS queries, however, they could still just monitor your traffic and where it goes (even in HTTPS requests, the domain itself is unencrypted in the header). They can easily do this on the same level they'd also have to go to for DNS interception (router level).
Eventually, this boils down to that you don't really hide anything from your provider when enabling dnscrypt. Yes, they won't see your DNS queries, but they will still be able to see all headers of the HTTP(S) requests you're making. The only way out here is using tunneling or VPN techniques, but I don't actually see dnscrypt adding any great value if you're already suspecting your provider to be doing packet inspections...

1 Like
34

but in Germany the privacy laws are also very strict

That is great for you. Here in the US, ISPs have the right to collect and sell whatever information they like. I most definitely don't trust them to not sell my data when they have a financial incentive to spy on me (and legal right to do so).

they could still just monitor your traffic and where it goes

This is true. And its not any harder for them to capture the IP addresses, but it is significantly harder for them to correlate the IP address with a website, especially if the website is hosted through a CDN or hosting provider that serves many different websites. Beyond being harder to correlate those IP addresses, if they try, then there will be without a doubt percentage of error. If they start adding a bunch of bad guesses to their analytics, then that data looses value.

Anyways, this isn't about trying to hide activity from an oppressive government. Or even from a rouge and distrustful ISP. I obviously trust them enough to use their service, after all they are the only providers in my area. If I want internet, I have to trust them. I just want to make it harder for them to sell data on me - which I have no control over without some added protections like DNS-over-TLS. I think the majority of the people looking for this feature feel the same way.

35

I don't agree. If you visit https://thissite.com and they are backed by a CDN, you don't type in https://cdn.thissite.com. You always enter the FQDN of the site you are visiting. Doesn't matter if the actual site then is hosted at http://thissite.godaddy.com with a CNAME or even a handful of A names, you still have to resolve the FQDN. It could return back that the FQDN is a CNAME for a CDN, or an A name to a different host, but you've only added more good information for the aggregators. So it's not hard to correlate.

As for trying to add noise to the signal, that's been discussed a lot, and it comes down to if you're visiting random sites or generating random noise, most of that is going to be NXDOMAIN anyways and easily thrown out of the data set.

If the argument is that DoT or DNSCrypt is more secure, well, of course it is. But you still end up revealing the sites you visit when you actually visit the site. The ISP needs to know the IP of your requested site so they can route your traffic accordingly.

I'm the most tin foil hat guy on the team and I go to extremes, I don't use any outside resolvers, I run my own clusters of resolvers. But I know that my traffic is going to be seen by every piece of hardware that sees my packet as it's got to read the header to know what to do with it. And that metadata is all going to be recorded and sold somewhere.

2 Likes
36

Yeah, and in addition what I already said:

A server is sitting at a specific IP address. However, it may be handling dozens of HTTPS protected pages. How should it know which server certificate to use? Correct, it knows because the host is transmitted in clear - for this exact reason.

As I already said, it is not more complicated to just read where your HTTP(S) requests go than to read your DNS packets. For an ISP, the latter may even be less valuable because you may have a local cache or (although that's surely an extreme) have configured some host names locally in your /etc/hosts file. In contrast, if they read your HTTP(S) request headers, they will be able to record every connection attempt, not only the one time DNS lookups (which also don't necessarily mean you visited the page as many browsers do DNS pre-fetching).

1 Like
37

I'll add on to this thread late - if it needs to be elsewhere please redirect.

This is a question of "who do you trust least and why." I have configured various PiHoles with unbound as recursive local recursive resolver, and with cloudflared running DNS over HTTPS. One protects the integrity of my DNS lookups but the ISP can see them, the other hides only my DNS activity from my ISP but now I have to trust Cloudflare to get me the correct DNS and keep my searches private.

If i run my VPN I'm secure end to end for the most part, but how much do I trust my VPN provider? I use VPN only when I need to hide my actual IP and location (overseas TV and the like).

My simple questions:

(1) any significant performance differences between DNS over TLS and DNS over HTTPS?

(2) I know my ISP would have a commercial reason to monitor my online activity and perhaps shape my network traffic speeds. Is there any indication that Cloudflare is not on the up-and-up and that they would also have a commercial reason to sell my data?

Any opinions on what gives me the best overall privacy and security - running my own local recursive resolver (I see one of the developers does this with a cluster) and accepting that the ISP is either going to see the DNS requests and the https request; or going for greater DNS privacy only by going encrypted to a DNS third party provider (removing half the information that the ISP sees)?

2 Likes
38

So because this issue is marked closed, shall we presume DNS-over-TLS is not on the pihole roadmap?

39

It was more "out of scope." But, I think that is a fair assumption, for all the reasons discussed in the replies above.

40

I'm running my PiHole with DoH on https://1.1.1.1
If anyone else is interested, I used this to set it up. Been running for a couple of weeks without any problems.
Securing DNS across all of my devices with Pi-Hole + DNS-over-HTTPS + 1.1.1.1

It's a little workaround till DOT (or similar) is implemented

1 Like
42

For me it's laziness. I already asked Scott why DOH and not DOT, but didn't get a reply sadly.