Sensson/powerdns – Puppet Forge

<img src="" alt="Build status" /

> Puppet Forge

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


Installation and configuration

This will install the authoritative PowerDNS server which includes the MySQL server and the administration of the database and its tables. This is the 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 that the services listen on their own IP address. The following example should be adjusted to use your server’s IP addresses.

This may fail the first time in Debian-based distributions.

PowerDNS::config { ‘authoritative-local-address’: type => ‘authoritative’, setting => ‘local-address’, value => ‘’, } powerdns::config { ‘resource-local-address’: type => ‘recursor’, setting => ‘local-address’, value => ‘’, } class { ‘powerdns’: db_password => ‘s0m4r4nd0mp4ssw0rd’, db_root_password => ‘v3rys3c4r3’, recursor => true, }


recursor forwarding Multiple forwarding zones can be configured using powerdns::forward_zones.

include powerdns::recursor

The configuration will be serialized into the forward-zones-file configuration file

. powerdns::forward_zones:’’: ‘foo’: # recurring queries ‘+.’:;;


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

If you don’t specify the backend, assume you’ll be using 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. Make sure that the pdns user has write permissions to the database file that contains directories. 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 (for example, sqllite, postgres, or mysql).

You can add a

zone ‘’ using: powerdns_zone{‘’: }

This will add the zone that is then managed through puppet, any records that are not added through puppet will be additionally deleted, and an SOA record will be generated. To ensure that the zone is available, but not to manage any records, use (and do not add any powerdns_record resources that target this domain):

powerdns_zone{‘’: manage_records => false, }

To add only the SOA record (if add_soa is set to true), use the soa_* parameters documented in the

powerdns_record resource.

Zone records can be managed through the powerdns_record resource. As an example, we add an NS an A record and a YYYY

: powerdns_record{‘nameserver1’: target_zone => ‘’, rname => ‘.’, # a dot takes the target_zone only as rname rtype => ‘NS’, rttl => ‘4242’, rcontent => ‘’ # Pay attention to the period at the end! } powerdns_record{‘’: rcontent => ‘’, } powerdns_record{‘’: target_zone => ‘’, rname => ‘ns1’, # for the full record, the target_zone will be modified rtype => ‘AAAA’, rcontent => ‘::1’, } powerdns_record{‘www-server’: target_zone => ‘’, rname => ‘www’, rcontent => ‘’ }

Remark: If the target_zone is not managed with powerdns_zone resource, powerdns_record nothing changes!


Sensitive passwords can be passed as plaintext strings or as a sensitive Puppet type when the appropriate encrypted backend is configured on the Puppet server.



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

. authoritative Install the authoritative

PowerDNS server. The default value is true.


Install the PowerDNS recursor. The default value is false.


Choose a backend for the authoritative server. Valid values are ‘mysql’, ‘postgresql’ and ‘bind’. The default value is ‘mysql’.


If you set this to true, it will attempt to install a database backend for you. This requires db_root_password. The default value is true.


Setting true will ensure that the required powerdns tables exist in the back-end database. If the database is on a separate host or you are using the bind backend, set backend_install and backend_create_tables to false. The default value is true.


If you set backend_install to true, you are prompted to specify a root password for the database. Accepts the String or Sensitive type.


Set the database user name. The default value is ‘powerdns’.


Set the database password. Accepts the String or Sensitive type. The default value is empty.


The database that you want to use for PowerDNS. The default value is ‘powerdns’.


The host where the database should be created. The default value is ‘localhost’.


The port to use when connecting to the database. The default value is ‘3306’. It is only supported on the MySQL backend currently.


The file where the database will be stored when using the SQLite backend. The default value is ‘/var/lib/powerdns/powerdns.sqlite3’


The host where the LDAP server is located. The default value is ‘ldap://localhost/’.


The path to search for in LDAP. The default value is undef.


Defines how LDAP is queried. The default value is ‘strict’.


The path to the object to authenticate with. The default value is undef.


Password for simple authentication against ldap_basedn. Accepts the String or Sensitive type. The default value is undef.


Do not manage the PowerDNS repository with this module. The default value is false.


Do not manage the EPEL repository with this module. The default value is false.


Set the version of PowerDNS. The default value is ‘4.1’.


Set the PowerDNS MySQL schema file. The default value is the location provided by PowerDNS.


Set the PowerDNS PostgreSQL schema file. The default value is the location provided by PowerDNS.

powerdns::authoritative and powerdns::recursor


You can set the version of the package to install. The default value is ‘installed’.


powerdns::config All PowerDNS configurations can be managed with



:config. Depending on the backend we will set some default configuration settings. All other variables can be changed as follows

: powerdns::config { ‘api’: ensure => present, setting => ‘api’, value => ‘yes’, type => ‘authoritative’, }


The settings you want to change. value The


of the previous setting



The configuration file

you want to change


Valid values are ‘authoritative’, ‘resourcer’. The default value is ‘authoritative’.

Make sure to Specify

whether this setting should be present or not. Valid values are ‘present’, ‘away’. The default value is ‘present’.


This module is compatible with Hiera and uses create_resources to configure PowerDNS if desired. An example can be found below

: powerdns::d b_root_password: ‘s0m4r4nd0mp4ssw0rd’ powerdns::d b_username: ‘powerdns’ powerdns::d b_password: ‘s0m4r4nd0mp4ssw0rd’ powerdns::resource: true powerdns::resource::p ackage_ensure: ‘latest’ powerdns::authoritative::p ackage_ensure: ‘latest’ powerdns::auth::config: gmysql-dnssec: value: ” local-address: value: ‘’ api: value: ‘yes’

Prevent declaration

duplicate In this example, we set local-address to If you also run a recursor on the same server and want to configure the local address through Hiera, you must configure the settings and rename the parameter in Hiera to a unique value.

For example

: powerdns::auth::config: local-address-auth: setting: ‘local-address’ value: ‘’ powerdns::resource::config: local-address-recursor: setting: ‘local-address’ value: ‘’

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


This module has been tested on:

  • CentOS 6, 7
  • , 8 Ubuntu 14.04,

  • 16.04, 18.04
  • Debian 8, 9

We also believe it in other operating systems such as:

  • Oracle
  • Linux

  • RedHat Enterprise
  • Linux Scientific Linux Linux Development

We strongly believe in the power of

open source. This module is our way of saying thank you.

If you want to contribute, please:

  1. Fork the repository
  2. .

  3. Run tests. It’s always good to know that you can start with a clean slate.
  4. Add a test for your change.
  5. Make sure it passes.
  6. Push your fork and send a withdrawal request to the main branch.

We can only accept extraction requests with approved tests


To install all your dependencies, please run:

bundle install -path vendor/bundle -without development Running unit tests Exec package execution rake test Execution of



Unit tests

only check if 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 run 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 goes wrong.