Like many, my homelab uses a FQDN for the many things I host. This makes it easier to access things quickly and means I don’t need to remember the various port numbers for all the different things.

For a while I was using the same DNS server we use at work, a Windows Server VM running AD with DNS. While this is great, Windows AD DNS isn’t greatly compatible with the software I eventually want to use to manage DNS records, DNSControl. DNSControl is a DNS as code solution that allows you to easily manage DNS records from a git repository. DNSControl is compatible with Windows AD DNS, but it requires running from a Windows GitLab runner and the integration is currently looking for a new maintainer, so best to not build a new homelab around it.

This is where PowerDNS comes in. After a bit of research I selected this as the software to run my DNS server, running on two Raspberry Pi 4’s. One Raspberry Pi will be the primary, the other will be the secondary. Changes made on the primary will replicate to the secondary.

Components

PowerDNS can run from a single Raspberry Pi, however I prefer to have some redundancy with DNS as without it, normal internet access can be impacted. As such I run two Pi’s, so if I need to, I can power one off and still have functioning internet.

Part Qty
Raspberry Pi 4 4GB 2
Raspberry Pi Case 2
64GB MicroSD Card 2
AmazonBasics USB2 USBC to USBC 2

Architecture

PowerDNS Architecture Diagram

There are four main components to the PowerDNS Architecture:

Component Port Purpose
PowerDNS Authoritative Server 5300 Hosts our Homelabs domain zone
PowerDNS Recursor 53 Forwards requests to our Authoritative server & handles public domains
Postgres 5432 Stores our data for the authoritative server
PowerDNS API^ 8081 Handles API requests to the Authoritative server

^The API server is part of the Authoritative Server package

Authoritative & Recursor

Previously, all that was needed was an Authoritative Server, with the recursor option enabled. This allowed the Authoritative Server to answer DNS queries for Domains it wasn’t in charge of. Recently this has been split out into a second package.

This now means that the Authoritative Server can only answer DNS queries for which it is the Authoritative Server, ie, only zones it hosts. As such we need the second Recursor package to act as the main DNS server, and only forward requests for our internal domain on to the Authoritative Server.

These can be on the same device, but will need to use different ports. The standard DNS port is 53, so the Recursor will handle that, and we will need to move the Authoritative Server to a different port. For ease I will use 5300 for this, but you can use whatever port you wish, just be sure to adjust the config as you go to suit.