By default, the web server will listen on port 8081 on localhost. That means, that you can’t view the status information from the outside network. To view the page, you could use a command line browser like lynx. You could change the interface of the web server to a public IP address, but this is very insecure and not recommended. The PowerDNS web server provides some sensitive information about your DNS server and you should not expose this information to the public. Also, the PowerDNS web server is probably not as thoroughly tested and hardened as e.g. Apache or nginx. Another problem is, that you can only specify a single password and that you are limited to basic authentication, which is not very secure.

There is a secure way to retrieve the information provided by PowerDNS from outside your DNS server host. You could use Apache, nginx or any other web server you like as a proxy server. That way you can use more advanced authentication methods built into that web server to secure your status page. I will now show you how to do this using Apache 2 on Debian. We’ll need mod_proxy, mod_proxy_http and mod_headers enabled on the Apache 2 server. If you do not want to run an instance of Apache 2 on your DNS server, you could use an SSL tunnel or a secure back channel link to a remote Apache server to retrieve the status page. But this is beyond the scope of this post.

First, enable the internal PowerDNS web server by editing the configuration file.

1. webserver=yes
2. webserver-address=127.0.0.1
3. webserver-port=8081
4. webserver-password=PowerDNS

This tells PowerDNS to run the internal web server on port 8081 of the localhost interface. The user name will be admin and the password will be PowerDNS. Of course you should change the password to something more secure, it’s just an example. After a restart of PowerDNS you can connect to your server from your DNS server host. The password is optional, but it’s safer that way, especially in an environment where you’ve got other users on your DNS server box.

Now install and enable the required modules of Apache 2 by executing the following commands.

1. apt-get install libapache2-mod-proxy-html
2. a2enmod proxy
3. a2enmod proxy_http
4. a2enmod headers

The last module is only needed, if you set a password for your internal web server as recommended above. I assume that you’ve got some kind of virtual host configuration for your Apache server. You’ll want to add a new virtual host for the DNS status information. If you use a subdirectory, navigation might be a bit odd. Let’s add a new site to the available sites.

1. vi /etc/apache2/sites-available/status.dns.example.net
2. <VirtualHost 192.168.0.1:80>
3. ServerName status.dns.example.net
4. DocumentRoot /var/www/
6. ProxyRequests Off
7. <proxy *>
8. Order deny,allow
9. Allow from all
10. ForceType 'text/html; charset=UTF-8'
11. </proxy>
12. ProxyPass / http://localhost:8081
13. ProxyPassReverse / http://localhost:8081
15. </VirtualHost>

Alright, so what are we doing here? Basically, we’re adding a new virtual host status.dns.example.net on our main interface of dns.example.net. We’re using a reverse proxy to to send all requests coming from the outside to our internal PowerDNS web server on port 8081. Also, we’re forcing a text/html content type in the proxy request filter, because otherwise we would just get text/plain and we would simply see the source code, which is probably not what you want. Let’s enable the site for a test:

1. a2ensite status.dns.example.net
2. /etc/init.d/apache2 reload

If you point your web browser to status.dns.example.net you should now see the internal status page of PowerDNS. If you set a password above, you will see a password dialogue. This is the password dialogue sent by the PowerDNS web server. The user name is admin and the password is your password. Try it out now, because we’ll get rid of this in a minute.

