Exploring PowerDNS
PowerDNS is an amazing, feature-rich, and versatile DNS server option.
Open source always innovates and produces a multitude of high-quality software offerings and this is true of PowerDNS. Like other critical network services, alternatives are always available. Apache or Nginx, Postfix or Sendmail, BIND or PowerDNS – all represent powerful options. PowerDNS is one such marvelous open alternative domain name system (DNS).
DNS, of course, is the distributed, hierarchical naming system that allows you to map what would be IP addresses to much more humanly digestible addresses. Thankfully, you no longer live in the early days of the Arpanet (precursor to today’s Internet), when you had to transfer large host files from node to node. PowerDNS is notably in use at some of the largest ISPs and websites in the world, such as AOL, Shaw Cable, and even Wikipedia. Its compact codebase and focus on security, scalability, and reliability make it a great name server choice. PowerDNS is jam packed with features that would impress any network or system admin:
- Authoritative DNS server (hosting)
- Resolving DNS server (caching)
- API to provision zones and records
- DNSSEC support (as of 3.x)
- Web-based management options
- DNS data stored in plaintext (BIND compatible)
- IPv4 and IPv6, UDP/TCP, 100% compliant
- MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Sybase database back ends
- Load balancing/failover algorithms
- SNMP support
- Remotely pollable statistics for real-time graphing
- Optional built-in web server
- Debugging tools
- Support for Linux, BSD, Unix
PowerDNS (PDNS) has two key distinct components: the authoritative server and the recursor. Other DNS servers combine these roles into one, but PowerDNS holds them separately. One can configure PDNS as either option. An authoritative name server is just what it sounds like: It is the the original and conclusive source of DNS zone information for a particular domain. A zone is merely a portion or set of administrative space. Authoritative domain servers are of two types: primary and secondary.
The primary name server is sometimes called a master server, which is the original and definitive source for all zone records for a domain.
The secondary name server, often called a slave server, is an identical replica used to provide redundancy and high availability. Like any service as vital as DNS, you should build redundancy into your infrastructure. That means at least two or more of everything, or you will need much more than two aspirins to deal with the headaches caused by downtime.
The PowerDNS recursor, on the other hand, simply provides caching or a standalone recursive resolver for clients accessing your network or the greater Internet (i.e., it is your first line of DNS for client machines). Recall that it isn’t authoritative but simply provides query resolution to the network client resolver (the client-side portion used to perform DNS queries) on your local machine.
The PowerDNS recursor supports:
- All relevant standards
- Advanced anti-spoofing measures
- Reconfiguration without downtime
- Plain BIND zone files for “resolved hosting”
- Question interception, answer reconditioning, NXDOMAIN redirection (including “block lists” and security measures)
- The rec_control utility, an API for direct control of the PowerDNS recursor and to output data to MRTG and RDD for pretty network graphs
- Local and remote access
- DNS64
Installing the PowerDNS Recursor
For this article, I’ll install on Ubuntu Server 13.04, which is in my local LAN. I am placing this server behind my hardware firewall on an internal network because making a caching server available on the public Internet is as unwise as doing so with a proxy or open mail relay. Installing is as easy as entering:
sudo apt-get install pdns-recursor
Now I need to customize my configuration file (recursor.conf) by editing /etc/powerdns/recursor.conf. For brevity’s sake, I only include the configuration variables I have changed herein.
allow-from=192.168.1.0/24 #The 'allow-from' address specifies the network address space you want to service queries to with your PowerDNS recursor. Note you can use comma-separated individual IPs or networks in CIDR notation. # local-address=192.168.1.10 # 'local-address' specifies the address or addresses on which the recursor is to listen for queries. # version-string=Wait, this ain't no host file # Give out bogus version information when queried with 'dig @ns1.example.com -c CH -t txt version.bind'. I'd rather add some mystery. =)
Now that I have saved my recursor.conf file, I restart my pdns-recursor:
sudo service pdns-recursor restart
Ubuntu has moved to Upstart instead of using sysvinit. so rather than the old school method of /etc/init.d start/stop/restart, I now use Upstart with the following syntax:
sudo servicestop/start/restart
rec_control
A bundled program, rec_control, lets you interact and control the PowerDNS recursor, which you can use to get statistics, check the status of the recursor, or even shut the recursor down. The following example (1) tests to see whether the server is up, (2) grabs variable statistics, (3) grabs a specific variable, and (4) quits PowerDNS:
01 $ sudo rec_control ping 02 $ sudo rec_control get-all 03 $ sudo rec_control get variable 04 $ sudo rec_control quit
Note that you can query many variables with rec_control, which you can use for RDD graphing.
PowerDNS Authoritative Server (BIND-Compatible Configuration)
PowerDNS supports a variety of back-end databases to hold zone data. Often PowerDNS is configured with a database back end (MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Sybase) and not flat text files (BIND back end), but in this article, I will explore using a BIND-compatible configuration. In many situations, you might not want to use a database. For example: a small organization might already be comfortable with a BIND configuration or not want the complexity of maintaining a database for DNS. Maybe, you are in transition from BIND to PowerDNS. Whatever the reason, PowerDNS has an easy way for you to use your existing BIND master zone configuration files to configure your PowerDNS server.
In this example, you would create two servers (or even VM or cloud instances) for your primary and secondary servers in your DMZ for publicly accessible services.
To begin, you need to install PowerDNS on your primary or master server:
sudo apt-get install pdns-server
The example PowerDNS primary DNS server configuration in /etc/powerdns for example.com is:
sudo nano example.com.zone example.com. 84600 IN SOA ns1.example.com. hostmaster.example.com. ( 2013062901 ; serial 21600 ; refresh (6 hours) 900 ; retry (15 minutes) 604800 ; expire (1 week) 3600 ; minimum (1 hour) ) NS ns1.example.com NS ns2.example.com MX 10 mail.example.com ns1 A 192.168.1.10 ns2 A 192.168.1.11 mail A 192.168.1.13 www A 192.168.1.14
(For simplicity and brevity’s sake the example omits the reverse DNS zone, but I recommend you create it.) Unlike the forward zone, which maps the hostname to the IP address, the reverse zone maps the opposite – IP address to hostname. Many network services and applications require reverse zone mapping, so it is a good idea to add it. Now, create a slimmed-down version of an old favorite, named.conf (BIND configuration file), in /etc/powerdns containing the bare essentials:
sudo nano bindbackend.conf options { directory "/etc/powerdns";};zone "example.com" { type master; file "example.com.zone"; };
Editing the Main PowerDNS Configuration File
General PowerDNS service is governed by a single configuration file located in /etc/powerdns – pdns.conf – to which you need to add:
allow-axfr-ips=192.168.1.11 #IP Address allowed to perform AXFR. # bind-check-interval=300 #Tell server how often to check for zone changes. # launch=bindbind-config=/etc/powerdns/bindbackend.conf #Tell PowerDNS to launch with BIND back end using the specified configuration file. # local-address=192.168.1.10 #Specifies the local IP on which PowerDNS listens. # master=yes #Tells PowerDNS to run this as the primary server. This primary server will send out a special notify packet to notify the secondary or slave of updates. # setgid=pdns #Sets Group ID to pdns for improved security # setuid=pdns #Sets user id to pdns for improved security # version-string=anonymous #No server version is divulged via dig query (e.g., dig @ns1.example.com -c CH -t txt version.bind). I'd rather make script kiddies work harder. =)
Finally, restart your PowerDNS service with:
sudo service pdns restart
PowerDNS Secondary (BIND Back End)
To get your configuration going, you first need to install PowerDNS on the secondary or slave server:
sudo apt-get install pdns-server
Just as with the primary sever, you create a slimmed-down version of an old favorite in /etc/powerdns, named.conf (the old BIND configuration file), containing the bare essentials:
sudo nano bindbackend.conf options { directory "/etc/powerdns"; }; zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.1.10; }; };
Note that because you are running with the setgid/setuid of the pdns user on the slave server, you need to change owner and group to that user:
sudo chown -R pdns:pdns /etc/powerdns
To configure a secondary DNS server with a BIND back end (BIND-compatible text configuration files), you need to add the following to pdns.conf (located in /etc/powerdns):
launch=bind bind-config=/etc/powerdns/bindbackend.conf #Tell PowerDNS to launch with BIND back end using the specified configuration file # bind-check-interval=300 #Tell server how often to check for zone changes # local-address=192.168.1.11 #Specifies the local IP on which PowerDNS listens # setgid=pdns #Sets Group ID to pdns for improved security # setuid=pdns #Sets user id to pdns for improved security # slave=yes #Variable identifies this server as a secondary or slave server # version-string=anonymous #No server version is divulged via a dig inquiry (e.g., dig @ns1.example.com -c CH -t txt version.bind). Oh, the mystery!
Finally, you want to HUP or restart the PowerDNS service:
sudo service pdns restart
Now that you have the servers up and running, you can dig query them to check the records and take a peek at /var/log/syslog to assure they are indeed talking. Now, go ahead and experiment with your newly created domain. As with the recursor, PowerDNS has even more tools and utilities on offer, and pdns_control is among them.
pdns_control
PowerDNS recursor has rec_control, and the full-blown server has its corollary, pdns_control. Much like rec_control, it allows you to control a PDNS server, as well gather important statistics: (1) test to see whether the server is alive, (2) purge the cache entries, (3) inform the back ends that the contents of the domains have changed, (4) show usage statistics, (5) show a specific statistic (use * for verbose details), (6) restart the PowerDNS instance.
01 $sudo pdns_control ping 02 $sudo pdns_control purge 03 $sudo pdns_control reload 04 $sudo pdns_control status 05 $sudo pdns_control06 $sudo pdns_control cycle
DNS and Security
DNS is a commonly exploited service that requires you to take your time in the engineering stages to deploy properly. Unfortunately, DNS has supernumerary attack vectors. The risks to a service that is as critical as DNS to the functioning of your network are many, but you can take some simple steps to ameliorate this:
- Patch, Patch, Patch – As silly as it sounds, some people don’t believe or invest in automating patch management; however, if you do so; it will solve quite a few issues.
- Split Servers Across Networks – Placing all your DNS servers on a single network space could be highly problematic if that core router dies or that network suffers a distributed denial of service attack. Split your servers across several, properly redundant and fault-tolerant network/server infrastructures.
- Firewalls – Although firewalls are by no means perfect, they are still a good practice. Firing up iptables on your DNS box will at the very least add additional layers to keep out those with malicious intent. Besides, thinking about ingress and egress rules with network services is always a good discipline.
- Explore and Deploy TSIG/TKEY and DNSSEC – Use TSIG/TKEY for securing zone transfers and deploy DNSSEC to help protect against cache poisoning. Although not detailed here, I point you to the copious documentation on these features.
I’m a big proponent of thinking of security as a priority in everything we do in Information Technology, and I see a rising consciousness of its importance. When you build with security as step 0, your problem set is reduced dramatically.
PowerDNS Community and Support Options
Like most other open source projects, support is available along many avenues. PowerDNS has gratis community support via mailing lists, forums and IRC, an ecosystem of partners and professional services organizations, and even direct commercial support from PowerDNS BV, the primary company behind this great software. Often commercial backing helps breath life, at least in the form of resources and community support, into an open source project; this is certainly the case with PDNS. Community and corporate support of high quality make this project great for users of any stripe – corporate or not.
Open source projects thrive when individuals become involved. PowerDNS has a host of opportunities for your involvement, including:
- Reviving OS X support
- Solaris packages
- Testing back ends
- Writing regression tests
- Collecting and documenting the plethora of web front ends
- Managing tickets: verifying that bugs reported for old versions still apply to new versions, making unclear tickets clear, and writing patches
- Many other to-do list items
If you are so inclined, it is a great way to get involved in a cool FOSS project. Learning opportunities abound, and your contributions will improve the critical infrastructure of today’s Internet.
I hope this short article has whet your appetite to explore this tremendously performant, feature-rich, flexible DNS software. PowerDNS rocks!
More Info
PowerDNS documentation:
https://www.powerdns.com/documentation.html
PowerDNS IRC:
#powerdns on OFTC – irc.oftc.net