Running PiHole in a multi subnet routed environment which is working quite well.
Only issue I have is with PTR queries for local private subnets which i actually want to answer rather than forwarding or rejecting.
I've had a look around, but can't seem to find how to do this.
Note that there is no DHCP server in use, they are all statically assigned.
I have a PowerDNS server and set the ARPA zone in Pihole to conditional forward the zone, but this is both a duplication and also stopped working sometime around version 4.1 (I think)
I can't manually set a record for these in PiHole directly, i can set it as a CNAME, but thats not going to break things.
I did read you can set this in the hosts file, but i really would prefer to avoid that and just do the ARPA zone in PiHole or a flat file read in by FTL.
Advice appreciated
Expected Behaviour:
[Answer the PTR queries from a local zone file on the PiHole server somehow]
The various devices spread over the subnets are using 2 central PiHole servers to complete DNS lookups (as resolvers)
Cloudflare DNS holds the forward zones for the device hostnames as not all of them need DNS names
There was a powerDNS server performing Reverse lookups, with PiHole conditional forwarding to that server, but that appears to be broken
Its not a traditional setup, and it probably raises some questions, but there are not a lot of interdependencies leading to device A doing a lookup for device B so cloudflare is rarely hit inside the network
So:
example.net is pointed to Cloudflare
so device55.example.net is on VLAN100, with static IP 192.168.100.100 using 192.168.155.61 (PiHole) for DNS recursion.
the hostname device55.example.net is set within Cloudflare
But the reverse of 192.168.100.100 is what i am trying to handle so that PiHole resolves it when (rarely) queried. Ideally this would happen from a zone file in PiHole directly.
I'm not sure whether I understand your configuration.
A public DNS server like Cloudflare (1.1.1.1) would not resolve hostnames like device55.example.net to private IP addresses like 192.168.100.100.
If that domain had a public IP address, Cloudflare would be able to correctly answer the respective PTR query (with that public IP).
If you want Pi-hole to answer a local private IP for your otherwise public device55.example.net, you'd have to create a respective local DNS record, which should also give you reverse lookups for that definition.
A public DNS server like Cloudflare (1.1.1.1) would not resolve hostnames like device55.example.net to private IP addresses like 192.168.100.100 .
It will when example.net is my own domain, delegated to Cloudflare as they are the authoritive nameservers. (Eg not Cloudflares public recursors) - Cloudflare DNS | Authoritative and Secondary DNS
Where you host your own zone with cloudflare.
So in this setup running dig A device55.example.net @ivan.ns.cloudflare.com would return 192.168.100.100 (and it does work)
What it wont do is answer a PTR request for 100.100.168.192.in-addr.arpa - eg it won't handle the reverse of this which is why i need a server locally to host the in-addr.arpa zones
This is how Cloudflare works when you use it for your public zone and use their DDOS mitigation / reverse proxy service. You delegate the domain to their nameservers and they host the public zone for you. (it's also free for their basic package)
Anyway, this is somewhat off topic, this boils down to "How can I make Pihole host a .in-addr.arpa zone".
There is no upstream server to answer the requests (as the Cloudflare zone isn't locally integrated, the devices don't register with them for their names. The router won't do it as its a static allocated device (it's on a Juniper) and DHCP isn't in use.
The only way (at least that i know of) is to host a reverse .in-addr.arpa zone. which was working, but since stopped.
I figure this is possible somehow as PiHole is capable of responding to A and CNAME queries so I'm hoping there is some advanced setting where i can shoehorn in a .arpa record / zone
It is, your configuration is just a bit ... bizarre. I'm not seeing why you'd actually host internal IP addresses on a publicly reachable name server. Because whoever gets the addresses outside your network (and I consider VPN somewhat inside your network) won't be able to anything with them.
To me, the proper implementation would look like hosting your entire zone locally. You can leave the top-level domain public, that won't harm. Just write all the content into, e.g., /etc/hosts on your Pi-hole and you're set. No need for any of this on Cloudflare anymore. This will ensure that both A and automatically generated PTR will work as expected without the need to ask anywhere upstream. The same wisdom will be available "to go" through a VPN.
If you chose the local domain of your Pi-hole to be the.....rk.net, it will even suffice to register the subdomains, following your example above:
avalon 192.168.151.31
dns01 192.168.155.61
They will then become available both with and without the TLD attached to them. dig avalon will work as well as dig avalon.the.....rk.net will work without the operating system needing to try a second time with the search domain attached (talking about the former case).
Since you seem to be using a /16 network, you may also want to enjoy the luxury of DHCP with this configuration. It will make editing /etc/hosts unnecessary. Pi-hole has a deterministic DHCP server, i.e., instead of enumerating devices in their order of appearance, it computes a hash based on the MAC (DUID) and tries to assign the same IP address to the same devices every time.
I know from my own experience that many users having an advanced network configuration at home think that static configuration is the best approach to things, and I may or not have done something similar before. Once you sit down and think about it for some time, you will likely see that DHCP is indeed a better option (don't remember the IP addresses, just log in via ssh avalon). Just leave the router and DNS on static assignments to absolutely rule out possible issues here. But it may take some time to realize it's something for you if you have done it differently before. Just a warm advise to make your life simpler
Most of the zone is for external use, there are just a few things internal.
The correct config would be split horizon, but i don't want that complexity.
Yes, correct. Am aware of this limitation
It would be split horizon, rather than hosting locally. The problem with the hosts file method is that there are some devices with 3 or more NICs that need a specific PTR for one of the interfaces. So hosts file won't correctly apply in this use case.
I have used at scale DHCP before, including multiVLAN. Sadly some of these devices are static only because the manufacturer doesn't support DHCP on them (LOLWUT). but also that they have multiple NICs for things like HA networks which are controlled by the devices themselves.
My take away from this is that PiHole works best with DHCP / integration which makes sense given what it is and where it is targeted in the market (so to speak). The config i am doing is well off the beaten path.
Could my network be changed to better suit it, yes, and that would make it work and PiHole respond to the PTR lookups properly, but my limitations mean that isn't possible at this time.
To directly answer my own question, from what i have gathered, it is NOT possible to manually host a .arpa zone through PiHole - that would need to be a separate server.
Thanks for your assistance guys, appreciate your time.
I do understand your network better now, I still don't know why you don't want split-horizon. Instead of setting up the local devices somewhere online, you can do the same on your Pi-hole. And yes, it is a limitation of the DNS caching forwarderdnsmasq, we use, to not be able to set up zones like would want to. You'd need a full-blown DNS server for this (as you said).
