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

However, Bobs web server needs to read the private key file to utilize the SSL certificate. If it is encrypted, Bob has to either store the pass-phrase somewhere or enter it by hand every time he starts the web server. If Bob uses Apache, he will get a so-called pass-phrase dialog. By default it looks like this (on the command line):

1. https-www:/etc/apache2-itk/# /etc/init.d/apache2-itk start
2. Some of your private key files are encrypted for security reasons.
3. In order to read them you have to provide the pass phrases.
5. Server secure.example.org:443 (RSA)
6. Enter pass phrase:
8. OK: Pass Phrase Dialog successful.
9. .

While entering the pass-phrase of an SSL certificate by hand is a very secure approach, it has its share of problems:

• Upon reboot of Bobs server, the web server will not start automatically. It will hang, because it waits for the pass-phrase to be entered. Likewise, if the web server is restarted automatically for some reason (e.g. by monitoring software) the web server will hang on start-up, because it waits for the pass-phrase to be entered.
• For security reasons, it is unwise to use the same pass-phrase for all private keys. Also, Bob shouldn’t use overly simple pass-phrases, that are easy to remember. If Bob needs tenths (or even hundreds) of private keys he can’t possibly remember every single pass-phrase.
• It takes some time until Bob has looked up the corresponding pass-phrase in his mind or in his secure pass-phrase store. Even if he manages to immediately know every pass-phrase in use at his web server, it takes some time until he has entered the pass-phrase.

For the sacrifice of some security, you can mitigate these issues. If you really don’t care much for security, you can either not use a pass-phrase in the first place or – if you somehow entered a pass-phrase by accident – remove the pass-phrase from the key file. To remove the pass-phrase from an RSA private key use:

1. openssl rsa -in secure.example.org-2009.key -out secure.example.org-2009.key.unprotected

If you want a somewhat more secure approach (depending on the implementation), you can check out the SSLPassPhraseDialog directive of the Apache mod_ssl module. Using this directive, you can tell Apache to ask an external script for the pass-phrase of your certificates:

1. SSLPassPhraseDialog exec:/path/to/script

Apache will supply two arguments to the script. The first argument is of the form servername:portnumber, e.g. secure.example.org:443 and the second argument is either RSA or DSA. The script would print the corresponding pass-phrase to stdout. Of course, you still need to store the pass-phrases somewhere. How much security you sacrifice using this construct depends on the implementation of your external script. But it might be a slight bit more secure than just using no pass-phrase for the private key files at all.