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.