For security reasons, you probably want to use Apache 2 for authentication. E.g. you might want use a SSL connection and authenticate your co-workers using the internal LDAP server of your company intranet. You might even stay with the insecure basic authentication method, but use other user names. This is entirely up to you and beyond the scope of this post. Consult the Apache 2 documentation on how to do this. What you probably don’t want to do, however, is to authenticate twice (first your secure authentication method and then PowerDNS basic authentication. Luckily, we can configure the Apache 2 proxy to do the authentication for us. This is a bit tricky, though.
To authenticate at the PowerDNS server, Apache 2 needs to send an additional Authorization header line to the PowerDNS server with every request it handles. We use the RequestHeader directive to override any existing Authorization header with our own authentication data. Add the following lines just before the end of the virtual host container.

1. <Location />
2. RequestHeader Set Authorization "Basic YWRtaW46UG93ZXJETlM="
3. </Location>

The above example works only for our example password, which is PowerDNS. Try it for a test. This is, because part of the header value is encrypted using the base64 algorithm. You need to change the encrypted part YWRtaW46UG93ZXJETlM=. In plain text the encrypted string would read admin:PowerDNS, where admin is the user name and PowerDNS is the password. To use your own password, you need to encrypt the string admin:yourownpassword using the base64 algorithm and replace our example string. Be sure to keep the Basic and the space. It is crucial for success, that you’ve got the right encrypted string. There are a number of online tools, to encode and decode these strings. To ensure, that you’ve got the correct encryption method, encode the example string and compare it to the string above for a reference. If you’ve got the wrong string, it will not work.

Restart the Apache 2 server. To clear your password cache, restart your browser. Now surf to the site again. You will see, that the password dialogue is gone. Now, don’t forget to secure the page again using Apache 2. Under any circumstances, do not use Directory containers in the configuration. These will not apply to the proxy, because the proxy is not a physical directory on your server. Use Location containers like we did above for setting the RequestHeader directive. Also, you could still use insecure basic authentication to secure the page, if you wanted. It would work regardless of the RequestHeader magic.

A light-weight alternative

For those of you, who think that Apache is too heavy, here is an example for the nginx web server:

1. vi /etc/nginx/sites-available/status.dns.example.net
2. server {
3. listen 192.168.0.1:80;
4. server_name status.dns.example.net;
5. root /var/www/nginx-default;
6. location / {
7. index index.html
8. proxy_pass http://localhost:8081;
9. proxy_redirect off;
10. proxy_set_header Authorization "Basic YWRtaW46UG93ZXJETlM=";
11. }
12. }

Prerequisites

For the rest of this workshop it is assumed that you’ve got two PowerDNS installations on two separate physical hosts with the IP addresses 192.168.0.1 and 192.168.1.2, respectively. The first server has the host name dns.example.net and the second server has the host name dns2.example.net.

Configure Master and Slave

You probably want one DNS server to act as the master server and a number of additional servers to act as slaves. PowerDNS supports multiple master servers for one domain and it can be slave and master at the same time.

We will now configure dns.example.net as the master and dns2.example.net as the slave. To do this, add master to the configuration file of the first server and slave to the configuration file of the second server.

In a traditional setup, you would configure a domain name both on the master and the slave server. Additionally, you would specify record data for the domain name on the master server. The slave would then query the master server and download the record data. Whenever you change the record data on the master server, it would notify the slave server and the slave server would refresh the record data by downloading the new record data from the master server. In fact, you can do this with PowerDNS and it will work just fine. But PowerDNS can do more: If you tell your slave(s), that your master is a so-called supermaster, you do not need to setup new domain names on the slave. All you need to do is to setup the new domain name and its record data on the master server. If the domain has a SOA record and your slave is listed as one of the authoritative name servers for the domain, the master will notify your slave of the new domain name. Your slave recognizes, that your master is a supermaster server and adds the domain name to its configuration automatically. It works like magic.

To tell your slave, that your master server is a supermaster server, execute the following SQL statement on your slave’s MySQL server.

1. INSERT INTO pdns.supermasters (`ip`, `nameserver`, `account`) VALUES ('192.168.0.1', 'dns2.example.net', 'test');

This tells your slave, that your PowerDNS server with the IP address 192.168.0.1 is a supermaster server. As you will see later, PowerDNS supports the concept of accounts. These do not have any influence on the operation of PowerDNS. You can specify account information for each domain name, which might be useful, if you want to find all domain names of a certain customer. If PowerDNS sets up a new domain name of a supermaster, it uses account information specified in the supermasters table for that supermaster server. In our case, all domains of the supermaster server dns.example.net will be added with the account information test. Note, that the nameserver column of the supermasters table is not the host name of the supermaster server. It is the host name of the slave server. Before the slave adds a new domain name from our supermaster server, it checks that the host name you specify in the the nameserver column is listed as one of the authoritative DNS servers for that domain name. Thus, we need to add the name of our slave there.

Enable AXFR

To exchange domain name and record data, your PowerDNS servers will use a method that is called AXFR. For security reasons, AXFR is disabled by default. Edit the configuration files of your PowerDNS master server:

1. allow-axfr-ips=192.168.2.1
2. disable-axfr=no

This will enable AXFR for the IP address of your slave server. Do not allow AXFR for any server. This would pose a security risk. If you’ve got multiple slave servers, add all the IP addresses of the slave servers separated by a comma. AXFR is compatible with other name server software (e.g. Bind).

Running PowerDNS

PowerDNS should be in a state now, where it can start and connect to the MySQL database with no problems. For now, we will start PowerDNS in monitoring mode. That way we can follow everything that happens live on the console. To start up PowerDNS in monitoring mode, use the following command.

1. /etc/init.d/pdns monitor

Later, you may want to run PowerDNS in the background. To do this just run the following command.

1. /etc/init.d/pdns start

Once you have started up both the master and the slave PowerDNS server we can start adding domain names.

Adding your first domain name

To add a new domain name, you need to add a new entry to the domains table of your database. To do so, execute the following SQL query on the master server:

1. INSERT INTO `pdns.domains` (`id`, `name`, `type`, `account`) VALUES (1, 'example.com', 'MASTER', 'test');

This will add the example.com domain name to the database. The type MASTER indicates, that our master server will be the master for this domain. The account name is optional, it is for your information only. It is important to note, that the id of our new domain name is 1. We’ll need this in a second.

Next, we need to add some records, i.e. some zone data, to the database for PowerDNS to serve. The records need to be added to the records table of the database. PowerDNS supports a number of different records. Depending on the type of the record, you need to provide different values for the type, content and prio columns. Check the PowerDNS documentation on supported record types and their storage to get an idea of what you need. For your convenience, I’ll give you a few examples of common record types.

The first thing you want to add is a SOA record. A typical SOA record would look like this:

1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','SOA', 'dns.example.net. hostmaster.example.net. 2009042301 10800 3600 604800 3600', 3600);

Note the domain_id, which is set to the id value of our example.com domain. Then there is the fully qualified domain name, that this record is valid for. You are probably familiar with the values of the type, content and ttl columns. If not, check the documentation.

Next, let’s add a few name servers. It is important that your master and all your slaves are listed here, of course.

1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','NS', 'dns.example.net', 3600);
2. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','NS', 'dns2.example.net', 3600);

You probably want some A records:

1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','A', '192.168.0.3', 3600);
2. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'sales.example.com','A', '192.168.0.4', 3600);
3. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, '*.example.com','A', '192.168.0.2', 3600);

