Forge Home


A module to install and configure PowerDNS 4.x authoritative server and recursor


111 latest version

Version information

  • 3.0.3 (latest)
  • 3.0.2
  • 3.0.0
  • 2.3.0
  • 2.2.2
  • 2.2.1
  • 2.1.5
  • 2.1.4
  • 2.1.3
  • 2.1.2
  • 2.1.1
  • 2.0.0
  • 1.7.2
  • 1.7.1
  • 1.7.0
  • 1.6.1
  • 1.6.0
  • 1.5.0
  • 1.4.0
  • 1.3.0
  • 1.2.3
  • 1.2.2
  • 1.2.1 (deleted)
  • 1.1.0
  • 1.0.1
  • 1.0.0
  • 0.0.12
  • 0.0.11
  • 0.0.10
  • 0.0.9 (deleted)
  • 0.0.8
  • 0.0.7
  • 0.0.6
  • 0.0.5
  • 0.0.4
  • 0.0.3
  • 0.0.2
  • 0.0.1
released May 27th 2023
This version is compatible with:
  • Puppet Enterprise 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x
  • Puppet >= 7.0.0 < 8.0.0
  • , , , , ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'sensson-powerdns', '3.0.3'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add sensson-powerdns
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install sensson-powerdns --version 3.0.3

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Tags: powerdns


sensson/powerdns — version 3.0.3 May 27th 2023


Build Status Puppet Forge

This module can be used to configure both the recursor and authoritative PowerDNS 4 server. It officially supports Puppet 7 and higher.


Installation and configuration

This will install the authoritative PowerDNS server which includes the MySQL server and the management of the database and its tables. This is the bare minimum.

