When I choose Cloudflare as my DNS provider in the Pi Hole settings, I can’t access certain sites. Actually, the only one I noticed was aljazeera.com.
Does anyone else experience that? I find this odd since aljazeera is a news website. Then again, Cloudflare is an American company…
When I choose, say Quad9, I works.
I’m aware that I should rather post this in the Cloudflare forum but that would mean to register yet another account and I can’t be bothered right now. They don’t offer any other possibilities to contact them other than to sign up.
There have been reports of Cloudflare and other DNS providers not returning an IP that was subsequently returned by another DNS provider. Examples I recall were a German bank and a British telecom domain.
It has nothing to do with the ownership of Cloudflare. Quad9, for example, is headquartered in Berkeley, CA.
I am located in US - ran dig on aljezeera.com to Cloudflare, Google, and Quad 9 and received the IP in each case.
I think that is where your solution lies. It is not a Pi-Hole issue.
That said, if you run unbound as your local DNS resolver, you will avoid any third party DNS filtering. It's an easy setup.
Thanks for the update.
Here's another strange behavior I noticed:
When I change DNS settings in Pi Hole to OpenDNS, I cannot visit any websites anymore.
The browser initially seems to want to connect to an IPv6 address when I open it up although I checked OpenDNS under IPv4.
I just updated and -graded the Raspberry Pi software (stretch) and the Pi Hole installation (there was nothing to update in the latter) and still the same behavior.
When I change back to Quad9 or so, the internet is back.
So what could be the flaw here? It must be on my side, since you can resolve e.g. aljazeera through Cloudflare and I cannot.
In the DNS settings I checked the top right box "Listen on all interfaces" and under Advanced Settings I checked all the top three (Never forward non-FQDNs and reverse lookups for private IP ranges plus Use DNSSEC).
As for unbound, I have thought about setting up my own DNS server, but read that you shouldn't use the recursive version since it can lead to loops while looking up DNS and eventually blacklisting by hosts.
The iterative version is supposed to be more reliable. Gotta check that out. However, I'm on a 4 GB SD card at the moment which is probably too tight for all the caching and so forth.
"
Recursive DNS query risks
A DNS server that supports recursive resolution is vulnerable to DOS
(denial of service) attacks, DNS cache poisoning, unauthorized use of
resources, and root name server performance degradation.
"
Servers that support this type of request are vulnerable to fake requests from a spoofed IP address (the victim of the attack), the spoofed IP address can get overwhelmed by the number of DNS results it receives and be unable to serve regular Internet traffic. This is called an Amplifier attack because this method takes advantage of DNS servers to reflect the attack onto a target while also amplifying the volume of packets sent to the victim."
A DNS server that supports recursive resolution is vulnerable to DOS (denial of service) attacks, DNS cache poisoning, unauthorized use of resources, and root name server performance degradation.
DOS attacks
Servers supporting recursive DNS queries are vulnerable to phony requests that flood a particular IP address with the results of each server's query. This can overwhelm the IP address with a volume of traffic too large to be processed.
DNS cache poisoning
Cache poisoning results from someone tricking a DNS server into believing that a fake DNS query response is authentic. Because responses are normally cached, this false information can be distributed to users of that server.
Unauthorized use of resources
With recursive DNS queries enabled, a server is more easily hijacked and its performance compromised."
Interesting reading and technically correct, but there is a significant difference when you use unbound as a local recursive resolver. The articles discuss DNS resolvers that are open to the internet. The big DNS providers are aware of these risks and have implemented security measures to protect them.
Unbound will be running inside your private network, not open to the internet. So, DOS, DNS cache poisoning, unauthorized use of resources and root name server performance degradation are not going to be an issue unless you have a serious network flaw. The only DNS requests that unbound will see are coming from your private network, and your recursive resolver is invisible to the internet.
If port 53 on your network is not open to the internet, then nobody on the internet can make DNS requests from your network. The risk of an open port 53 is the same to you whether you run unbound or not. If somebody has access to your port 53, they can put as many DNS requests as they like. If this were the case today, they would make these requests and Pi-Hole would forward them to Cloudflare.
One more detail - unbound doesn't listen directly on port 53 when set up per the guide. Unbound is installed on the Pi, and listens on the loopback address 127.0.0.1 at port 5353. So, this port can only be accessed from the Pi itself and Pi-Hole is the only client set up to send traffic to that port. So, all requests to unbound first go through Pi-Hole (and you'll see all the requests).
A port scan from here will identify any of your ports that are open to the internet. If you run this test and don't have any open ports (particularly port 53, which serves DNS), then your local resolver will be private.
Here is how it should look if your network is set up properly:
Thanks for the clarification. Makes sense. I'm learning.
In that case I will try out unbound (after backing up my running Pi Hole installation).
The only port I opened actively on my router is one so that the Pi can communicate with a DynDNS as described in the PiVPN setup. I used a different one than in the manual, as I've read this should minimize random attacks on well known ports.
I know the GRC link and I've already tried it. I don't get the green grid graphics but a "THE EQUIPMENT AT THE TARGET IP ADDRESS DID NOT RESPOND TO OUR UPnP PROBES!" note. Which is also good.
