Blogs

Sensson/powerdns – Puppet Forge

Posted on by admin

<img src="https://github.com/sensson/puppet-powerdns/workflows/CI/badge.svg" 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.

Examples

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 => ‘127.0.0.1’, } powerdns::config { ‘resource-local-address’: type => ‘recursor’, setting => ‘local-address’, value => ‘127.0.0.2’, } class { ‘powerdns’: db_password => ‘s0m4r4nd0mp4ssw0rd’, db_root_password => ‘v3rys3c4r3’, recursor => true, }

Zones

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:’example.com’:10.0.0.1 ‘foo’:192.168.1.1 # recurring queries ‘+.’: 1.1.1.1;8.8.8.8;8.8.4.4

Backends

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 ‘example.org’ using: powerdns_zone{‘example.org’: }

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{‘example.org’: 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 => ‘example.org’, rname => ‘.’, # a dot takes the target_zone only as rname rtype => ‘NS’, rttl => ‘4242’, rcontent => ‘ns1.example.org.’ # Pay attention to the period at the end! } powerdns_record{‘ns1.example.org’: rcontent => ‘127.0.0.1’, } powerdns_record{‘ipv6-ns1.example.org’: target_zone => ‘example.org’, rname => ‘ns1’, # for the full record, the target_zone will be modified rtype => ‘AAAA’, rcontent => ‘::1’, } powerdns_record{‘www-server’: target_zone => ‘example.org’, rname => ‘www’, rcontent => ‘127.0.0.1’ }

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

Secrets

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.

PowerDNS

Benchmarks

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.

recursor

Install the PowerDNS recursor. The default value is false.

backend

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

backend_install

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.

backend_create_tables

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.

db_root_password

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

db_username

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

db_password

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

db_name

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

db_host

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

db_port

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

db_file

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

ldap_host

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

ldap_basedn

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

ldap_method

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

ldap_binddn

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

ldap_secret

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

custom_repo

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

custom_epel

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

version

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

mysql_schema_file

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

pgsql_schema_file

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

powerdns::authoritative and powerdns::recursor

package_ensure

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

Define

powerdns::config All PowerDNS configurations can be managed with

powerdns

:

: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’, }

setting

The settings you want to change. value The

value

of the previous setting

.

scribe

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’.

Hiera

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: ‘127.0.0.1’ api: value: ‘yes’

Prevent declaration

duplicate In this example, we set local-address to 127.0.0.1. 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: ‘127.0.0.1’ powerdns::resource::config: local-address-recursor: setting: ‘local-address’ value: ‘127.0.0.2’

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.

Limitations

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. .

  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 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

acceptance

tests

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.

admin