Multi-server management
One of the core features that sets PDNS Manager apart from the typical "one panel, one server" tools: you can manage any number of PowerDNS Authoritative servers from the same panel. Whether they share a database, are a master/slave pair, or are completely separate setups in different datacenters.
What it looks like in the panel
Under Settings → DNS servers you find the list of registered servers. Per entry:
- Name – free display name, shown as a badge throughout the UI.
- URL – HTTP API endpoint (typically
http://<host>:8081). - API key – same value as in
pdns.conf, encrypted at rest. - Writable? Off = treated as a pure read replica.
How the manager handles multiple servers
On reads: merged view
The zone list, global search and dashboard query all registered servers in parallel. Identical zones are merged into one row. The servers carrying the zone show as small badges next to it:
example.com. master-fra1 master-ams1 replica-fra2
internal.lan. master-fra1
secret.example.com. master-ams1 Clicking a zone takes you to a writable server automatically – if one exists. If only read-only ones host the zone, you land in the read-only view.
On writes: fan-out
Since v2.3.7 record writes (POST, PUT, DELETE, bulk) are applied automatically to all servers that satisfy both:
allow_writes = true- The zone exists on the server.
Read-only servers are hard-rejected (HTTP 403) instead of silently skipped, so configuration mistakes show up immediately.
Common topologies
1 · Multiple authoritative servers on one shared DB
Classic HA: two or more PowerDNS containers/VMs talk to the same MariaDB cluster via the gmysql backend. Mark exactly one as writable in the panel; the rest are read replicas. That prevents the same write going through gmysql twice.
2 · Master + AXFR slaves
Classic. Only the master is registered in the panel, or the slaves are added as read-only so they show up on the dashboard. NOTIFY runs natively in PowerDNS.
3 · Multiple independent setups
"Internal DNS" and "external DNS" on different server pairs. Both registered, both writable – they just don't share zones. The dashboard merges sensibly anyway.
Connection test per server
Each server entry has a Test connection button. It sends GET to /api/v1/servers on the PowerDNS API and reports:
- Reachable (HTTP 200) → green, statistics shown.
- HTTP 401 → wrong API key.
- HTTP 5xx → PowerDNS responded but is broken – detail in the backend log.
- Timeout / Connection refused → network or webserver config in
pdns.conf.
Reveal API key
The configured API key is encrypted in the DB. Admins can fetch it once via API:
curl -X GET "https://pdns.example.com/api/v1/settings/servers/3/api-key" \
-H "Authorization: Bearer dnsmgr_usr_..." This action is logged with action=REVEAL_API_KEY in the audit log, so it's traceable.