class { 'powerdns':
  db_password      => 's0m4r4nd0mp4ssw0rd',
  db_root_password => 'v3rys3c4r3',

If you want to install both the recursor and the authoritative service on the same server it is recommended to have the services listen on their own IP address. The example below needs to be adjusted to use the ip addresses of your server.

This may fail the first time on Debian-based distro's.

powerdns::config { 'authoritative-local-address':
  type    => 'authoritative',
  setting => 'local-address',
  value   => '',
powerdns::config { 'recursor-local-address':
  type    => 'recursor',
  setting => 'local-address',
  value   => '',
class { 'powerdns':
  db_password      => 's0m4r4nd0mp4ssw0rd',
  db_root_password => 'v3rys3c4r3',
  recursor         => true,

Recursor forward zones

Multiple forward zones can be configured using powerdns::forward_zones.

include powerdns::recursor

The configuration will be serialized into forward-zones-file config file.

   # recurse queries


The default backend is MySQL. It also comes with support for PostgreSQL, Bind, LDAP and SQLite.

If you don't specify the backend it assumes you will use MySQL.

class { 'powerdns':
  backend     => 'mysql',
  db_password => 's0m4r4nd0mp4ssw0rd',

To use PostgreSQL set backend to postgresql.

class { 'powerdns':
  backend     => 'postgresql',
  db_password => 's0m4r4nd0mp4ssw0rd',

To use Bind you must set backend_install and backend_create_tables to false. For example:

class { 'powerdns':
  backend               => 'bind',
  backend_install       => false,
  backend_create_tables => false,

To use LDAP you must set backend_install and backend_create_tables to false. For example:

class { 'powerdns':
  backend               => 'ldap',
  backend_install       => false,
  backend_create_tables => false,

To use SQLite you must set backend to sqlite. Ensure that the pdns user has write permissions to directory holding database file. For example:

class { 'powerdns':
  backend => 'sqlite',
  db_file => '/opt/powerdns.sqlite3',

Manage zones with this module

With this module you can manage zones if you use a backend that is capable of doing so (eg. sqllite, postgres or mysql).

You can add a zone '' by using:

 powerdns_zone{'': }

This will add the zone which is then managed through puppet any records not added through puppet will be deleted additionaly a SOA record is generated. To just ensure the zone is available, but not manage any records use (and do not add any powerdns_record resources with target this domain):

   manage_records => false,

To addjust the SOA record (if add_soa is set to true), use the soa_* parameters documented in the powerdns_record resource.

The zone records can be managed through the powerdns_record resource. As an example we add a NS an A and an AAAA record:

   target_zone => '',
   rname       => '.',  # a dot takes the target_zone only as rname
   rtype       => 'NS',
   rttl        => '4242',
   rcontent    => '' # pay attention to the dot at the end !
   rcontent => '',
   target_zone => '',
   rname       => 'ns1',  # for the full record, the target_zone will be amended
   rtype       => 'AAAA',
   rcontent    => '::1',
   target_zone => '',
   rname       => 'www',
   rcontent    => ''

Remark: if the target_zone is not managed with powerdns_zone resource, powerdns_record does not change anything!

Sensitive secrets

Passwords can be passed either as plain-text strings or as Puppet's Sensitive type when appropriate encrypted backend is configured on Puppet server.




We provide a number of configuration options to change particular settings or to override our defaults when required.


Install the PowerDNS authoritative server. Defaults to true.


Install the PowerDNS recursor. Defaults to false.


Choose a backend for the authoritative server. Valid values are 'mysql', 'postgresql' and 'bind'. Defaults to 'mysql'.


If you set this to true it will try to install a database backend for you. This requires db_root_password. Defaults to true.


If set to true, it will ensure the required powerdns tables exist in your backend database. If your database is on a separate host or you are using the the Bind backend, set backend_install and backend_create_tables to false. Defaults to true.


If you set backend_install to true you are asked to specify a root password for your database. Accepts either String or Sensitive type.


Set the database username. Defaults to 'powerdns'.


Set the database password. Accepts either String or Sensitive type. Default is empty.


The database you want to use for PowerDNS. Defaults to 'powerdns'.


The host where your database should be created. Defaults to 'localhost'.


The port to use when connecting to your database. Defaults to '3306'. Only supported in the MySQL backend currently.


The file where database will be stored when using SQLite backend. Defaults to '/var/lib/powerdns/powerdns.sqlite3'


The host where your LDAP server can be found. Defaults to 'ldap://localhost/'.


The path to search for in LDAP. Defaults to undef.


Defines how LDAP is queried. Defaults to 'strict'.


Path to the object to authenticate against. Defaults to undef.


Password for simple authentication against ldap_basedn. Accepts either String or Sensitive type. Defaults to undef.


Don't manage the PowerDNS repo with this module. Defaults to false.


Don't manage the EPEL repo with this module. Defaults to false.


Set the PowerDNS version. Defaults to '4.1'.


Set the PowerDNS MySQL schema file. Defaults to the location provided by PowerDNS.


Set the PowerDNS PostgreSQL schema file. Defaults to the location provided by PowerDNS.

powerdns::authoritative and powerdns::recursor


You can set the package version to be installed. Defaults to 'installed'.



All PowerDNS settings can be managed with powerdns::config. Depending on the backend we will set a few configuration settings by default. All other variables can be changed as follows:

powerdns::config { 'api':
  ensure  => present,
  setting => 'api',
  value   => 'yes',
  type    => 'authoritative',

The setting you want to change.


The value for the above setting.


The configuration file you want to change. Valid values are 'authoritative', 'recursor'. Defaults to 'authoritative'.


Specify whether or not this configuration should be present. Valid values are 'present', 'absent'. Defaults to 'present'.


This module supports Hiera and uses create_resources to configure PowerDNS if you want to. An example can be found below:

powerdns::db_root_password: 's0m4r4nd0mp4ssw0rd'
powerdns::db_username: 'powerdns'
powerdns::db_password: 's0m4r4nd0mp4ssw0rd'
powerdns::recursor: true
powerdns::recursor::package_ensure: 'latest'
powerdns::authoritative::package_ensure: 'latest'

    value: ''
    value: ''
    value: 'yes'

Prevent duplicate declaration

In this example we configure local-address to If you also run a recursor on the same server and you would like to configure local-address via Hiera you need to set setting and change the name of the parameter in Hiera to a unique value.

For example:

    setting: 'local-address'
    value: ''
    setting: 'local-address'
    value: ''

If you have other settings that share the same name between the recursor and authoritative server you would have to use the same approach to prevent duplicate declaration errors.


This module has been tested on:

  • CentOS 6, 7, 8
  • Ubuntu 14.04, 16.04, 18.04
  • Debian 8, 9

We believe it also on other operating systems such as:

  • Oracle Linux
  • RedHat Enterprise Linux
  • Scientific Linux


We strongly believe in the power of open source. This module is our way of saying thanks.

If you want to contribute please:

  1. Fork the repository.
  2. Run tests. It's always good to know that you can start with a clean slate.
  3. Add a test for your change.
  4. Make sure it passes.
  5. Push to your fork and submit a pull request to the main branch.

We can only accept pull requests with passing tests.

To install all of its dependencies please run:

bundle install --path vendor/bundle --without development

Running unit tests

bundle exec rake test

Running acceptance tests

The unit tests only verify if the code runs, not if it does exactly what we want on a real machine. For this we use Beaker. Beaker will start a new virtual machine (using Vagrant) and runs a series of simple tests.

You can run Beaker tests with:

bundle exec rake spec_prep
BEAKER_destroy=onpass bundle exec rake beaker:centos6
BEAKER_destroy=onpass bundle exec rake beaker:centos7
BEAKER_destroy=onpass bundle exec rake beaker:oel7
BEAKER_destroy=onpass bundle exec rake beaker:ubuntu1404
BEAKER_destroy=onpass bundle exec rake beaker:ubuntu1604
BEAKER_destroy=onpass BEAKER_PUPPET_COLLECTION=puppet5 bundle exec rake beaker:ubuntu1804
BEAKER_destroy=onpass bundle exec rake beaker:debian8
BEAKER_destroy=onpass bundle exec rake beaker:debian9

We recommend specifying BEAKER_destroy=onpass as it will keep the Vagrant machine running in case something fails.