The DNS filter software PI-Hole is available in version 5 and can also run as a container on Turris Omnia. Is there any experience with the interaction of PI-Hole and knot? How can I connect PI-Hole from the container to the name services of TOS? Can DNS queries to TOS be redirected to PI-Hole without changing the DNS entries on the clients?
Cheers Harry
1 Like
I’m using pihole in a lxc container (Ubuntu 16.04), it works pretty well.
lxc containers run on an internal ssd, pihole has a separate IP which is configured in the Turris DHCP server and forwards queris to Turris resolver (kresd).
1 Like
Yes. I just want to stress that if you want both Pi-hole and Knot Resolver (or generally, both filtering and a validation), you want to put filtering between clients and the other resolver, not the other way around. That’s because there’s no good way of proving if a change in DNS content was wanted by the user. Otherwise the filtered names would cause lots of retries.
1 Like
You can run PiHole in LXC container ; once set-up and running, you go to Luci > Network > Interfaces > LAN ; scroll down to DHCP part and there go to “Advanced Settings”
There is DHCP-Option where you add your PiHole IP (sample where .1.1 is TOS and .1.2 is PiHole) 6,192.168.1.1 to 6,192.168.1.1,192.168.1.2 (save-and-apply)
That will propagate both resolvers to the DHCP clients as 1st and 2nd dns servers. You can change the order there 
If you want PiHole to be “main” resolver you have to set TOS resolver to forward ( Luci > Network > DHCP and DNS > General Settings and there is DNS forwarding options ) dns queries only to Pihole (which will forward it to some public resolvers or your own).
notes
btw: i have kresd/dnsmasq serving to dynamic/static domains so i am not forwarding any queries out and Pihole is forwarding queries to TOS first as second to NIC.cz resolvers and as third to google. So i have it as backup and for some “static” clients (like TV, MediaCenters to use only pihole)
(i am having omnia with 3.x branch) , so i do not have any know-how for 4.x or 5.x branches , but i hope that above mentioned hint is valid, if not let me know and i with withdraw my post
2 Likes
Thank You. That’s exactly the information I was looking for! I already switched to TOS 5.0. I will test the new pi-hole release the next days.
Regarding the reply from Maxmilian_Picmaus I’d like to share my personal recent experience regarding DNS forwarding.
As I use multiple interfaces I wanted to avoid adding Pihole (running in a LXC container) as a DNS parameter to be passed to clients by DHCP.
However, I still want to use the “local name resolution” within my LAN.
Therefore I did the following:
- Leaving the DNS settings in each interface untouched. Each client in each interface uses the Turris Omnia (e.g. 192.168.0.1 , 192.168.77.1) as DNS.
- I created a new file
/etc/resolver/dns_servers/99_pihole_local.confcontaining
name="99_pihole_local.conf"
description="Pihole"
enable_tls="0"
port="53"
ipv4="192.168.0.2"
hostname="pihole.lan" - In
/etc/config/resolverwithinconfig resolver 'common'I added
option forward_custom '99_pihole_local'
option forward_upstream '1' - In Pihole Settings > DNS Use Conditional Forwarding is now enabled and points to the DHCP (192.168.0.1) of the Turris Omnia.
Limitation: I am not sure, whether the local name resolution would work, if the destination host is in a different subnet, e.g. 192.168.1.* .
Source for this solution is https://doc.turris.cz/doc/en/public/dns_knot_misc .
I don’t get how this is supposed to work; I see a cycle.
It looks like clients send to 192.168.0.1 which runs a resolver (kresd) configured to forward to pihole at 192.168.0.2 which is configured to (conditionally?) forward back to 192.168.0.1. Maybe I misunderstood something 
It is a cycle indeed.
However, according to the note on the Pihole settings page
One solution for this is to configure Pi-hole to forward these requests to your DHCP server (most likely your router)
it is not the DNS on 192.168.0.1 that is queried in the cycle, but rather the DHCP.
Of course it would be much nicer if requests are only forwarded to Pihole if not found in 192.168.0.1 and within the local domain.
DHCP server does not answer DNS queries. It gives you the address of DNS server that does it, but in Turris case it’s the router address… so I think it results in what I posted. (Side note: yes, dnsmasq is an exception that runs both DHCP and DNS server in a single process.)
Thank you for the clarification.
Any idea how to break this cycle?
I’d personally do that, with 6,192.168.0.2. And drop that 99_pihole_local.conf.
That way DHCP instructs your LAN clients to ask pihole which forwards to normal Turris resolver. And you can configure that one in various ways (no forwarding – my favorite, forwarding to ISP servers, forwarding to some public resolvers).
Actually I intended to design the forwarding the opposite way for the following reasons:
- I use multiple interfaces with different subnets (e.g. 192.168.0.* vs 192.168.99.*)
- In case Pihole fails (for whatever reason) I only want to deactivate the forwarding in Turris Omnia
- As far as I understand I would need to add extra firewall rules to access 192.168.0.2 from other subnets as those use different interfaces and zones also
This cycle/loop issue would not let me sleep. 
I disabled Pihole Settings > DNS Use Conditional Forwarding, tested it, and apparently dnsmasq first looks in the locally known host names and then forwards the request to Pihole.
Various requests using dig on a VM in the same network successfully return the corresponding IP addresses.
Hmm, right, those seem valid reasons. There’s one disadvantage I know, but perhaps it’s not as important:
To keep the order you want and break the cycle, pihole should forward to ISP’s resolver (or some public resolver).
These three problems also don’t happen if you simply use the adblock package instead of pihole, as that’s integrated as loading RPZ rules into the default resolver, but I assume you have some reasons why you prefer pihole.
1 Like
Absolutely.
The order now is
- requesting client …
- Turris Omnia
- Pihole
- Quad9
I should just clarify that Omnia uses kresd (Knot Resolver) as default for DNS, not dnsmasq.
Thank you, I edited my previous post.
Regarding pihole vs. adblock - I personally found the statistics very interesting. Besides, part of the motivation was to learn more about LXC containers.