It’s been a while since I wrote about PowerDNS, but I recently had the opportunity to look at the BIND backend. This backend enables PowerDNS to serve BIND-format zone files – which is a boon for any migration from BIND to PowerDNS. The BIND backend also supports serving DNSSEC RRs.
In this article, I will cover the installation of the latest version of PowerDNS Authoritative Server on a pair of CentOS 7.1 hosts – one set up as a master (centos-ns1) and the other as a slave (centos-ns2). Both of these servers will use the BIND backend. I’ll cover setting up these servers to run under
systemd, and appropriate firewall configuration using
firewall-cmd. Read my previous article for more detail on PowerDNS, the MySQL backend, chroot-ing the installation, and other topics.
Note: This article was written alongside BIND 10 1.0.0-beta. See this article which covers the major differences to be aware of between 1.0.0-beta, and 1.0.0-rc.
The third article in my series detailing the newest DNS software release from ISC – BIND 10 – will cover the configuration of zone transfers and dynamic DNS, both secured with TSIG. This article assumes you know a little about the new architecture of BIND 10 (I’ve written about it here).
I have two servers configured for this as follows, both running BIND 10 built as per my first article in the series:
172.16.18.169 ns1.example.com dolan
172.16.18.172 ns2.example.com gooby
No BIND 10 modules other than the default have been enabled at this point, and the servers have been started for the very first time. First, we need to perform some configuration of our master DNS server – ns1.example.com.
After many years in development, and many releases (development, alpha, beta, release candidate), ISC have announced the final Production release of BIND 10 1.0.0. My previous article covered the upgrade from 1.0.0-beta to 1.0.0-rc. Aside from a database upgrade (which was clearly logged for our attention) the upgrade was very straightforward.
Let’s see if the upgrade from 1.0.0-rc to 1.0.0 is as easy.
In this introductory article, I will present several methods for helping to secure DNS and Web Servers. I am using BIND 9.9.4 and Apache HTTPD 2.4.6 on CentOS 6.4. BIND and HTTPD are by far the most common DNS and Web Server platforms. I will show how to build the software from source, as well as perform an initial secure configuration. I will presume a minimal installation of CentOS 6.4. If you’re using another Linux or UNIX variant, you will need to adjust the procedures accordingly. This article presumes that the reader is already familiar with DNS and Web Servers, particularly BIND and HTTPD.
Fully hardening these services is a very complex subject and we only touch on the major aspects of configuration below.
Knot DNS server is a high-performance authoritative-only DNS server which supports all of the key features of the domain name system including zone transfers and DNSSEC. It was developed by the CZ.NIC. Knot DNS is open-source and multi-threaded. Current features include:
- Full and incremental zone transfers (AXFR/IXFR)
- Dynamic DNS updates
- EDNS0 and DNSSEC extensions, including NSEC3
- Response Rate Limiting
- and all of the standard features you’d expect with an authoritative-only nameserver implementation
Knot used to require zone files to be compiled (like NSD), but this requirement was removed as of Knot 1.3.0.
For this article, I’ll be running the latest stable version of Knot, 1.3.3, on CentOS 6.4. The test environment will comprise two hosts – venus (master) on 192.168.122.12 and earth (slave) on 192.168.122.13.
Knot 1.4.0-rc1 was also available at the time of writing which supports experimental DNSSEC auto-signing, so that may be worth checking out if relevant to your needs.
NSD is a name server implementation developed and maintained by NLnet Labs in cooperation with RIPE. NSD is an authoritative-only DNS implementation, and is memory efficient, secure and fairly straightforward.
NSD can start up quickly, as all zone information is compiled into an efficient binary format prior the the NSD daemon reading it. A few of the root nameservers use NSD, as well as the .se ccTLD. NSD has a proven history of being robust and can meet the demands of the highest-traffic DNS requirements known.
You can read more about NSD over at the project page (http://www.nlnetlabs.nl/projects/nsd/) so I won’t dwell on the preamble. My NSD implementation will run a master instance on server gooby and a slave instance on server dolan. There were a few pitfalls along the way, as this was my first NSD implementation. Unfortunately, there don’t seem to be many NSD resources available on the internet, so I’ll include those pitfalls in this article and hopefully save you some of the time/pain/
bash -x that I had to indulge myself in. Both gooby and dolan are running a minimal package install of CentOS 6.3 x86_64.
I have been an avid PowerDNS Authoritative Server (hereafter referred to as PowerDNS – there is also a separate Recursor available that we shall ignore for now – both available at http://www.powerdns.com) user since early in the 2.x series of releases. I replaced a global BIND infrastructure with PowerDNS for many reasons – instant provisioning to an easily replicated MySQL backend being the main one. PowerDNS is also RFC-compliant, powerful, and reliable.
The infrastructure I commissioned served well over 200,000 zones across three nameserver sites – each site receiving well over 100,000,000 queries per day. Two servers at each site, each with their own MySQL backend, replicated to from a hidden MySQL master to which we provisioned, handled this load with ease. Of course, this will depend entirely on the server specifications you use to host PowerDNS. PowerDNS offers support for multiple backends, however MySQL suits my needs well – I’m familiar with it, it’s more suited to DNS provisioning than LDAP (IMHO) and supports native replication (unlike PostgreSQL).
Rather than hacking a provisioning solution around BIND 9, moving to PowerDNS provided a technical advantage as well as a business advantage – customers could have their DNS data provisioned near-instantly – something that BIND 9 with a large number of zones and a cron’d rndc reconfig/reload would not achieve. PowerDNS 3.x introduces support for DNSSEC, something PowerDNS 2.x didn’t have – so it’s time to move to PowerDNS 3.x where possible.
I will use this article to walk through an installation of PowerDNS 3.2 from source on CentOS 6.3, perform basic configuration, load a basic zone, and serve the zone data authoritatively. This article will only scrape the surface of what PowerDNS has to offer, and further articles will be written in due course to cover interesting concepts in finer detail.
Have a good read over the manual available on the PowerDNS documentation site (http://doc.powerdns.com) too.