“Just use Cloudflare” is not wrong, exactly. It is incomplete. The advice treats DNS as a software decision when it is really a labor decision. PowerDNS is a fine authoritative server, and installing it takes minutes. The costs that the advice ignores are the obligations that come with being the authoritative source for a zone — obligations that a managed provider absorbs on your behalf, and that you inherit the moment you point a delegation at your own nameservers.
This is a cost-accounting exercise for the operator running one to ten machines. Not a takedown of managed DNS, and not a claim that self-hosting is reckless. The question is which obligations you are choosing to own, and whether you can staff them.
The software is the cheap part
PowerDNS Authoritative is one package plus a backend. The project supports a range of backends, from database backends such as MySQL and PostgreSQL to BIND zone files and JSON APIs (PowerDNS Authoritative documentation). You pick one, point launch= at it, and the daemon starts answering queries. That is the whole install.
The obligations do not come from the daemon. They come from the delegation. Once a parent zone lists your nameservers, the rest of the internet will test them, and the tests are not advisory.
What a delegation actually requires
IANA publishes the technical tests it performs for delegation changes in the zones it manages, and those tests are a useful proxy for what any registry or resolver ecosystem will expect of your nameservers (IANA, Technical requirements for authoritative name servers). The baseline is more demanding than most small operators expect:
- At least two NS records, on distinct IP addresses. The hosts must not resolve to the same IP address.
- Reachability over both UDP and TCP on port 53. Not UDP alone. TCP is tested.
- Authoritative answers with the AA bit set. Tested by querying the SOA with the RD bit clear.
- Network diversity. The nameservers must be in at least two topologically separate networks, defined as separate origin autonomous systems in the BGP routing table.
- Consistent data across servers. All authoritative nameservers must serve the same NS record set and the same SOA record for the zone.
- No open recursion. The authoritative servers must not provide recursive service.
- No prohibited networks. Addresses must not sit in private, documentation, or otherwise non-globally-routable ranges.
Read that list as a job description rather than a checklist. Two distinct IPs means two failure domains. Two autonomous systems means a second provider or a second location, not a second address on the same VPS. TCP reachability means your firewall rules and your provider’s network both have to cooperate. Consistency means you need a way to notice when the two servers disagree about the SOA serial — and a plan for what to do when they do.
The second nameserver is the largest hidden cost. It is not the price of a second VPS. It is a second patch cadence, a second set of firewall rules, a second monitoring target, and a consistency check that is easy to defer until a resolver failure or a delegation test surfaces it at the worst possible moment.
The backend is an operational decision, not a preference
PowerDNS’s backend choice looks like a matter of taste. It is not. Each backend implies a different backup and replication story, and the documentation is explicit about the constraints.
The SQLite backend is attractive for small deployments because the database is embedded in the application — no separate database server process to run, patch, and monitor (PowerDNS Generic SQLite3 backend). That removes a moving part from the stack. It also introduces a specific constraint that matters for anyone planning backups or replication by file copy:
It is not possible to replace the sqlite3 database file while PowerDNS is running. Specifically, using rsync to distribute sqlite3 databases does not work without stopping PowerDNS first and restarting it after the change.
That is a documented limitation, not folklore. If your backup plan is “rsync the database file every hour,” you have a plan that either corrupts the database or silently serves stale data. The correct plan involves stopping the daemon, copying the file, and restarting — which means a maintenance window, however brief, and a restore procedure you have actually tested. A database backend such as PostgreSQL moves the problem rather than solving it: now you have a database server to back up, replicate, and patch, plus the PowerDNS schema on top of it.
Neither choice is wrong. The point is that the backend decision determines what your backup and replication obligations look like, and that decision is usually made in five minutes during installation and then lived with for years.
DNSSEC is a calendar item, not a checkbox
PowerDNS makes zone signing look trivial, and the documentation says so directly: securing an existing zone can be as simple as pdnsutil zone secure example.org (or secure-zone prior to version 5.0) (PowerDNS DNSSEC documentation). That command is the easy part.
PowerDNS treats DNS data and DNSSEC keys and signatures as separate entities, storing keying material separately from record storage. That separation is good design — it lets you focus on keeping zone data correct — but it also means the key material is a second thing to back up, and a second thing to reason about during a restore.
The parts that need an owner and a reminder are the ones outside the daemon:
- The DS record at the parent. Signing the zone locally does nothing for validation until the parent publishes a DS record that matches a DNSKEY in your zone. IANA’s tests require that a DNSKEY matching each DS record be present in the child zone at the time of the listing request. Get this wrong during a key change and your zone goes bogus for every validating resolver.
- Key rollover. PowerDNS documents the phases for KSK, ZSK, and algorithm rollover, including the DS change phase for KSK rollover. Each phase has a waiting period tied to TTLs and propagation. This is a sequence of steps spread over days or weeks, not a single command.
- Signature freshness. Signatures expire. If the signing process stops — a crashed daemon, a full disk, a botched upgrade — the zone continues to answer, and validating resolvers continue to reject it. The failure is silent from the perspective of a non-validating client.
The single-command signing is real. The lifecycle around it is the cost. Budget it as a recurring calendar item with a named owner, not as a one-time setup task.
The cost ledger
Here is the honest comparison, framed as obligations rather than features. A managed DNS provider is largely selling operational labor: anycast across many networks, DNSSEC DS handling through a web interface, monitoring, and the on-call rotation behind it. When you self-host, you are not replacing that labor with software. You are absorbing it.
| Obligation | Managed provider | Self-hosted PowerDNS |
|---|---|---|
| Second network / autonomous system | Included by design | You provision and pay for it |
| UDP and TCP on port 53 | Included | Your firewall and provider must allow it |
| Zone consistency across servers | Internal | You monitor and reconcile |
| DNSSEC DS publication | Web interface | Registrar interaction, timing-sensitive |
| Key rollover calendar | Handled | Yours, with phases and waiting periods |
| Backend backup and restore | Internal | Yours, with documented constraints |
| Patch cadence | Provider’s | Yours, on every server |
| Monitoring and alerting | Provider’s | Yours, including DNSSEC validity |
None of this argues against self-hosting. It argues against self-hosting without counting the rows. The operator who installs PowerDNS on one VPS, points a delegation at it, and enables DNSSEC in an afternoon has not finished the project. They have started it.
A decision rule for the one-to-ten-machine operator
Self-host authoritative DNS when you want direct control over zone data, when you can name the second network your second nameserver lives in, and when you can staff the DNSSEC calendar. The control is real: your zone file is yours, your API is yours, and no provider’s policy change can alter your records.
Choose the managed option when you cannot answer those questions. Not because managed DNS is technically superior — it is not, in any way that matters for a small zone — but because you are buying operational labor you have not yet staffed. That is a legitimate purchase.
A useful test before you commit: can you describe, without looking it up, how you would notice if your two authoritative servers disagreed about the SOA serial? Can you name the autonomous system your second nameserver sits in? If either answer is no, the managed option is buying you time, not just convenience. Take the time, build the second location and the rollover calendar, and then migrate. The zone will still be there.
Questions that come up
Can I run both nameservers on the same VPS with two IP addresses?
Two IPs on one host satisfy the “distinct IP” test but not the network-diversity test. IANA defines diversity by origin autonomous system, and two addresses on one VPS are almost always in the same AS. Whether a specific provider’s layout passes is something you have to verify against the BGP table, not assume.
Is SQLite good enough for a small zone?
Yes, with the documented caveat. The SQLite backend is embedded and removes a database server from the stack. The constraint is that the database file cannot be replaced while PowerDNS is running, so any backup or replication plan built on file copying must be designed around a stop-copy-restart sequence rather than live rsync.
Does enabling DNSSEC require action at my registrar?
Yes. Signing the zone locally produces DNSKEY records and signatures, but validation depends on a DS record at the parent. IANA’s tests require a matching DNSKEY in the child zone at the time of the listing request, which means the DS publication and the key state have to be coordinated. This is the part that needs a calendar entry.
What happens if one nameserver goes down?
Resolvers will retry the other. That is the point of the second server. The failure mode to worry about is not a clean outage but a divergence: one server answering with a stale SOA serial while the other has the current zone. IANA’s consistency tests exist because that failure is common enough to test for, and it is the one your monitoring has to catch.