I’ve been doing a lot of work with and testing of the PowerDNS authoritative DNS server lately, and I must say I quickly tire at having to create new zones in its MySQL back-end database. Yes, I can and do use the PowerDNS API or nsedit for that as well as trivial shell scripts, but I remain an aficionado of command-line utilities such as cp and vi for zone file maintenance.

For some reason, and even though I describe that first in my book, I’ve been neglecting PowerDNS’ so-called bind back-end (a misnomer in my opinion; it could equally well have been called the nsd back-end in terms of the zone files it reads. :-). Configured to use the bind back-end, PowerDNS reads zone master files directly off the file system without requiring a heavy-duty relational database system.

PowerDNS with the bind back-end runs in one of two modes:

  1. a hybrid mode in which it stores DNSSEC-related configuration in a separate back-end (e.g. MySQL or PostgreSQL)
  2. a non-hybrid mode in which PowerDNS uses a compiled-in version of SQLite in which to store DNSSEC-related configuration and metadata.

I will discuss this second form as it avoids large “moving parts”, i.e. we don’t require a big relational database alongside the DNS server.

PowerDNS bind back-end

Let’s assume the following configuration in /etc/powerdns/pdns.conf:


When PowerDNS launches, it checks its configuration and loads the zones enumerated in bind-config from master zone files just like BIND and NSD do. It obtains the names and types of the zones it should serve from a named.conf - like file, but it requires only a minuscule subset of BIND’s directives. Basically the following suffices to configure one master and one slave zone.

options {
    directory "/etc/powerdns/bind";

zone "example.aa" IN {
    type master;
    file "example.aa";

zone "ww.mens.de" IN {
    type slave;
    masters {; };
    file "ww.mens.de";

PowerDNS starts up very quickly even with a very large number of zones. Slave zones are transferred in, but the file specified for the slave zone must exist and be writeable for PowerDNS or it won’t transfer (AXFR) the zone to disk but a misleading diagnostic message is logged at first try.

Furthermore, there is no need to reload the server when a zone is added or removed: simply change the file pointed to by bind-config, and PowerDNS will pick this up every bind-check-interval seconds or explictly when you invoke

pdns_control rediscover

One really brilliant feature of the PowerDNS bind back-end is, I can edit one of the zone master files on disk (vi, etc.), and PowerDNS will pick up that change within a second without me having to do anything. (It checks the file’s modification time once per second when queried for a zone and reloads it on change.)

PowerDNS has to store DNSSEC-related data and metadata for a zone somewhere; zone master files don’t cater for that. In particular the keys (respectively pointers to keys on a HSM) must be available, and the server uses the configured bind-dnssec-db for doing that. This database contains the domainmetadata, cryptokeys, and tsigkeys tables. In other words, if I create DNSSEC keys and associate those with a zone, PowerDNS looks for that data in this database which we create before first launching PowerDNS:

pdnssec create-bind-db /etc/powerdns/bind/dnssec.db

I’m fond of hand-crafting zone master files, but there are cases in which automation is necessary. Unfortunately, the bind back-end has neither support for RFC 2136 dynamic updates (even though PowerDNS has this for some back-ends), nor does it support the REST API. (I thought I could lure one of the developers to bite, but my feeble attempt at an April fool’s joke wasn’t taken seriously … even though I think having both these features in the bind back-end a very good idea. ;-)

In short: on the plus side:

  • Fewer moving parts (no relational database management system)
  • Fast
  • Zone master files are immediately reloaded when modified
  • DNSSEC support
  • Did I say “fast”?

On the minus side:

  • Neither the PowerDNS REST API (which is built-in to the server so it could be utilized) nor, and this is very minus, RFC 2136 updates which the server is also capable of doing.
  • Incoming AXFR fails if the zone file doesn’t exist; the server could, permissions permitting, create this itself.

All in all, this combination could become one of my favorites…

DNS, PowerDNS, and BIND :: 02 Apr 2015 :: e-mail