Installing the PDNS software

Installing the package

Before we install any packages we should ensure that the correct use-flags will be used so that all required functionality is made available and unnecessary functionality is not included. The pdns package and its dependencies provide a variety of use-flags only some of which will be discussed further here. As usual feel free to add and remove use-flags at will although the minimum set which are required for using this guide in its entirety are shown below.

lisa emerge -pv pdns
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild      ] app-admin/eselect-boost-0.3
[ebuild      ] dev-util/boost-build-1.35.0-r2  USE="-python -examples"
[ebuild      ] app-admin/eselect-postgresql-0.3
[ebuild      ] dev-libs/boost-1.35.0-r5  USE="eselect python -doc -expat -icu -mpi -test -tools"
[ebuild      ] dev-db/postgresql-base-8.4.2-r1  USE="ldap nls pam readline ssl zlib -doc -kerberos -pg_legacytimestamp -threads"
[ebuild      ] virtual/postgresql-base-8.4
[ebuild      ] dev-cpp/libpqpp-4.0-r6  USE="-examples"
[ebuild      ] net-dns/pdns-2.9.20-r1  USE="ldap postgres -debug -doc -mysql -sqlite -static -tdb"

Once you are confident that the correct use-flags are set for the pdns package, and any dependencies it may require, you can proceed with the installation by issuing the emerge command shown below.

lisa emerge pdns

Installing additional tools

Although the PowerDNS package provides everything needed to run a DNS server and connect that server to a variety of back-ends it provides nothing at all in the way of DNS diagnostic tools. Thankfully the most often used of these tools, the dig application, is available in the net-dns/bind-tools package. We can install this package using the command below.

lisa emerge bind-tools

Operating System DNS resolver configuration

Now that we have merged any packages we require it is no longer imperative that the existing name resolution configuration, which is presumably in place if you have managed to reach this stage, remains correct and functional. So that we can easily test our new DNS server we shall modify the DNS resolver configuration to use our own IP address and base domain settings. To do this we firstly need to open the configuration file in an editor as shown below.

lisa nano -w /etc/resolv.conf

You will probably see something which looks similar to that shown below although the comment may not be present if the entries were not automatically generated and the IP addresses of the nameserver entries will almost certainly be different. As these settings are presumably fully functional they should probably be left in the configuration file, commented out, in case we need them at a later date for any reason.

# Generated by dhcpcd for interface eth0

Once you have commented, or deleted, any existing lines from the resolv.conf file you can add the entries shown in the example below. Remember to change these entries so they correspond to the domain name and IP address which you are using in your installation.

If you do not have a domain name and wish to configure a DNS server purely for use on an internal network there are two special top level domains, the .site and .internal top level domains, which can be used for this purpose. You may create domains and sub-domains under these top level domains as you see fit.

If the first line of the configuration file looks like that shown in the first example above then the settings were placed there automatically by the DHCP client when it obtained the network address settings. So that our changes are not overwritten next time the network address changes or the interface is brought up we need to configure the DHCP client not to write to the /etc/resolv.conf file. This can be accomplished by adding the following line to the /etc/conf.d/net configuration file.

The network interface name may differ on your installation, especially if you have more than one physical network connection. If this is the case then replace the eth0 portion of the above configuration entry with whichever network interface is running a DHCP client on your installation.

Basic configuration

During installation of the PowerDNS package an example configuration file was created in place of a usable configuration file. As we shall be creating our configuration from scratch the first task is to rename the existing file, so that we can keep the example should we wish to refer to it at a later date, and create a new file in its place which we can begin editing.

lisa mv /etc/powerdns/pdns.conf /etc/powerdns/pdns.conf.example
lisa nano -w /etc/powerdns/pdns.conf

Now that we have an empty configuration file open in an editor we can begin to create a usable configuration for the PowerDNS daemon to use. We shall begin with a very simple configuration with no back-end processes configured so that we can introduce the configuration file syntax slowly and separate the configuration elements common to all back-ends from those which are specific to a single back-end. Enter the text below into the configuration file you opened earlier. The comments can be omitted, obviously, and are only there for your convenience.

# User and group settings

# Server settings

As you can see from the above example the syntax of the PowerDNS daemon configuration file is very simple consisting of a single variable-value pair on each line. The first two lines, after the comment, in our example configuration above instruct the PowerDNS daemon process to switch to the pdns user and group after starting. This is always a good idea as any daemon process can theoretically be compromised by an attacker and if it is running as the root user the entire machine is then accessible.

The next variable-value pair configures the PowerDNS daemon to listen on the local network address of which must, obviously, be an address bound to an adaptor in the machine we are installing the service on so you should change this address to one suitable for your configuration. If you would like the PowerDNS daemon to listen on multiple network addresses then a comma separated list can be used. Finally we instruct the PowerDNS daemon to start a "guardian" process to monitor the server process and restart it should it stop operating for any reason.

In the section below we shall enable the built-in web server so that we can make use of it during the configuration process as a debugging aid. In a production environment the server should probably be disabled and this information gathered using a combination of log analysis and the other management options built in to the PowerDNS daemon.

# Web server settings

As the web server component is disabled by default this section can simply be removed when the configuration is complete and this functionality is no longer required.