Pi-Hole and IPFire, which way round?


I’m trying to get Pi-Hole working with IPFire, and have the following issues, and was wondering what the best way around this it:

IPFire config:
Webproxy enabled
Transparent Proxy enabled (for Android devices which do no have manual proxy settings).
Customprerouting config so all DNS queries from GREEN are routed to the IPFire resolver (I don’t want devices trying to go to google DNS directly).

Client > P-Hole (for DNS) > IPFire > Internet (for DNS)
If I place Pi-Hole behind IPFire the blocked website is still loaded by a machine using the proxy. If I disable proxy settings on the client, the site is blocked successfully.

Client > IPFire > P-Hole (for DNS) > Internet (for DNS)
If I place Pi-Hole in front of IPFire, everything breaks, as IPFire sees Pi-Hole as DNSSEC not supported. This is strange, as I built a 2nd IPFire box to test this, and that one says DNS Validating. So what’s wrong with my 1st IPFire box?

i have ipfire (proxy transparent for green)->pihole (it’s dns ipfire, pihole is dhcp and dns for the client’s)
->client’s works well.

I think you should not use pi-hole, because it breaks DNSSEC. You will need to trust your DNS.

Are you saying If I use Client > Pi-hole > IPFire > ISP, DNSSEC is broken? I wouldn’t have thought it would be, as IPFire is still using DNSSEC Aware Upstream.

I understand Pi-Hole will cache DNS Queries, but they would have come from a DNSSEC aware route already, right?

What I want to do is block certain domains for Android devices, as they are not using the proxy, and I don’t want to go round configuring them.

Any other options?

Pi-Hole will give you a different DNS response than what is in the global DNS.

So lets say you want to filter google.com, they will give you an invalid IP address ( for example) instead of the actual IP address that Google wants you to see. google.com is not signed, so you will get away with that, but ipfire.org is DNSSEC-signed: You will get an invalid response and if your client would validate, you would get an error.

You can have the proxy configured by DHCP which would take that burden away from you.

So I guess this relates to what the pi-hole log shows:
google.com (INSECURE)
ipfire.org (SECURE)

Apologies, I’m not getting what you are saying. My setup is working without errors so far. Pi-Hole is sitting in between the Client and IP Fire. IP Fire is the only box that can resolve external DNS, so is there still a risk?

I will look at DHCP, but would like to run Pi-hole as a tool for logging really. But I didn’t think Android devices would work. I currently use the DNS method to deploy it.

EDIT: I am actually using DHCP at the moment, and Android devices definitely don’t support it.

In this setup you would at least make sure that DNSSEC signatures are being validated locally and that would minimise chances to spoof any DNS replies on the RED side.

However you still have that risk in your local network.

Why do the pi hole people not use native mechanisms like RPZs?

have a look at https://discourse.pi-hole.net/t/implement-response-zone-policies-nxdomain-for-end-user-performance-increase/1342

in my case too. Pihole is using IPfire as it’s DNS. Also you can turn on DNSSEC in Pihole works well here.

in addition unfortunately in German

As mentioned here Pi-Hole does:

“Verify DNSSEC signatures, discarding BOGUS domains”


it filters DNS records. That is no possible with DNSSEC.

I understand that. That’s why it can only verify them.

Anyway, to contribute to the question asked, I use Pi-Hole behind my Firewall that has transparent proxy enabled with no problems.

Thanks for all the responses guys.

@nik7 I don’t have problems with transparent, but IP Fire proxy content filtering does not work for Android devices, as they do not pick up the WPAD settings, and I don’t want to go around configuring each device (especially guests).

Ok - I thought that pi-hole didn’t work at all.
Now your situation is more clear to me.

Although I might sounds really anti pi-hole all the time (and which I am for many reasons) I would like to say that I generally agree with this functionally and that IPFire should provide something similar too.

It is just quite difficult with DNS and maybe a solution could be to strengthen the web proxy feature. There could be a couple of options…

Ill only be using pihole as a monitor of what going on really, the IP Fire content filter is a better way of managing blocks via categories. Who know, might end up ditching Pihole. Just trying various solutions to manage blocked all the crap :smile:

Michael Tremerms

Nov '19

Although I might sounds really anti pi-hole all the time (and which I am for many reasons) I would like to say that I generally agree with this functionally and that IPFire should provide something similar too.

It is just quite difficult with DNS and maybe a solution could be to strengthen the web proxy feature. There could be a couple of options…

I’m interested.
Ipfire the pi-hole buster. :smile:

1 Like

Can you please go into more details Michael? What is the risk if (i dont really understand what can go wrong besides some Software breaking that does DNSSEC)? And is there a better alternative that uses RPZ?

Yes, a little. I probably should write a longer article for the blog, but I not want to sound too miserable about technology out there and constantly piss off other people who are working hard on their software projects.

The problem I see with Pi-Hole is that it is sitting someone in the middle of the network and is just catching DNS packets and depending on a blacklist won’t forward the queries any more.

It acts as an authoritative name server on behalf of other domains. The deliberately send you a spoofed response and tell you that “some-porn-site.com” does not exist although it might exist. That is exactly the same method that an attacker would use to lead you to a faked website and not the one of your bank.

You don’t see that the DNSSEC validation process fails because no DNS resolver in a mobile or desktop operating system validated the signatures. But IPFire does. We at least make sure that the firewall has received a correct and valid, non-spoofed response. Transport over the local network might still be under control of an attacker, but that is a lot less likely.

When Pi-Hole sits in front of IPFire, it simply won’t forward any DNSSEC signatures to unbound which then cannot validate a DNS response. It will instead send a NXDOMAIN response for domains that should be blocked. Those need to be signed, too, because otherwise an attacker could just filter DNS queries and not respond to them. Your browser will receive a different error code which is SRVFAIL in case of the signature not being validated, but will unfortunately show you the same error page which says that the website “was not found”.

That is a huge problem and a “bug” in the browsers that Pi-Hole is taking advantage of. Hopefully operating systems will soon validate DNSSEC signatures and this will no longer work.

I think that the proper way is to use the proxy which will let the browser know that something has been filtered and present a proper error message that says exactly that to the user, too. This is not complicated to configure at all and complies with Internet RFCs.

Breaking DNS is a sensitive issue for me. There are many players who break it in one way or the other. Unfortunately DNS is becoming more and more important because we put more and more information into DNS records that are simply needed to run the Internet.

I want to be able to access the whole Internet - wherever I am.

And although I see the point of filtering porn websites in a school, there is a better way how to do that and breaking DNS isn’t it.

EDIT: I also had a look at pi-hole’s code and thank god I was sitting down…


Sorry for bringing this Topic back.

What i am missing the most is the overview about what my network is doing. Would be really great if Ipfire could do that too.
And whats the best way to setup Ad filtering for my Network? There is this Guide


but its getting old and i dont know if this is still the best way to do it.