The first of these records is for the example.com domain name. The second is for a subdomain, i.e. sales.example.com. The third A record is special. It is a wildcard record. It matches any subdomain, that is not already specified, i.e. everything except example.com and sales.example.com.

Let’s finish by adding some MX records:

1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`, `prio`) VALUES (1, 'example.com', 'MX','mail.example.net', 3600, 10);
2. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`, `prio`) VALUES (1, 'example.com', 'MX','mailbackup.example.net', 3600, 20);

Within a short time you will see the following information showing up in the log file of your slave server. Don’t be impatient, it takes some time. You should see something within a minute, though.

1. Feb 07 21:43:26 Received NOTIFY for example.com from 192.168.0.1 for which we are not authoritative
2. Feb 07 21:43:26 Created new slave zone 'example.com' from supermaster 192.168.0.1, queued axfr
3. Feb 07 21:43:27 gmysql Connection succesful
4. Feb 07 21:43:27 No serial for 'example.com' found - zone is missing?
5. Feb 07 21:43:27 AXFR started for 'example.com', transaction started
6. Feb 07 21:43:27 AXFR done for 'example.com', zone committed

And the equivalent on the master server:

1. Feb 7 21:43:20 1 domain for which we are master needs notifications
2. Feb 7 21:43:20 Queued notification of domain 'example.com' to 192.168.1.2
3. Feb 7 21:43:21 AXFR of domain 'example.com' initiated by 192.168.1.2
4. Feb 7 21:43:21 Removed from notification list: 'example.com' to 192.168.1.2 (was acknowledged)
5. Feb 7 21:43:21 gmysql Connection succesful
6. Feb 7 21:43:21 AXFR of domain ‘example.com’ to 192.168.1.2 finished
7. Feb 7 21:43:23 No master domains need notifications

This looks like a successful AXFR of the example.com domain name. Let’s see, if the domain was really added to the MySQL database on the slave server:

1. mysql> SELECT * FROM pdns.domains WHERE name='example.com';
2. +----+--------------+---------------+------------+-------+-----------------+---------+
3. | id | name | master | last_check | type | notified_serial | account |
4. +----+--------------+---------------+------------+-------+-----------------+---------+
5. | 1 | example.com | 192.168.0.2 | 1234039407 | SLAVE | NULL | test |
6. +----+--------------+---------------+------------+-------+-----------------+---------+
7. 1 row in set (0.00 sec)

Quite cool, isn’t it? You can also query the records table. All your records will be there. Every time you add a new record and raise the serial number, PowerDNS will notify your slave and the record data will be updated automatically.

Adding slave domains

Sometimes, you might want to add a slave domain to one of your servers manually. Suppose your master server acts as a slave server for the domain example.org. Say, the master server of the example.org domain is a remote Bind server with the IP address 192.168.2.34. First, make sure that AXFR with that server is allowed (see above). Then, execute the following SQL query on your server.

1. INSERT INTO `pdns.domains` (`id`, `name`, `master`, `type`, `account`) VALUES (2, 'example.org', '192.168.2.34', 'SLAVE', 'test');

