Implement DNS-over-TLS capability in Pi-hole

Feature Requests Closed or Out Of Scope
1

Requested behaviour

Although there is an experimental implementation of DNS-over-TLS through the use of Stubby, official support coming to Pi-hole would greatly enhance the privacy aspects of the Pi-hole. DNS-over-TLS is in essence an encrypted tunnel through which the DNS-requests are send. Man-in-the-Middle (MitM) attacks on this traffic would result in captured encrypted data.

DNS-over-TLS (port 853) is not to be confused with DNS-over-HTTPS (port 443) and DNSCrypt (port 53). DNS-over-HTTPS is something that is supported by Google DNS, but just as DNSCrypt (supported by OpenDNS), it ain't a formal standard (RFC). DNS-over-TLS is an official standard and it is supported by Quad9 (9.9.9.9) and Cloudflare DNS (1.1.1.1).

Out-of-the-box support for DNS-over-TLS is therefore my feature request :).

Actual behaviour:

All DNS lookups to DNS-servers higher up in the chain are all not encrypted. Hence this invades privacy, because anyone can sniff out to which site you are going. Not the url, but in many cases the domain-name itself surrenders enough data to build a profile.

More info

I have read the following guides, but as there is no formal support yet I do not want to adjust my daily-Pi-hole-driver yet.

But see also these pages from DNS-resolvers.

DNS-over-TLS RFC7858

2

Did you read this?

3

I prefer DNS-over-HTTPS, or even better DNSCrypt.

2 Likes
4

How is DNSCrypt "even better?" DNS-over-TLS is an actual standard and should be pursued over non-standard solutions such as DoH or DNSCrypt.

2 Likes
6

DoH and DNSCrypt are no RFC-standards indeed. And DNSCrypt is about encrypted DNS requests over plaintext channels. So from a continuity and compatibility point-of-view, DoT should be the way to go.

But, that is my point-of-view :slight_smile:

2 Likes
7

Ah, good to hear! And what about updates in regard to Stubby? Do you have automated that or does it require manual work?

8

Here is a good comparison: https://dnscrypt.info/faq

1 Like
9

knot resolver is imho best piece of dns resolver when it comes to dns over tls

10

Got any comparisons that aren't inherently biased?

Of course DNSCrypt's official website is going to say DNSCrypt is the best.

1 Like
11

Lies, dns over tls is completed in Knot resolver. as well as related standards. F**** biased comparison

DNS-over-TLS (Transport Layer Security) RFC 7858,
Query Minimization RFC 7816,
Aggressive Use of DNSSEC-Validated Cache RFC 8198.
12

Feel free to use whatever you want. You already can use all three, even without official support in Pi-hole. My choice is and will be DNSCrypt.

1 Like
13

This feature request is specifically for 'Implement DNS-over-TLS' - which is not DNSCrypt. If you want DNSCrypt, please vote for one of the other feature requests for DNSCrypt. My vote is specifically for DNS-over-TLS, which is supported by Google, Quad9, and CloudFlare - who do not support DNSCrypt.

Anyways, there was a request in the Dnsmasq mailing list from Oct. 2017 for them to support DNS over TLS - but there were no responses: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q4/011804.html

The previous Dnsmasq request for DNS over TLS (Sept 2015) mentioned issues with requests over TCP - which is now supported by Dnsmasq. It would be nice if Dnsmasq could just add support for this, and Pi-Hole's fork could pull it in.

14

You could trigger a discussion there. We will surely take it over into FTLDNS once it went into a release of dnsmasq!

2 Likes
15

@DL6ER I sent a message¹ asking for an updated opinion on native DNS-over-TLS support. Looks like this feature will not be added to Dnsmasq anytime soon - if ever. Kinda a bummer since I believe there is a good amount of demand for better DNS privacy and having this feature built-in would go a long way in reaching that goal. Oh well, it is nice that the big providers are supporting DNS-over-TLS, but it will be awhile before the general public can benefit from that increase in privacy

[1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012131.html

16

Yeah, I was afraid that this might be the answer. I can confirm, being familiar with most it its source code, that it is not possible to use TCP for the upstream connection if the request comes in over UDP. This is by design and it would be really difficult to change it.

As always, the question is whom can you trust? Can you trust the big providers? Why can you trust, e.g., Google more than your ISP? Are you sure about it? But this is a discussion for a different thread!

I will mark this feature request as out-of-scope as this is what Simon Kelly said.

3 Likes
17

Thanks all for the responses! I tend to disagree though with out-of-scope, especially due to the fact that Pi-hole is moving away from dnsmasq towards FTLDNS. Why fork if you do not want to add new features/improvements yourself?

Considering the proposition of Pi-hole itself (protecting ones privacy) I feel somehow a small bit mislead if that same Pi-hole now wants to disregard a 10-voted feature with the argument: "whom can you trust?". Considering the fork to FTLDNS I cannot even understand out-of-scope.

Just as with Security, Privacy comes in depth also. So shielding the DNS-requests for mass-surveillance is still a very good practice. And that has nothing to do with someone trusting someone. I am worried about parties that I cannot control nor choose that are intercepting my DNS-traffic.

18

How is this out of scope? You have your own fork, FTLDNS, so how is dnsmasq's reply having anything to do with this request being "out of scope?"

Pi-hole is a DNS forwarder... implementing additional DNS security is not "out of scope" for such a project.

19

You have gotten it all wrong. We are not moving away from dnsmasq, we are just incorporating it into FTL to have a reliable monolith DNS solution that can provide all the known statistics. As a purely volunteer driven project, it was already a major undertaking to get FTLDNS set up and running, because it was much more than just copy-pasting dnsmasq into place...

We have been very explicit about how we will react to feature requests that target the resolver part:

Think of FTLDNS as dnsmasq with Pi-hole’s special sauce. This allows us to easily merge any upstream changes that get added, while still allowing us to continue to develop Pi-hole as we have been.

If we would start to heavily modify the resolver code (and we would have to rewrite a majority of the code that handled forwarding to upstream providers!), then this would probably make us deviate too much from dnsmasq's code base and we couldn't apply version update patches easily.

I think I already covered this.

If you have read my post well, then you see that this a wrong oversimplification. I did not say that we will not implement this because of the fact that you cannot trust Google or some other guys. If you are really concerned about privacy, you should not trust anyone of them but set up your own resolving DNS server (I recently wrote a wiki article about this) and equip this one maybe even with dnscrypt or something similar. By this, you have to trust nobody and can still resolve DNS.

Well, I see what you're after, but I do not agree in regards to that I don't see why it would be better to have Google record my entire DNS traffic but not the NSA? Is Google really better just because you know that they are doing it and since you explicitly selected them as your big-brother provider?

@stryker4526 Your comments are covered here as well.

2 Likes
20

@DL6ER Thanks for your extensive answer and the further explanations. Much appreciated! I understand it way better now (with the UDP upstream and all) :slight_smile: . Although I want DoTLS real bad, there are applications that can implement that, so I have read in this thread.

Anyway, just to be clear, I really like Pi-hole and I am a happy user! Thanks for taking your time in regard to my feature request.

Ps, I am not using Google as my upstream, but Quad9 :wink:

21

Thanks for the response. Is it safe to say that FTLDNS will remain the only choice of resolver/forwarder for Pi-hole going forward? Is there any consideration toward integrating other DNS resolvers or forwarders in the GUI or script configuration?