Add the ability to let Pi-Hole resolve DNS



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.


I can see it being usefull as being an option.
Not to have both running because you have to.


And that’s why it’s in Feature Requests :grinning:


Got it.

EDIT: at least it got bumped couple of times now :wink:


I knew I had seen this on the interwebs somewhere. I’m not sure if this link will help anybody or not.


I haven’t seen anything for unbound in my journeys.

I’m also assuming that there would be a performance/speed cost to doing something like this.


Any update regarding this optional feature ?


Like to know that too.


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= 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.

Help Us Beta Test FTLDNS

3 posts were split to a new topic: Unbound and IPv6


Works great thanks :grin: @DL6ER


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
A very nice conversion offers using
The extended use case:
/bin/ -s 1,2,3,12,13,14 -b /etc/unbound_control/blacklist.hosts && sed -i 's/local-data/local-zone/g; s/[[:space:]]A"/" 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.


Although qname-minimisation is a nice idea, in principle, it is not guaranteed to work always (and in fact doesn’t always work!). See for an analysis of this problem. We can surely discuss this.

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


there is it:

in combination with the sed command

sed -i 's/local-data/local-zone/g; s/[[:space:]]A"/" static/g' /etc/unbound/local.d/blocklist.conf

that sounds very interesting!

there is actually work going on behind the scenes to offer a one-click solution for switching between the current and an NXDOMAIN behavior


I just meant that there was (and is) no automated script within Pi-hole so far.


5 posts were split to a new topic: Unbound with Pi-hole v3.3.1


Hi there, this works now great but I am wondering; Why limiting this to “localhost” on the same machine?

A lot of routers can or already run some sort of Unbound process. I have an Edgemax lite-3, which also has Unbound running with about the same confuguration, however I can not change the IP address, only the port itself?!

Can this feature be extended, by making the IP address box in the GUI edittable as well?


26 posts were split to a new topic: Why not use the root servers directly for Pi-hole?



Very very nice!


Thanks you so much for this upgrade ! I’m using it since beta and works great !