DNS Introduction
Every name on your network resolves to an IP address through DNS. The mail server, the file server, the monitoring dashboard, the internal services that never touch the public internet: all of them are reachable by name only because something is doing the translation. For most homelab setups that something is the router, forwarding queries to whatever the ISP provided. This series replaces that with something more capable, more private, and more correct.
Running your own DNS infrastructure is not simple. It involves at least two distinct types of server, a validation layer, DNSSEC signing, and careful thought about which queries go where. This article explains the design. The following articles cover the implementation.
The two jobs DNS has to do
DNS resolution splits into two distinct jobs that are easy to conflate but should not be.
Authoritative DNS answers the question: what are the records for a zone I am responsible for? An authoritative server holds the definitive answer for the zones it serves. When something asks “what is the IP address of mail.yourdomain.net?”, the authoritative server for yourdomain.net is the one with the actual answer.
Recursive resolution answers the question: I have a name, find me the answer, wherever it lives. A recursive resolver does not hold zone data itself. It walks the DNS hierarchy from the root, following referrals until it reaches the authoritative server for the name it is looking for, then returns the answer to the client that asked. It also caches answers for their TTL to avoid repeating the same lookup.
These two jobs are kept separate for good reasons. An authoritative server that also does recursive resolution is harder to secure, harder to reason about, and violates the principle of least function. This series uses a separate resolver (Unbound) and a separate authoritative server (PowerDNS).
The network’s DNS architecture
The network this series documents has two sites connected by a VPN: a primary site and a remote site. Each has its own local subnet, its own services, and its own hostname conventions. All of them live under a single domain that is registered and controlled.
The DNS design reflects this:
Public internet
↑
Registrar nameservers (authoritative for public zone)
|
↓
PowerDNS on the primary server (authoritative for internal zones)
|
↓
Unbound on the primary server (recursive resolver + DNSSEC validator)
|
↓
All devices on the network (via DHCP)
Queries from devices on the network go to Unbound first. Unbound handles external names by resolving them recursively and validating DNSSEC signatures. For internal names under the private zone, Unbound forwards to PowerDNS, which holds the authoritative answers.
The remote site connects to the primary site via VPN, so its devices also use the primary server’s Unbound instance as their resolver. There is no separate DNS infrastructure at the remote site. If the VPN is down, devices at the remote site fall back to a public resolver for external names and cannot resolve internal names until the VPN recovers. This is an acceptable trade-off for a two-site homelab; a more resilient design would run a secondary resolver at the remote site, which is a future consideration.
The domain split
The network uses two DNS namespaces.
The public zone (yourdomain.net) is registered with a domain registrar and has public authoritative nameservers. It contains only the records that need to be resolvable from the public internet: the MX record for incoming mail, the A/AAAA records for public-facing services, and the SPF/DMARC records for mail authentication. Everything else is absent from the public zone.
The internal zone is served only by the internal PowerDNS instance and is not delegated in public DNS. Internal services are reachable by name from inside the network, but those names resolve to private IP addresses that are unreachable from the outside.
There are two ways to handle this split. The first uses the same zone name internally and publicly, with the internal PowerDNS serving private IP answers for names that differ from the public zone. This is called split-horizon DNS. The second uses a dedicated subdomain internally that does not appear in public DNS at all.
This series uses a subdomain for internal names. It is cleaner, less prone to confusion, and eliminates the risk of accidentally leaking internal hostnames into the public zone. The specific subdomain is a matter of preference. The articles that follow use yourdomain.net for the public zone and internal.yourdomain.net for the private one.
Hostname conventions
Before adding records to a DNS zone, it is worth thinking about naming conventions. Names that made sense when a network had three devices become confusing at thirty. A few principles that help:
Use the server’s role, not its hardware. mail.internal.yourdomain.net is more meaningful than february.internal.yourdomain.net, and remains correct if the mail role moves to different hardware. Reserve the hardware name (the server’s own hostname) for administration and management access. For public-facing services, use the service name.
Put site-specific resources in a site subdomain. If each site has its own router and its own services, a subdomain per site keeps the namespace tidy: router.site-a.internal.yourdomain.net rather than router-site-a.internal.yourdomain.net. Both work; the subdomain approach is easier to delegate and query.
Use CNAMEs for service aliases. If a single server hosts multiple services, a CNAME from nextcloud.internal.yourdomain.net to the server’s A record means the IP only has to change in one place if the server moves.
Be consistent with the VPN namespace. The network design section established a vpn.yourdomain.net subdomain for VPN endpoints. DNS records for VPN tunnels live there rather than mixed in with service records.
DNSSEC
DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that the answers they receive came from the authoritative server and have not been tampered with in transit. Without DNSSEC, a response to a DNS query can be forged. With it, a forged response fails validation and is rejected.
DNSSEC involves two sides.
Signing at the authoritative server. PowerDNS signs zone records with private keys. The corresponding public keys are published in the zone as DNSKEY records, and a chain of trust is established back to the DNS root by publishing DS records at the parent zone via the registrar.
Validation at the resolver. Unbound validates the signatures on every response it processes. A response that fails validation is treated as if the name does not exist, and the failure is logged.
For the public zone, DNSSEC is worth implementing. It protects the mail and web records that external clients depend on, and the chain of trust from the registrar makes it verifiable by any validating resolver in the world.
For the internal zone, DNSSEC signing is optional since the zone is not accessible from the public internet and there is no chain of trust to establish. The primary benefit of DNSSEC (protection against on-path tampering) is less compelling when all traffic stays on a VPN-connected private network. This series does not sign internal zones.
What the following articles cover
Unbound configures the recursive resolver on the primary server. It handles resolution for all devices on the network, validates DNSSEC for external names, and forwards queries for internal names to PowerDNS.
PowerDNS configures the authoritative server for both the public and internal zones. It holds the records for every host, service, and reverse pointer in scope, and uses the database backend for zone storage.
DNSSEC covers signing the public zone with PowerDNS and publishing the DS record at the registrar to establish the chain of trust.
Dynamic DNS covers updating the public A record automatically when the primary site’s public IP address changes, using PowerDNS’s API.
DANE covers publishing TLSA records in DNS to allow clients to verify TLS certificates independently of the public certificate authority infrastructure.
Reverse DNS covers PTR records for private IP addresses, which matters for mail server reputation scoring and for making log output readable.
Prerequisites
Three things need to be in place before the DNS articles begin.
A registered domain name. The registrar needs to support DNSSEC and allow custom nameservers. Namecheap, Gandi, and Cloudflare Registrar all support what is needed.
The MariaDB server installed on the primary server. PowerDNS uses a database backend and needs a running database before it can be configured. The MariaDB article in this series covers installation.
A static private IP address for the primary server. Assign it either as a DHCP reservation at the router or configured statically on the server. A DNS server whose own address changes is a problem that is annoying to diagnose.