home of the madduck/ blog/
DNS server selection, and why not to BIND yourself

I have been searching for a new DNS server for quite some time now. Among the ones I inspected were:

So with all of the above, it comes down to MaraDNS or PowerDNS for me, depending on whether I want flat files (easy to maintain by separate users, with permissions set with per-domain granularity) or SQL (flexible, but not as easy to control access). My goal is to give certain users complete control over their own zones.

Anyway, in the process, I did look at BIND 9 again, simply because it certainly has some interesting features the others do not have, namely nsupdate, DNSSEC, TSIG, and IPv6.

So with the help of this awesome document on starting with a secure BIND configuration, I got the name server up and running with only few problems (zone files suck). However, it did not take me long to abandon it for good:

The reason is #372591. I have found that the only way to give users the ability to create and modify zone files for their own domains in a fail-proof manner (so that they don’t accidentally screw up permissions), is by using POSIX ACLs, so that each zone file has permissions like this:

# file: zones/belligerence.net
# owner: madduck
# group: dnsmasters
user::rw-
group::r--
group:bind:r--
mask::r--
other::---

BIND, however, insists on checking the standard Unix permissions of files it reads and fails rather verbosely if it decides that it cannot, or rather should not be able to read them:

Jun 10 15:36:15.871 client 84.7x.xx.129#33283: query: belligerence.net IN A
Jun 10 15:36:15.871 client 84.7x.xx.129#33283: error

I’ve let of most of my steam on IRC, but for the record, here’s Bernhard R. Link’s explanation, quoted with permission. He did point out that he knows only very little about BIND and comes at this rather from the point of view of the system-level privileges.

When POSIX permissions fail, it’s always hard to decide. The system might not be able to drop root permissions properly and one might end up reading stuff not intended to be read. It took some time in Unix history to get privilege dropping right, and there’s nothing worse than a BIND suddenly sending out your shadow file. the point is, bind needs root to bind to its ports. Then it has to make sure that root privilege is not abused. That can be either done by making sure on is only the specific user (which is hard to do portably, and sometimes fails), or double check you only access what you are allowed. Ideally it should drop privileges good enough, but given how often this failed in the past, double checks are a good thing.

I disagree. Of course it’s hard to argue that double checks aren’t a good thing, especially when it comes to security issues with respect to an application that has one of the worst security track records of all Unix applications. However, what BIND is doing here is covering up a potentially greater problem: if the underlying system does not handle privilege drops properly, then that needs fixing. If an admin runs such a system, there’s the root of the problem. It helps only marginally that BIND is trying to help prevent attacks. Fix the problem at its root, don’t fix or patch for the symptoms!

Now, of course, it does not really hurt that BIND does these checks. However, if it does them, it should at least be less naïve about them. POSIX ACLs have been around for, what, almost 10 years now. Go figure. Btw: this applies to many other tools/standards in the Unix world. scp, for instance, also cannot handle ACLs.

So MaraDNS or PowerDNS?