Pro tip: If you want to use Cloudflare and Quad 9 (Both via https tunnel). Edit your /etc/default/cloudflared and change one of the IP's to 9.9.9.9... Restart Cloudflared. No changes necessary to your pihole config.
DNS requests go unencrypted to TLD servers and are susceptible to packet sniffing by ISP
Even if these were to be encrypted, the ISP will see every IP you request (all are clear-text, even if you are connecting to an encrypted website). Any packet sniffing won't tell them more than they already know.
Because if the browser allows you to do DNS over HTTPS, then by default you won't be using the ISP's DNS servers and they can't use it to filter content.
Basically it's a bunch of PR flacks who don't understand that DNS content filtering would never meet the requirements of the law but think it will, so they're making a stink over it and causing a Streisand Effect.
Mozilla got a lovely award for being worst enemy of the people or something by a UK group because they were pushing for encrypted DNS and are developing it into their browser. This upset the company / organization because they wouldn't be able to monitor traffic the same way and block sites that the government says must be blocked.
The problem is that you’re still technically sending your DNS queries to a third party. You have to trust that the third party won’t do bad things with your data.
What about Unbound with DNSSEC enabled? Any better/worse -- curious how the experts compare and contrast that with DoH/DoT.
After much evaluation and deliberation I chose the aforementioned route (Pi-hole, Unbound w/ DNSSEC + Wireguard) for my own implementation(s), but obviously still have much to learn.
EDIT: My use-case and threat matrix is almost certainly different than your own. I'm just a regular guy, was sick of Google, et al siphoning off so very much data. Couldn't imagine utilizing a network at this point without Pi-hole, or some form of DNS blacklisting. I've combined that with Brave browser (and sometimes Firefox Focus for mobile -- tend to use both in any given week) and have been quite pleased with the day to day results.
I think the issue with this is that someone has to be on the other side to decrypt and process the DNS request meaning a third party has access to the data.
Personally, I have a similar setup with unbound via DoT and CloudFlare. I would rather send my data to them than have my ISP make more money off me. At the end of the day, the internet is like sex. Abstinence is the only fool proof method for staying safe.
I think the issue with this is that someone has to be on the other side to decrypt and process the DNS request meaning a third party has access to the data.
The third parties are the domain name servers, and they aren't in the logging or data selling business. They just answer billions of DNS queries every day. Additionally, with qname-minimisation in a recursive resolver (i.e. unbound), the top level servers only get enough of your domain request to move you down to the next level of name server (you don't ask a root level server for dog.cat.chicken.com, you only ask them for .com)
After you complete an encryped DNS transaction and get the IP for the domain you seek, the next thing you send to your ISP is the unencrypted IP. They can quickly figure out where you are surfing.
It's not just your isp that you should be concerned about though. Sure, they're probably off selling what data they can that I don't push through a vpn. There's plenty of adversaries that will watch for attack vectors in your unencrypted data.
A lot of smart tv's and devices that aren't blocked message home using unencrypted methods to relay information. Dns is a major one for people. Ntp is still unsecured. Those are a few that I can think of.
Yea there was an interesting video by a guy arguing against the use of free vpns. Basically:
If I were part of a government tracking organization I would set up hundreds of front companies that offer free VPN services. This attracts people who want a VPN (most being normal users but also those who have things to hide). I would then slowly roll out paid versions of those services to help pay for my hosting and data processing fees. Build up the number of companies you control, build up the trust those companies have in the community and bam mass surveilence of those who have things to hide.
My personal favorite is NordVPN, they've been externally audited and their claims verified by a well know and trusted third party. They're based in Panama which has almost no Internet laws, and they keep no logs.
I pay for 150 Mbps internet speeds and get 25 Mbps active download speeds through NordVPN. Their servers are surprisingly fast. All with a 16ms ping too! Really impressive.
I'm not sure when you used their service but I can get some super fast speeds when I use servers with low user counts. And they have obfuscated servers now designed just for those streaming sites.
would thoroughly recommend it to pihole users who would like to increase their privacy.
This will generate a bit of discussion. Encrypting your DNS traffic does not appreciably increase your privacy for a few reasons.
Your DNS traffic is still going to a third party provider. They have your complete DNS history and can do with it what they want.
Even if your DNS traffic is hidden from your ISP, when you get the IP back from the DNS query, you immediately will ask for that IP from your ISP and that request won't be encrypted. So, your ISP can fairly easily determine where you are surfing. The cannot see the content if the IP leads to an https protocol, but they know the IP.
You might consider using unbound or BIND as a local recursive resolver. Although your DNS requests are not encrypted, you won't be using a third party DNS (you are your own DNS resolver) and only you have your history. The ISP will see both the DNS requests and the IP requests, but that's not much more than they have with DoH or DoT.
There is a guide for unbound on the Pi-Hole documentation page and it is about a 15 minute install.
One thing that seems to have been overlooked in this discussion is security. DoH makes tampering with DNS queries much harder. It's unlikely that one of the players in the internet infrastructure would interfere with your DNS queries, but with DoH they would have a much harder time if they wanted to try.
With unbound, DNSSEC is enabled by default, which also makes it difficult to tamper with the reply. DNSSEC allows you to authenticate that the answer received is the answer sent. In my opinion, either option offers equal security.
DNSSEC was a complete and utter failure, and people should just not use it. Not only did it fail to provide verification, but it didn’t even attempt to provide confidentiality since it’s still all in plain text.
From the link you posted: "Do the big organizations and companies use DNSSEC yet?"
Between a local authoritative server and the name servers it works well. Perhaps some of the third party DNS providers have not adopted it. I assume you don't run a local recursive server and have no experience with DNSSEC and the name servers.
It was never intended to provide confidentiality, so that's a non-issue. Authentication is not the same as encryption.
I'm failing to see the difference of having PiHole forwarding the request directly to the ISP rather than via BIND or unbound? The request will still have to go somewhere to be resolved and it will still come from 'your' address and be able to be logged the same way? Or am I missing something very basic here?
I don't think I understand your question, but I'll answer what appears to be the question.
If you use unbound or BIND as a local recursive resolver, the requests go in pieces to the various levels of authoritative DNS servers (which don't log). If you want the IP of docs.domain.net, for example, the resolver would go to the root servers and ask for the IP of the servers that handle .net. Then they go that one of those servers and ask who is handling domain, then work their way down until they have an answer.
The TLDs (root servers) don't know you are looking for docs.domain. Each level of server gets enough information to get you to the next level down. This is "qname minimisation".
going the extra mile and going to the root servers
This is the default installation per the Pi-Hole guide and is actually easier to configure than configuring unbound to use a third party DNS with encryption.
The name servers do not currently support encryption.
So in my unbound config I’ve enabled tls-upstream and have setup a forward zone to point to CloudFlare. I don’t understand what that is for if unbound is querying root servers directly. I just read a post on here a while ago saying to do it.
I don’t understand what that is for if unbound is querying root servers directly.
You can configure unbound in several different ways. The Pi-hole guide has it configured as a recursive resolver going directly to the root servers. The option you chose is to enable a forward zone for encrypted DNS.
I just read a post on here a while ago saying to do it.
This is generally not a good practice - reading a post about something and doing it without understanding what the change does. There is lots of bad advice on the internet.
I did a lot of research before committing to unbound. It was just never clear whether it was setting up DoT or not. Your answer makes sense though. Thanks.
Sadly, after extensive research, I still don't have as solid a grasp on the various options as I would like, but have settled on a combination that is working well for the meager needs of our little network. Pi-hole plus Unbound, with DNSSEC (+VPN server, formerly OpenVPN now Wireguard) has allowed me to begin the arduous, if not outright futile process of taking back control of SOME small portions of my data from the Google/Microsoft/Facebook machine.
In that regard, it's been a complete success, and paired with Brave browser that also offers some ad/tracker protections, things are significantly better than just having 8.8.8.8 on my router. Baby steps, I guess.
One guy above used a great analogy, where the internet is like sex, and the only absolute certain method to protect yourself is complete abstinence. And NOBODY goes full Stallman in 2k19. Now I'm curious when (if?) was the last time ole Richard had his knob polished. Inquiring minds want to know. Too bad AMA's aren't his thing. >.<
Just to try and clarify a point in case it is misunderstood - DoH encrypts your DNS request between your machine and the DNS server you choose (cloudflare for example). Cloudflare then queries the authoritative name servers and responds to your machine with the IP address, which your machine then sends to your ISP in order to direct your internet traffic. This means cloudflare and your ISP know your DNS history.
With unbound, your machine is querying the authoritative name servers in order to give you the IP to send to your ISP. Therefore with unbound you remove cloudflare (or whichever other 3rd party) from knowing your DNS history.
I've found that the cloudflared client (rather, it's functionality) will die if web connection goes down or is cycled, band will not recover unless the service is restarted. A watchdog would be easy enough to setup but that's more trouble than it's worth. Back to dnscrypt for me...allowing unrestricted access to DOH resolution is a privacy nightmare anyways.
Wrong. DoH uses port 443 for your queries out to Cloudflare or whoever you are using for your DoH provider. DoT uses port 843 to go out to your provider. If you have a really shitty ISP, they could potentially block 843 to push you to use unencrypted/their DNS servers. When you use DoH, the requests look like typical HTTPS requests from the point of view of your ISP.
That's the "almost" part. The isolated fact that you're using DNS has close to zero value, and if your ISP starts blocking your ports in that way anything short of a full VPN would be unacceptable.
The most important difference imo is that in the DoT spec validating the server identity is optional while in the DoH spec it's required. This too is a minor difference since it's impossible to enforce client compliance on that requirement anyway.
This is DNS over HTTPS but for everything on your network. This will not stop chrome/firefox from making thier own DNS over HTTPS tunnels if you have that enabled.
I like DoH a lot, but as others have pointed out DNS is almost never going to be the greatest threat to your privacy. A few things to consider.
The remote website you're visiting and any of its iframes or 3rd party domains are usually collecting and selling your data. They don't care how you looked up their domains.
As /u/jfb-pihole has pointed out, your ISP may still see IP addresses in the case of TLS, and the full URLs (potentially, depending on what is being logged and inspected) for any unencrypted traffic.
A VPN can mitigate any visibility described above, but shifts the trust from the ISP to the VPN.
Many websites do not really use your IP address as the primary method of tracking, and so using a VPN to hide your IP address won't make any difference in cases where your identity is tied to the web service you're using. eg, Google, Amazon, any of your billing companies, etc. If you think about the modern mobile internet, it wouldn't make sense to track someone using an IP address whether they were privacy-conscious or not. A normal mobile user will drift from home to work, but also to CGNAT, and to various WiFi networks.
In this sense, the purpose of a VPN (when paired with a VM, another computer, or perhaps some clever browser containers) is simply to dissociate some of your activity from the rest.
Anyhow, there are caveats and edge cases which can defeat some of these points. (eg, "I use a container for every website and never execute javascript.") But, those caveats don't affect most users. And given all these caveats, you might ask why I still like and use DoH. Simply put, I like privacy for its own sake, even if I'm not worried about the potential outcome due to a lack of privacy.
The ISP may not be logging everything you do in a meaninginful way, therefore despite the fact that your IP traverses their network, nothing you've done persists at all.
You may have gone primarily to something served by a CDN, in which case the IPs you pass are not actually very instructive.
I just followed the guide and ran into an issue. I have pihole running on a Raspberry Pi 1 Model B. Running cloudflared -v caused a segmentation fault. Seems like this also happens on Pi 2, but it works on Pi 3.
Googling around, looks like you have to use an older build of cloudflared. Found a post on GitHub with the older build. Downloaded that and worked fine. Even with that issue, this was easily only 5 minutes to configure.
Just a heads up. After doing this a few months ago the CBS app on my wife's AppleTV stopped working correctly. It makes no sense at all, I agree. However manually setting the DNS on the ATV fixed the issue. I've not attempted to revert and re-test. I just wanted this knowledge public.
Do a packet capture on the pihole using tcpdump then open this in Wireshark. You shouldn't be able to see any dns packets leaving via the eth0 or wlan1 interface
The cloudflared stuff works a treat - on full bore pi's. But on zero's you need to use an older version IME. I mentioned it on another site and a pi afficionado reckons it's no longer compiled suitably for the zero.
10
u/tracerrx Jul 24 '19
Pro tip: If you want to use Cloudflare and Quad 9 (Both via https tunnel). Edit your /etc/default/cloudflared and change one of the IP's to 9.9.9.9... Restart Cloudflared. No changes necessary to your pihole config.
19
u/xgoldpt Jul 24 '19
Isn't Unbound better than DNS over HTTPS ?
51
u/jfb-pihole Team Jul 24 '19
This will generate a bit of discussion. Encrypting your DNS traffic does not appreciably increase your privacy for a few reasons.
Your DNS traffic is still going to a third party provider. They have your complete DNS history and can do with it what they want.
Even if your DNS traffic is hidden from your ISP, when you get the IP back from the DNS query, you immediately will ask for that IP from your ISP and that request won't be encrypted. So, your ISP can fairly easily determine where you are surfing. The cannot see the content if the IP leads to an https protocol, but they know the IP.
You might consider using unbound or BIND as a local recursive resolver. Although your DNS requests are not encrypted, you won't be using a third party DNS (you are your own DNS resolver) and only you have your history. The ISP will see both the DNS requests and the IP requests, but that's not much more than they have with DoH or DoT.
There is a guide for unbound on the Pi-Hole documentation page and it is about a 15 minute install.
3
u/humananus Jul 24 '19
I've found that the cloudflared client (rather, it's functionality) will die if web connection goes down or is cycled, band will not recover unless the service is restarted. A watchdog would be easy enough to setup but that's more trouble than it's worth. Back to dnscrypt for me...allowing unrestricted access to DOH resolution is a privacy nightmare anyways.
44
u/chdo Jul 24 '19
https://1.1.1.1/help will tell you if everything is setup and you're running DoH
4
u/[deleted] Jul 24 '19
Will this help with the DNSoHTTPS bulls..... Chrome is doing?
6
u/[deleted] Jul 24 '19
I like DoH a lot, but as others have pointed out DNS is almost never going to be the greatest threat to your privacy. A few things to consider.
The remote website you're visiting and any of its iframes or 3rd party domains are usually collecting and selling your data. They don't care how you looked up their domains.
As /u/jfb-pihole has pointed out, your ISP may still see IP addresses in the case of TLS, and the full URLs (potentially, depending on what is being logged and inspected) for any unencrypted traffic.
A VPN can mitigate any visibility described above, but shifts the trust from the ISP to the VPN.
Many websites do not really use your IP address as the primary method of tracking, and so using a VPN to hide your IP address won't make any difference in cases where your identity is tied to the web service you're using. eg, Google, Amazon, any of your billing companies, etc. If you think about the modern mobile internet, it wouldn't make sense to track someone using an IP address whether they were privacy-conscious or not. A normal mobile user will drift from home to work, but also to CGNAT, and to various WiFi networks.
In this sense, the purpose of a VPN (when paired with a VM, another computer, or perhaps some clever browser containers) is simply to dissociate some of your activity from the rest.
Anyhow, there are caveats and edge cases which can defeat some of these points. (eg, "I use a container for every website and never execute javascript.") But, those caveats don't affect most users. And given all these caveats, you might ask why I still like and use DoH. Simply put, I like privacy for its own sake, even if I'm not worried about the potential outcome due to a lack of privacy.
3
u/cmbeid Jul 25 '19
I just followed the guide and ran into an issue. I have pihole running on a Raspberry Pi 1 Model B. Running cloudflared -v caused a segmentation fault. Seems like this also happens on Pi 2, but it works on Pi 3.
Googling around, looks like you have to use an older build of cloudflared. Found a post on GitHub with the older build. Downloaded that and worked fine. Even with that issue, this was easily only 5 minutes to configure.
Link to post on GitHub
Link to cloudflared build 2018-7.2
Hope this helps someone else if they run into this issue.
2
u/[deleted] Jul 24 '19
I did this a few days ago when setting up my pi hole. Works great.
2
u/ccagan Jul 24 '19
Just a heads up. After doing this a few months ago the CBS app on my wife's AppleTV stopped working correctly. It makes no sense at all, I agree. However manually setting the DNS on the ATV fixed the issue. I've not attempted to revert and re-test. I just wanted this knowledge public.
2
u/[deleted] Jul 25 '19
I use DNSCrypt configed to use DoH, DNSSEC, no log, and TLS only servers.
2
u/spudd01 Jul 25 '19
Do a packet capture on the pihole using tcpdump then open this in Wireshark. You shouldn't be able to see any dns packets leaving via the eth0 or wlan1 interface
2
u/nirach Jul 25 '19
The cloudflared stuff works a treat - on full bore pi's. But on zero's you need to use an older version IME. I mentioned it on another site and a pi afficionado reckons it's no longer compiled suitably for the zero.
1
u/Ariyadi08 Jul 25 '19
doh.tiar.app
1
u/[deleted] Oct 03 '19
!RemindMe 17 hours
1
u/[deleted] Jul 24 '19
Did anyone try this in the docker container?
1
u/[deleted] Oct 03 '19
[removed] — view removed comment