Voilà. That’s it. PowerDNS will take care of the rest.

Limitations of the supermaster mode

Unfortunately, supermaster mode is not equivalent to database synchronization. Automatic set up of new domain names and record data works like a charm. What doesn’t work, though, is the automatic deletion of domain names. If you delete your domain name on the master server, you need to delete it on all slaves manually.

Deploying PowerDNS on all our servers has a few major advantages over our current Bind based setup.

• PowerDNS has native MySQL database backend support and is therefore easier to integrate with our customer control panel. Also changes to the MySQL database are discovered automatically, eliminating the need for periodical restarts. All changes are applied almost instantly.
• PowerDNS can act as a so-called supermaster, synchronizing itsself automatically with slave servers. Zone transfers occur even without adding a domain name to all of the slaves beforehand. It is enough if the domain is added to the database of the master server.

I will now describe how to setup PowerDNS on a Linux box running Debian Woody or Debian Sarge or Debian Lenny and utilizing the MySQL database backend.

Initial Setup

Official Debian packages for PowerDNS are availlable since Debian Sarge, but you can download Woody packages from http://www.powerdns.com/downloads/, if you use Woody. There is no apt repository availlable, however.

After downloading the most recent package with wget, you can install it on your system with dpkg.

1. wget http://downloads.powerdns.com/releases/deb/stable/pdns-static_2.9.17-1_i386.deb
2. dpkg -i pdns-static_2.9.17-1*

If you’ve got a Sarge or newer installation of Debian just run apt-get as follows and the necessary packages will be installed automatically.

1. apt-get install pdns-recursor pdns-backend-mysql

You’ll notice that PowerDNS will not start up directly after installing the package. That’s because the standard configuration file does not come preconfigured for a specific backend; we have to configure PowerDNS for a backend of our choice first. See below for a sample output of a fresh PowerDNS installation.

1. /etc/init.d/pdns monitor
2. Jun 04 10:13:56 Unable to launch, no backends configured for querying.

Gerneal Settings

Before we will begin to configure the database backend, we’ll have a look at some basic settings first. If you use Sarge, you can skip this part. You will be asked for the information below during configuration of the package. If you use Lenny or Woody, you need to specify an IP address and a port, to which PowerDNS should bind. You should specify an alternate port for non-production use. That allows you to run PowerDNS in parallel to an existing nameserver installation during the initial setup period.

On Woddy and Sarge, edit /etc/powerdns/pdns.conf directly. In Lenny, do edit the file /etc/powerdns/pdns.d/pdns.local file instead. This way it will be easier to update the package later.

1. vi /etc/powerdns/pdns.d/pdns.local
2. local-address=192.168.0.2
3. local-port=5300

If you want to bind PowerDNS to multiple IP addresses change the local-address setting as follows.

1. local-address=192.168.0.2,192.168.0.3

If your server has multiple IP addresses configured, you should also set the IP address, which PowerDNS will use as the source address when sending out answers to queries from clients or remote servers.

1. query-local-address=192.168.0.2

MySQL

Before we start to configure PowerDNS to use the MySQL backend, we need to setup the required database and tables.

1. CREATE DATABASE pdns;
2. USE pdns;
4. CREATE TABLE domains (
5. id INT auto_increment,
6. name VARCHAR(255) NOT NULL,
7. master VARCHAR(20) DEFAULT NULL,
8. last_check INT DEFAULT NULL,
9. type VARCHAR(6) NOT NULL,
10. notified_serial INT DEFAULT NULL,
11. account VARCHAR(40) DEFAULT NULL,
12. primary key (id)
13. )type=InnoDB;
15. CREATE UNIQUE INDEX name_index ON domains(name);
17. CREATE TABLE records (
18. id INT auto_increment,
19. domain_id INT DEFAULT NULL,
20. name VARCHAR(255) DEFAULT NULL,
21. type VARCHAR(6) DEFAULT NULL,
22. content VARCHAR(255) DEFAULT NULL,
23. ttl INT DEFAULT NULL,
24. prio INT DEFAULT NULL,
25. change_date INT DEFAULT NULL,
26. primary key(id)
27. )type=InnoDB;
29. CREATE INDEX rec_name_index ON records(name);
30. CREATE INDEX nametype_index ON records(name,type);
31. CREATE INDEX domain_id ON records(domain_id);
33. CREATE TABLE supermasters (
34. ip VARCHAR(25) NOT NULL,
35. nameserver VARCHAR(255) NOT NULL,
36. account VARCHAR(40) DEFAULT NULL
37. );