PowerDNS Authoritative Server packaged by Azorian Solutions

The PowerDNS Authoritative Server is the only solution that enables authoritative DNS service from all major databases, including but not limited to MySQL, PostgresSQL, SQLite3, Microsoft SQL Server, LDAP, plain text files, and many other SQL databases via ODBC.

DNS answers can also be fully scripted using a variety of (scripting) languages such as Lua, Java, Perl, Python, Ruby, C and C++. Such scripting can be used for dynamic redirection, (spam) filtering or real time intervention.

In addition, the PowerDNS Authoritative Server is the leading DNSSEC implementation, hosting the majority of all DNSSEC domains worldwide. The Authoritative Server hosts at least 30% of all domain names in Europe, and around 90% of all DNSSEC domains in Europe.

PowerDNS Authoritative Server Website

PowerDNS Authoritative Server Documentation

Quick reference

• Maintained by: Azorian Solutions
• Github: https://github.com/AzorianSolutions/docker-powerdns-nameserver
• Website: https://azorian.solutions

TL;DR

docker run -d -p 12053:53/udp -p 12053:53 -e PDNS_local_address=0.0.0.0 azoriansolutions/powerdns-nameserver

Azorian Solutions Docker image strategy

The goal of creating this image and others alike is to provide a fairly uniform and turn-key implementation for a chosen set of products and solutions. By compiling the server binaries from source code, a greater chain of security is maintained by eliminating unnecessary trusts. This approach also helps assure support of specific features that may otherwise vary from distribution to distribution.

All documentation will be written with the assumption that you are already reasonably familiar with this ecosystem. This includes container concepts, the Docker ecosystem, and more specifically the product or solution that you are deploying. Simply put, I won't be fluffing the docs with content explaining every detail of what is presented.

Additional features

When building this image, support for the following features have been compiled into the server binaries.

• OpenSSL ecdsa
• ed25519
• ed448
• Lua (luajit)
• Lua records
• SNMP
• libsodium

Supported tags

* denotes an image that is planned but has not yet been released.

Alpine Linux

• 4.8.3, 4.8.3-alpine, 4.8.3-alpine-3.19, alpine, latest
• 4.8.3-mysql, 4.8.3-alpine-mysql, 4.8.3-alpine-3.19-mysql, alpine-mysql, mysql
• *4.8.3-pgsql, 4.8.3-alpine-pgsql, 4.8.3-alpine-3.19-pgsql, alpine-pgsql, pgsql
• *4.8.3-sqlite, 4.8.3-alpine-sqlite, 4.8.3-alpine-3.19-sqlite, alpine-sqlite, sqlite
• *4.8.3-odbc, 4.8.3-alpine-odbc, 4.8.3-alpine-3.19-odbc, alpine-odbc, odbc

Deploying this image

Server configuration

Configuration of the PowerDNS authoritative server may be achieved through two approaches. With either approach you choose, you will need to be aware of the various settings available for the server.

PowerDNS Authoritative Server Settings

Approach #1

You may pass PowerDNS authoritative server conf file options as environment variables to the container. These environment variables will be automatically inserted into the /etc/pdns/pdns.conf file. Any environment variable that begins with "PDNS_" will be converted into the proper format for insertion into the primary server conf file.

For example, say you pass the environment variable "PDNS_local_address" with the value "0.0.0.0" to the container. This will result in the following line being added to the /etc/pdns/pdns.conf file;

local-address=0.0.0.0

If you don't want to pass sensitive information in the environment variables then support has been added for Docker Swarm secrets style support. All you have to do is add "FILE" to the end of any environment variable beginning with "AS" or "PDNS_". The content of the file will be automatically loaded into a corresponding environment variable using the same name without the "_FILE" suffix. The original environment variable with the "_FILE" suffix will be deleted. Here is an example of how you would configure the web server password using an environment variable that references a Docker Swarm secret;

PDNS_webserver_password_FILE=/run/secrets/SECRET-NAME

This would result in the following line being added to the /etc/pdns/pdns.conf file;

webserver-password=CONTENTS_OF_SECRET_FILE

Approach #2

With this approach, you may create traditional PowerDNS authoritative server conf files and map them to a specific location inside the container. This will cause each mapped configuration file to be loaded each time the container is started. For example, say your Docker / Podman host has a PowerDNS authoritative server conf file stored at /srv/pdns-server.conf and you want to load that in your PowerDNS authoritative server container. You will create a volume mapping that will link the conf file on the host to a specific location in the container. The mapping would look something like this;

/srv/pdns-server.conf:/etc/pdns/pdns.conf

Deploy with Docker Run

To run a simple container on Docker with this image, execute the following Docker command;

docker run -d -p 12053:53/udp -p 12053:53 -e PDNS_local_address=0.0.0.0 azoriansolutions/powerdns-nameserver

If all goes well and the container starts, you should now be able to query this DNS authoritative server using dig;

dig -p 12053 @IP-OR-HOSTNAME-OF-DOCKER-HOST a docker.com

Since there will be no domains setup by default, you should expect the aforementioned dig test to receive a REFUSED response for any query you send.

Deploy with Docker Compose

To run this image using Docker Compose, create a YAML file with a name and place of your choosing and add the following contents to it;

version: "3.3"
services:
  nameserver:
    image: azoriansolutions/powerdns-nameserver
    restart: unless-stopped
    environment:
      - PDNS_local_address=0.0.0.0
    ports:
      - "12053:53/udp"
      - "12053:53"

Then execute the following Docker Compose command;

docker-compose -u /path/to/yaml/file.yml

Building this image

If you want to build this image yourself, you can easily do so using the build-release command I have included.

The build-release command has the following parameter format;

build-release IMAGE_TAG_NAME PDNS_VERSION DISTRO_REPO_NAME DISTRO_TAG

So for example, to build the PowerDNS authoritative server version 4.8.3 on Alpine Linux 3.19, you would execute the following shell command:

build-release 4.8.3-alpine-3.19 4.8.3 alpine 3.19

The build-release command assumes the following parameter defaults;

• Image Tag Name: latest
• PDNS Version: 4.8.3
• Distro Name: alpine
• Distro Tag: 3.19

This means that running the build-release command with no parameters would be the equivalent of executing the following shell command:

build-release latest 4.8.3 alpine 3.19

When the image is tagged during compilation, the repository portion of the image tag is derived from the contents of the .as/docker-registry file and the tag from the first parameter provided to the build-release command.