Short term user of Pi-Hole here, been an avid user of pfSense with SquidGuard for years but this project appeals to me. The Dashboard i.e. is great and so is the logging.
To suit all DNS needs the project could be complemented with an DNS resolver, like Unbound. This way no external DNS servers need to be configured, with the added bonus of privacy (the ISP or other DNS service provides will not see your requests) and better reliability since the independence of the ISP for DNS. I've been running the Unbound DNS resolver using pfSense for a long time and it has been performing fantastic. Sure there are many more advantages in running your own resolver. It would be neat to have it all in the same little Raspberry Pi box.
Maybe a setting could be made for a circumstance when the Pi-Hole resolver is unresponsive, to fall back to preconfigured DNS servers, i.e. Google or OpenDNS. Really anxious on everyones thoughts about this.
Just to be clear, both unbound and dnsmasq(used by Pi-Hole) are DNS resolvers.
The title of this thread is misleading as dnsmasq(Pi-Hole) is already resolving via DNS against the upstream configured servers.
But unbound is no good replacement for dnsmasq as its lacking the DHCP service.
EDIT: You could have both daemons running on the same system but that would need a bit of hacking and doesnt fit in as a "Feature Request".
Dnsmasq is a DNS forwarder, it forwards the requests made by clients to the upstream configured DNS servers. Unbound is a a validating, recursive, and caching DNS server, a resolver. It contacts rootservers. Nice explanation here: Unbound DNS Server Tutorial @ Calomel.org
Both are DNS servers for the connected LAN, but the way the operate are quite different. A local resolver has many benefits; in many situations more reliable since it bypasses sometimes dodgy ISP DNS servers, it supports DNSSEC and it improves privacy since your requests are only made from the rootservers down. Having it in Pi-Hole would make the package complete, as a standalone DNS application.
How does that tackle the issue of dhcpd missing ?
Should you make the system over complicated by running two daemons (dependencies!) for the few users who got an exotic setup ?
I can imagine a Windows guy to want Pi-Hole to manage a Xen domain to run his favorite Windows DNS software in.
You can run both daemons, forwarding one to the other, with losing maybe a tiny bit of performance.
But someone needs to figure out first or maybe a similar howto is already floating about on the net.
Unbound can be run on the same device as the Pi-hole, you would just need to run Unbound on a different port and then change the upstream to point to that new port scheme.
I run multiple Unbound installs on different VPSes and then forward my Pi-hole to those Unbound installs as upstreams.
We have been looking for a while at how to allow users to change the resolver used, and to see if it's feasible to be more modular in the installation. That will take a lot of time to work out, but it's something that has been discussed by the development team.
With FTLDNS, we finally implement official support for this, read more details below.
We, the Pi-hole core developing team, have discussed how to tackle this feature request best. It is clear that we do not want to implement this into our own DNS resolver at this stage, but want to rely on an already well-tested recursive DNS server. So, we had basically been three options available: Firstly, script everything up for this and install it during the initial installation; secondly, script everything up and give users the option to have it installed with with one keystroke; and thirdly, write a tutorial explaining how to do it in a few steps.
After some back and forth, we decided that the third option is the best for several reasons: Many users are installing Pi-hole on a vast amount of operating systems - Pi-hole is by far not limited to Raspberry Pis and Raspbian at this point. Coding such an automated script that will support all systems would be a major undertaking that could likely never be truly finished.
Presenting it in the form of a tutorial has a few advantages:
One of them is that we get the possibility to explain a few further DNS principles so you can better understand how your newly configured system will behave and why this is preferential in terms of privacy and security.
Another one is that users with non-standard systems will hopefully be able to adapt our instructions easily as we always describe what and why are doing something.
Our wiki article can be found here:
The implementation is already fully available in the most recent version of the FTLDNS beta testing branch.
It can also be implemented with Pi-hole v3.x, however, this will require some scripting (put server=127.0.0.1#5353 in your /etc/dnsmasq.d/01-pihole.conf and remove all other server lines in there). Note that with Pi-hole v3.x both CLI and the web interface won't support it and may behave unexpectedly.
Thanks, I like the workaround in the wiki article. However, a lot of potential of unbound is wasted.
Especially the blocking option of unbound, which works much more effectively with an NXDOMAIN response than the timeout to 127.0.0.1.
A very nice conversion offers GitHub - sfeakes/ipfire-scripts: Scripts for ipfire using dns_blocklist.sh
The extended use case: /bin/dns_blocklist.sh -s 1,2,3,12,13,14 -b /etc/unbound_control/blacklist.hosts && sed -i 's/local-data/local-zone/g; s/[[:space:]]A 127.0.0.1"/" static/g' /etc/unbound/local.d/blocklist.conf && /etc/init.d/unbound restart
Furthermore, it is avoided that all requests are (can be) logged by a dedicated external forwarder.
Using qname-minimisation: yes, privacy becomes more important.
There is development on this going on alongside FTLDNS. The most severe problem with NXDOMAIN is not the implementation (Pi-hole actually supports this since the very beginning, there was just no automated script for this), but the consequences as a huge number of users rely on the blocking page which will obviously not be available any more when sending out NXDOMAIN replies. Many of us don't use/need the blocking page and there is actually work going on behind the scenes to offer a one-click solution for switching between the current and an NXDOMAIN behavior (@PromoFaux and myself are currently working on it). See also
