Pi-Hole with PowerDNS backend

I've just finished deploying my Pi-Hole setup for my homelab, which replaced the recursive function of a PowerDNS authoritative server (as of Pi-Hole's deployment I upgraded the authoritative server to a more recent version that did not have recursion built-in). Question: does anyone here have any thoughts or experience with using a DNS backend for pi-hole that was not dnsmasq? (I'm initially looking at the PowerDNS standalone recursor, but will look at other options) I already have an ISC DHCP server deployed elsewhere on the network with Glass Admin, so I don't need the DHCP functionality.

Background:
One thing I noticed when connecting the pi-hole to my authoritative server is that it only supports one upstream per domain (at least as far as I could tell). Before pi-hole, I had 3 DNS servers: two authoritative (PowerDNS for the DNS/DHCP domain name and MS DNS Server for the Windows AD domain) and one secondary that cloned both the PowerDNS domain and the AD domain. The pdns auth also carried a secondary zone for the AD domain, and my DHCP server distributed the IPs of my pdns server and my secondary server as the nameservers. Both of these servers allowed recursion to 1.1.1.1, and the windows DNS did not allow recursion. Basically, no one except the DNS servers knew Windows DNS existed.

Ideally, I'd like my recursive server to do this:
int.example.com: pdns-auth, dns-secondary
win.example.com: win-auth, dns-secondary
0.0.10.in-addr.arpa: pdns-auth, dns-secondary
default:1.1.1.1, 1.0.0.1

When I tried this with dnsmasq by using two server directives per domain, I noticed that all queries were getting routed to my secondary. Since the secondary has a copy of all the needed zones, resolution speed is not an issue, however the point of having a redundant authoritative server is lost if the recursive server will only query one of them. Separately, I will also be working on a synchronized second pi-hole node (because redundancy)

As a hobby programmer, I realize that this may not be a small feat as different recursors have very different control interfaces to dnsmasq. From my basic knowledge of the interaction between pi-hole and dnsmasq, the new interface would need to be able to change the config, acquire statistics for API, and trigger a restart. On the good news side of the spectrum, I think at least pdns_recursor can be convinced to read the host file format that pi-hole already uses for dnsmasq

Is it imperative that you have multiple authoritative resolvers running (is that vital to your network function)?

If not, I have found that running FTLDNS and unbound as the local recursive authoritative resolver works quite nicely, even on a limited power device like a Pi Zero. I serve 26 clients and 40K requests per day.

Since I like the PiHole functionality on my entire network, I run two separate Pi's, each with PiHole and unbound, and in parallel. One is listed after the other in my router DNS settings, and the first listing gets 99% of the DNS queries. The second is pretty much in standby in case the first Pi crashes.

It's not imperative since this is a homelab and not a production environment (DNS is actually the only redundant thing on my network outside of NIC teamed servers), but my Windows DNS is unreliable enough that I'd like to have a backup of at least that one. In a simplified model, I could just have dnsmasq or unbound query the pdns auth server, which would serve as a secondary for the windows DNS

So it looks like in that case, you use dnsmasq/FTLDNS -> unbound, which has root hints and can fully resolve queries on its own without recursion.

So the final version would be:

dnsmasq/FTLDNS -> unbound -> powerdns (internal)
                          -> powerdns (secondary of Windows DNS)
                          -> root NS based resolution

I might be getting confused here. Why not just run PiHole using unbound as it's local authoritative recursive resolver and have the PiHole be your DNS provider for the entire network? For redundancy, run a second PiHole in parallel in case the first crashes or loses power.

1 Like

The eventual goal is to have two pi-holes, but I can't use unbound to fully host a DNS domain easily- it can only normally be a recursive server, or use root hints to contact other authoritative servers. I have two internal DNS domains that are not internet facing, so just using unbound to point to them and the internet adds an extra step. I could probably get away with fitting the internal DHCP domain into Unbound (pfSense does something similar), but the Windows AD domain needs to be managed by a Windows server since the domain itself is stored in active directory. As far as I know the Active Directory Domain Services role actually depends on Windows DNS server being installed. So no matter what, I still need at least one of these two local authoritative servers.

What I was looking for is a different first-level recursor that can support more features than dnsmasq. Unbound fits the bill, as I could use either the forward-zone or authority-zone blocks to define where my authoritative DNS servers are, then all the rest can either land in a forward-zone for CloudFlare or be properly resolved using root hints.

Terminology check for my sanity: it appears that you are using the term "authoritative server" to refer a DNS server that can use root hints to contact the proper nameserver for each domain it encounters. Earlier, I was using it to refer to a DNS server that was the point of authority for a domain (actually contains the SOA record and is one of the ns#.example.com); the one that should be contacted. Does this term actually mean two things, or am I just confused? Is there a better way to refer to a DNS server that is the point of authority for a domain?

I'm not a DNS expert by any means, but to me an internet authoritative resolver is one that goes directly to the root hints, and then to the appropriate domain name servers, to get the DNS results directly from the authoritative servers. It doesn't query a third party DNS like Google or Cloudflare. I don't run a DNS for my local network (no Windows AD, etc.), so my only DNS lookups are to the internet. I use unbound for its combination of speed and reliability/security/privacy.

I don't know the correct terminology for a DNS provider for a local network.

I'm certain some of the smart DNS people on this site can provide some better information on this.

So by those definitions:

  • My two DNS servers are private authoritative-only (One PowerDNS Authoritative, one Windows)
  • dnsmasq/FTLDNS is a forwarding, caching server
  • Unbound and PowerDNS Recursor are forwarding, caching servers with the capability to use root hints for recursive queries

So with that, I'm looking for something that can fill the role of dnsmasq in pi-hole with the functionality of Unbound or PowerDNS Recursor

I wonder if you could use a PiHole for this with unbound as one DNS server, and also point it to your private authoritative servers as second and third sources.

DNS1 would be: 127.0.0.1#5353
DNS2 would be:  PowerDNS private
DNS3 would be:  Windows

Or, on just the windows machines list your windows DA addresses in /etc/hosts files (you might be able to put one of these on the network and alias to it). Don't know if that would work for what you need. I believe this is the first place a stub resolver looks on a Windows machine.

Or, could you put the information from your DA authoritative server in a Pi hosts file, so the PiHole would read it and give back addresses to requesting clients without having to go back to an authoritative private DNS.

Right now what I have (which works) is 1.1.1.1 as DNS1, 1.0.0.1 as DNS2, and the following as 02-mydns.conf in /etc/dnsmasq.d/:

server=/i.example.com/10.0.1.1#5300
server=/win.example.com/10.0.1.2
server=/1.0.10.in-addr.arpa/10.0.1.1#5300

Unfortunately for the hosts file idea (I use them a lot at work on both Windows and Linux nodes), I can put the DCs in my %WINDIR%\system32\drivers\etc\hosts, which works for Group Policy, LDAP and Kerberos (I think) on already joined machines, but the domain join queries a SRV record on _ldap._tcp.dc._msdcs.win.example.com when you execute a domain join (both Windows native client and Linux SSSD).