Posted on

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!

Posted on

Vale SORBS, we’ll hardly miss ye…

SORBS is on death’s door.

I can’t say I’m unhappy to see this or i’ll miss it when it’s gone. An arbitrary definition of “spam” is not so good; providing almost no information to administrators and end users is just plain poor and demanding a “donation” for removal is just plain bovine excrement.

Something I learned from my formative years as a neophyte mail admin-in-training on news.admin.net-abuse.email was that if you wanted to run a blacklist and be taken seriously, you need a fair deal of transparency (ie provide info on why/how a server got listed and a means to resolve the issue) and fairly sane and personable demeanour, and a clear and stricly enforced policy on listing.

Unfortunately SORBS failed all of these in my experience.

One of my old jobs was to handle abuse@ at a Large Australian Hosting Provider (now part of MelbourneIT) along with my regular systems admin / support duties.

Alas, as unfortunately happens in large network / hosting ops, a customer spews some junk. We found and terminated the perp, but not before getting blacklisted.

A quick check of the major lists found the evidence / reason for listing and after informing them that we’d resolved the issue removal was quite swift.

But not SORBS. After jumping through a couple of hoops to find out how / when the servers got listed, no evidence for it’s addition was found aside a single “Recieved:” email header – which is easily forged (and at the time quite popular with spammers to confuse less experienced users/admins)

Our request for more information was met with little more than “I have proof, but I’m not sharing any more” and removal was met with “Donate to the fund supporting Mr Anti-Spammer, who’s being sued for defamation by WeSpamYou Pty. Ltd and I’ll remove it” (names spared to protect the innocent).

W.T.F? Of course the answer was “no” (with the backing of management) especially after I pointed out the case had been settled, in the anti-spammer’s favour. This was changed to a “donate to $charity” after I reminded Mr/Ms Sullivan of that fact.

It still didn’t act as a deterrent (even Legal pointing out that it’s potentially extortion didn’t work!) so I just gave up and stopped bothering with him. You know what they say about arguing with an idiot – they bring you to their level and beat you with experience.

Henceforth, I’ve been advising mail administrators not to use SORBS zones. Customers getting bounces mentioning SORBS got a boilerplate response outlining the situation and why using opaque and arbitrary lists are a Bad Thing (worded appropriately for on-forwarding to ISPs as applicable). I don’t recall ever getting one complaint, as most of the major ISPs here didn’t use it to block mail anyway and smaller players generally got the message once made aware.

There are far better alternatives that don’t generate so many false positives, catch more genuine spam and don’t shake down mail admins / abuse guys for removal. I personally use zen.spamhaus.org for my DNS blacklist needs and it’s never let me down in over 6 years (tied into a multitude of Postfix and Exim installs for small and large mail providers alike)