I'm a newbie who wants to learn how to set up a DNS nameserver. Should I use djbdns, BIND, or something else?

Current network requirements include subdomain support, SSL, and mail service, all on very light traffic. I'd like a solution that could someday scale up to heavier traffic and possibly trickier requirements (like load balancing). At this time I'd run either on Linux.

I've read that BIND has security issues if not properly configured, and that its configuration can be tricky. I've also read that djbdns is easier to configure, more secure, and equal to heavy loads. The arguments for djbdns seem plausible, but I haven't the expertise to properly evaluate them. If BIND is better, I'd appreciate a discussion of those claims for djbdns.


  • Authoritative service or recursive one?
    – bortzmeyer
    Jul 2, 2009 at 12:01
  • Authoritative, I think.
    – chernevik
    Jul 2, 2009 at 13:30

11 Answers 11


I've worked with djbdns in the past and currently run a bunch of BIND servers.

The biggest problem with djbdns is best put the way my first grade teacher put it on my report card: "doesn't play well with others". It simply doesn't behave like anything else on a unix box in all sorts of very small ways that can bite you later. It uses a syntax for zone files you won't see anywhere else.

The biggest advantage of djbdns is that it was designed from the ground up with security as goal #1.

If you were going to set up a DNS server, expose it to the internet and then never maintain it, djbdns would be the way to go.

In the real world, most admins are better off using the BIND packages from the OS vendor, and patching it promptly when there's an update. But running it chrooted is a good idea, and keeping your authoritative DNS servers separate from your recursive resolver DNS servers is a good idea.

If you find docs for something with DNS, BIND will be included and djbdns is unlikely to be included. If you use dig, the format it returns can be pasted into a BIND zone file and work. It acts like any normal unix daemon instead of something from another planet.

We use some hardware load balancers and load balance our recursive resolver BIND servers; works great. Just make sure the users get the same source IP as they sent their requests to and any UDP and TCP capable load balancing setup should work. If you're doing authoritative DNS, load balancing is as simple as having more than one server and publishing all of them in the whois info; the other DNS servers will load balance intelligently.

  • 2
    I like to think of it as if djdns doesn't work, it's your fault, if it does, then its DJ's. Jun 29, 2009 at 2:23
  • 2
    The whole discussion is helpful, and singling out any one answer seems a bit unfair to the others. This one is closest to the conclusion I've reached for myself: whatever their technological differences, BIND is better supported by documentation and community. As another answer noted, understanding it seems likely to simplify future DNS interactions. Those advantages seem more important than whatever benefit djbdns offers in ease of configuration.
    – chernevik
    Jun 29, 2009 at 16:49

For an authoritative service, nsd.

For a recursive one, unbound.

Both are small (so probably have less security holes waiting to be discovered), actively maintained and support all the recent DNS things (DNSSEC, IPv6, etc).

Otherwise, BIND is good software.

