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?
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
dnsmasqsince 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
dnsmasqbut none who are (very) familiar with the source code of
dnsmasqgives 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.
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.
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.
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?
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?
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.
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.
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.
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 188.8.131.52) can still see everything. This fact might otherwise be hidden if there is just a button saying “encrypt my upstream DNS requests”!
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.
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…
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…
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.
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.
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).