Getting a PowerDNS recursor up and going, fast!

This post is another one of my “quick and dirty” service tutorials

This time, I’ll cover getting a recursive DNS service up and going, using the PowerDNS recursor package. Traditionally Red Hat/Fedora users would opt for BIND (with or without the old “caching-nameserver” package of old) but I like to be a little different. Plus:

  • PowerDNS has an excellent security record (was not affected by the Kaminsky DNS vulnerability)
  • It’s small and does only the job it’s intended for in the traditional small-tool UNIX philosophy (Authoritative DNS is the job of it’s “bigger brother” PowerDNS package)
  • It’s fast and very easy to configure (compare to djbdns for example, which is neither)

Installing the software

For Fedora users, it’s in the Everything repository so you can just install the package as below. Red Hat Enterprise Linux  / CentOS et. al will need to  add the EPEL repository first

To install, simply

yum install pdns-recursor

.. which will install the package and it’s dependencies (just lua and boost if you’re on a fairly fresh install)

Configuration:

It only needs a single configuration file in /etc/pdns-recursor/recursor.conf., so open it in your preferred editor

As it uses key = value pairs, it’s very easy to follow, well commented and the defaults are quite sensible.

Firstly, for security, change the “allow-from” to match your local subnets – this determines which address blocks our server will permit and answer recursive queries for.

allow-from= 127.0.0.0/8, 192.168.1.0/24, 10.0.0.0/8

If  you have local authoritative zones (especially private internal DNS) you may want to set forward-zones to tell the recursor to query those servers for domains

#format is zonename=dns.server.ip

forward-zones = internal.example.com=10.0.0.1

If  you have a number of zones to forward queries for, you can use the forward-zones-file directive, which should point to a file containing the key-value pairs as above

By default, PowerDNS will listen on all interfaces but in practice will still prefer an explicit interface to listen on, so setting a local address via local-address is generally a good idea, especially if you’re multi-homed. It takes multiple addresses or even 0.0.0.0 ?

# Listen on localhost and my NIC IP

local-address = 127.0.0.1, 10.0.0.1

For spotting common issues I like to have a little logging, but not much, so I set it to send common errors to syslog

log-common-errors=yes

For most uses, that’s all you need! Start the server via service pdns-recursor start and test it via dig/host

[mfleming@qbert ~]$ dig a www.thatfleminggent.com @10.0.4.42

; <<>> DiG 9.5.1-P3-RedHat-9.5.1-3.P3.fc10 <<>> a www.thatfleminggent.com @10.0.4.42
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6559
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.thatfleminggent.com.    IN    A

;; ANSWER SECTION:
www.thatfleminggent.com. 2044    IN    A    174.143.247.61

;; Query time: 4 msec
;; SERVER: 10.0.4.42#53(10.0.4.42)
;; WHEN: Sun Aug  9 14:19:19 2009
;; MSG SIZE  rcvd: 57

Oh, and before anyone asks: see the 3rd answer in the FAQ regarding presence/absence of Authority records in dig etc. output. It’s a feature, not a bug!

A little more advanced..

If you have IPv6 enabled networks and want to make best use of v6-enabled services, tell the recursor to look up AAAA records too (it’s not on by default, as it’s a little slower):

aaaa-additional-processing=yes

You can also send queries out over IPv6 using the query-local-address6 directive eg:

query-local-address6=2001:44b8:62:1b0::1

If you’re security conscious and don’t want any bogus records coming from g/TLDs that isn’t glue/delegations, use the delegation-only directive:

delegation-only=ad,af,ar,biz,cr,cu,de,dm,fr,id,lu,lv,md,ms,museum,name,no,pa,pf,re,se,sr,to,tw,us,uy

Enjoy!