djbdns is a one-man project, unmaintained for a long time, not more secure (the author just says it so), and the official Web site is full of mistakes. (Now, I'm sure I will get a lot of downvotes from djbboys, my rep. was too high for my taste :-)


If it is for yourself, and if you want to learn how DNS works, I'd use djbdns.

If you want to understand how everyone else does DNS, and how to support typical enterprise deployments, learn bind.

If your goal is minimal effort and support, and you're reasonably competent, djbdns has a far lower support overhead.

If you're more on the novice side of the fence, you'll probably have an easier time getting bind up and running, but keep in mind that it is far more likely to explode in weird and wacky ways.

If I didn't already know djbdns (and bind) I would also look into powerdns and maradns, but I doubt that for tiny installs it is any better than the djbdns suite.

Regardless, even if you use bind for advertising your DNS to the internet, you should still run dnscache (part of the djbdns suite) running on localhost for your system's resolver.


Skip djbdns. Although djb is a hero, he carries over a mathematician's arrogance to software. The fact that it doesn't behave like other software with respect to starting/stopping it might be a good demonstration of a clever technique of managing daemons. But you're going to have to pull out the documentation if you don't use it on a regular basis, because everything is so different. If you set it up on systems that others maintain as well, you'll need to write them clear documentation - which they'll need to read in its entirety to do simple operations. Running stuff out of init is cute, even clever. But it's also obnoxious, surprising, and nonstandard.

Also, I've had issues with djbdns causing serious problems due to an insistence on only respecting standards, and not software interoperability. Troubleshooting these problems was a big waste of time, because it hinged on minor differences in DNS packets.

Also djbdns has strange behavior in certain cases that will cause people troubleshooting your DNS server with tools other than djb's (e.g. with nslookup) to get surprising results. You'll waste your time explaining "actually, I just use this obscure DNS server called djbdns. The problem is that your diagnostic tools are giving you a strange message, but it's working OK. If you look at this packet capture, you can tell. This isn't related to the problem we had a few months ago where djbdns was not interoperating correctly with your DNS server. Nor is it related to the problem we had a few weeks ago where I was out of the office and it took my teammates an hour to restart the DNS server."

Similar issues with qmail all around.

There is some educational value in setting up djbdns, if you're asking the question and have the time to kill. You can also learn plenty by just reading djb's website.

There are two sets of security issues. Security holes that allow an attacker access to the system - djbdns almost definitely doesn't have any of these. Some years ago bind had quite a few embarrassing ones discovered in a short time, also exposing a bad design. I would expect that over this many years, it's been completely rewritten. If you really want to be safe in this respect, run it under a virtual machine (e.g. Xen). Also consider, if you're running on a Linux system with SELinux in targeted mode, you'll have a setup for bind and probably won't bother with one for djbdns. The bind + SELinux system is potentially more secure.

The other issue is security against cache poisoning. My guess is that djbdns was better when it was released, and bind is probably better now due to greater attention. This is probably the cause of your hearing that bind is insecure unless "properly configured". You should at least research and understand this issue. In the process you'll probably find out what configuration risks exist for both DNS servers.

Behavior under heavy load is a nonsense criteria for most users. Beware of performance used as a criteria to evaluate software that is rarely a performance bottleneck. You're not hosting a caching DNS server for a huge user base, where you might get requests at a significant rate. You're running authoritative DNS to provide services that are probably running on the same system. These services are thousands of times more expensive than DNS. Your Internet link might not even be sufficient to heavily load your DNS server, but if you were receiving such a heavy load on the services you provide, DNS would not be a likely bottleneck.


You may want to have a look at MaraDNS, a security-aware DNS server.

  • Secure. MaraDNS has a security history as good as or better than any other DNS server. For example, MaraDNS has always randomized, using a secure random number generator, the Query ID and source port of DNS queries; and was never vulnerable to the "new" cache poisoning attack.

  • Supported. MaraDNS has a long history of being maintained and updated. MaraDNS was originally created in 2001. MaraDNS 1.0 was released in 2002 and MaraDNS 1.2 was released in December of 2005. MaraDNS has been extensively tested, both with a SQA process and with over four years of real-world use. MaraDNS continues to be fully supported: The most recent release was done on February 13, 2009. Deadwood, the code that will become part of MaraDNS 2.0, is being actively developed.

  • Easy to use. A basic recursive configuration needs only a single three-line configuration file. A basic authoritative configuration needs only a four-line configuration file and a one-line zone file. MaraDNS is fully documented, with both easy-to-follow tutorials and a complete and up-to-date reference manual.

  • Small. MaraDNS is well suited for embedded applications and other environments where the server must use the absolute minimum number of resources possible. MaraDNS' binary is smaller than that of any other currently maintained recursive DNS server.

  • Open Source. MaraDNS is fully open-source, The license is a two-clause BSD license that is almost identical to the FreeBSD license.

See the page of maraDNS advocacy where there is a comparison of several DNS server software that may help you choose.

  • MaraDNS is no longer maintained by the author, as noted on the project home page: maradns.org Jul 21, 2012 at 2:17
  • 1
    As a correction, while I no longer actively develop MaraDNS, I'm still maintaining it (bug fixes, updates for new compilers and Linux distros, etc.). In fact, I just put out a new MaraDNS release this year (2014) and will probably make one next year: maradns.samiam.org/download.html
    – samiam
    Jan 31, 2014 at 16:35

If you are running DNS just for yourself, djbdns is the the better software package. It was one of the few software packages that had identified the major DNS security issue from last year and was build/patched to fix it years before hand. For DNS caching I install dnscache (part of djbdns) on all servers that don't run as authoritative DNS servers. It really does work better than BIND for most items, but given today's hardware, the extra weight and slower speed of BIND is a non-issue.

For experience, I'd learn the basics of BIND, regardless of which package you choice to run.

Djbdns is up set to be real easy to admin from the command line. All changes to DNS data are done as commands. In BIND, you edit a series of text files.

You can get packages for both. I view the difference as IE vs. other browsers. IE comes built in and works for many things and doesn't that you change from the default. Djbdns is different and requires a different set of trade-offs. For an ISP, moving from BIND to djbdns can be a little tricky, because BIND by default does caching and name serving, where as djbdns splits this into two parts. This preferred security solution, but is harder to setup, so many BIND installations don't bother.


Personally I'd say that you need to learn the basics of BIND for reference sake, but that moving onto something else will make you a happier system administrator for future :)

Most places I've worked in the ISP industry seem to make use of djbdns, it provides excellent building blocks and foundations to layer 'managed' services atop - writing scripts to generate zone files is pretty trivial, meaning you can store all your DNS data in SQL anyway. It handles a ridiculous amount of queries per second and is secure to boot.

If you need to scale it, just go have a peek at http://haproxy.1wt.eu and pop a few authoritative servers behind that! I'd also highly recommend splitting out the resolvers from authoritative servers in any setup you choose to deploy.

Other things worth reading about are MaraDNS and PowerDNS.


I primarily use FreeBSD for these kind of things and since it comes bundles with BIND I never really took the effort to learn anything else. Hoever I find BIND rather easy to configure and since it is maintained in a security perspective by FreeBSD I only have to track that channel for any security problems.

So I guess the best bet for you is try both of them and see which one suites you the most, that is unless you use an OS that comes bundled with either of them.


If you're looking to learn about DNS, a copy of the O'Reilly book "DNS and BIND" and the latest version of bind installed is probably the best way to go.

It's true that BIND has had more security issues in its lifetime. dnjdns had none until last year, but it has a very different architecture from BIND and you may find it more difficult to pick up if you're not familiar with how the naming system works.

If you're just looking to learn about how to run a DNS server (as opposed to learning about the protocols and such), you'd be best to just pick one and dive in. I expect you'll find binary packages for both in whatever *nix distro you choose. That being said, there are some advantages to compiling from source with software that you may need to re-build if there is a security vulnerability announced.

As with any internet-facing service, some common sense and pragmatic thinking is the best way to go, regardless of what software you use. If you have to enable dynamic updates, make sure those are signed. If you allow zone transfers, restrict who can perform them from your sever, etc.

  • 1
    I dove in with djbdns, quickly hit some minor installation issues, and discovered there just isn't a very large community documenting such issues. There is nothing like "DNS and BIND" for it. Even if I get past this hurdle, every thing I might want to do is more likely to have discussion of the BIND solution. Whether it's technology is better or not, BIND seems to have better support.
    – chernevik
    Jun 27, 2009 at 18:10
  • Apparently, not so hard as you would like. I'm trying to do work, and make the best choices I can on limited understanding, not exhaust the potential of any particular tool. I'm grateful for djbdns, and perl, and lighttpd, and Free BSD, and all the other open source stuff I'm not currently using. Well, almost all. But I don't think you can seriously expect a novice to RTFM, or Look For TFM, more than I do. You're clearly invested in djbdns, and that's great. If my opinion annoys you, I guess you can hope for smarter novices, or you can work to make it easier for us to find answers.
    – chernevik
    Jul 3, 2009 at 12:08


If you will learn how to configure it (while reading a whole bunch of somewhat tiresome DNS-related RFCs) then you can easy switch to another DNS server in the future (for whatever purposes). I'm using BIND as primary and secondary servers everywhere on FreeBSD, Linux and even on the Vista laptop (for VMware NAT'ed hosts).

Btw, it's a kinda fun to read the source of BIND and discover how, for example, classic functions like gethostbyname() or gethostbyaddr() works.


After years of using bind, it finally dawned on me that most of my servers don't need to run their own DNS daemon at all. This may not apply to you, but think about it: virtually every domain registrar these days offers to server your DNS records for you (usually giving you some web-based way to edit your DNS records). They handle serving the info, managing the secondaries, etc. If you remove the need for your server to respond to DNS queries, all that is left is for your server to do DNS lookups. For this, I point my /etc/resolv.conf at and, which are the Level3 "anycast" DNS servers and seem to be quite fast and reliable.

An added bonus is that the firewall configuration for your server no longer has to let in DNS. You just need to the "established,related" rule to allow your server's DNS queries to work.

Okay, so you didn't ask if you needed to run a DNS daemon, but that's the question I answered. Just to be complete, if you find you must run one, I recommend sticking with bind because it is so commonly used you'll find lots of documentation and help making it do what you want.

  • Seems reasonable, but it seems easier to figure out how this works by first hosting it myself.
    – chernevik
    Jun 28, 2009 at 0:13

Not the answer you're looking for? Browse other questions tagged .