How PowerDNS differs from file-based DNS servers

BIND 9 keeps each zone in a separate text file — see the article on running an authoritative server on BIND 9. PowerDNS Authoritative Server works differently: zones and records live in a relational database — MySQL, PostgreSQL, or SQLite. That is convenient when there are thousands of zones managed not by an administrator by hand, but by a hosting panel or billing system through SQL queries or a REST API.

The second difference is a built-in HTTP API that lets you create zones and records programmatically, without editing files and without an rndc reload.

Installing PowerDNS with a MySQL backend

On Debian or Ubuntu the packages install like this:

sudo apt update
sudo apt install pdns-server pdns-backend-mysql -y

The database connection is described in /etc/powerdns/pdns.conf:

launch=gmysql
gmysql-host=localhost
gmysql-dbname=pdns
gmysql-user=pdns
gmysql-password=CHANGE_ME

The table schema comes from a ready-made SQL script in the pdns-backend-mysql package, after which the service starts with systemctl restart pdns.

Creating a zone with pdnsutil

The most convenient way to manage zones from the command line is the pdnsutil tool:

pdnsutil create-zone example.com ns1.example.com
pdnsutil add-record example.com www A 3600 203.0.113.10
pdnsutil add-record example.com @ MX 3600 "10 mail.example.com."

Every command writes straight to the database — there is no separate zone reload, PowerDNS reads the current data on the next query.

Managing records through the REST API

For automation, enable the API web server in pdns.conf:

api=yes
api-key=CHANGE_ME
webserver=yes
webserver-address=127.0.0.1
webserver-port=8081

After a restart, a zone can be created with a single request:

curl -X POST http://127.0.0.1:8081/api/v1/servers/localhost/zones \
  -H "X-API-Key: CHANGE_ME" \
  -H "Content-Type: application/json" \
  -d '{"name":"example.com.","kind":"Native"}'

This approach is used by hosting control panels that create a zone automatically at the moment a domain is ordered, with no manual administrator involvement.

The GeoIP backend for geo-balancing

The geoip module lets PowerDNS return different IP addresses depending on the resolver's country or continent — exactly the task covered in the article on Anycast and GeoDNS. The backend is enabled with a second launch line and a pointer to the GeoIP database:

launch+=geoip
geoip-database-files=/usr/share/GeoIP/GeoLite2-City.mmdb

The region-to-answer rules are then described in a separate YAML zone file for the geoip backend, which PowerDNS reads when the service starts.

Checking and monitoring the service

The service status itself is checked through the control socket:

pdns_control ping
dig @127.0.0.1 example.com A +short

If there is no answer, check the service log and the database access permissions. For an external check of the published zone and its serial number, use the methods from the article on dig, dnsviz, and common mistakes. It is also worth enabling a DNSSEC signature for the zone with pdnsutil secure-zone if security policy requires it — general principles are described in the article on configuring DNSSEC.

Summary: a checklist for launching PowerDNS

The database schema is created, the pdns service connects to MySQL and starts with no errors in the log.
Zones are created through pdnsutil or the API, not by editing SQL tables by hand.
API access is limited to a local address or VPN, and the api-key is not stored in a public repository.
The GeoIP database is updated regularly, otherwise geo policies start serving outdated regions.

PowerDNS: Zones in a Database and API Management