Ignore djbdns. Embora djb seja um herói, ele carrega a arrogância de um matemático para o software. O fato de que ele não se comporta como outro software em relação a iniciar / parar pode ser uma boa demonstração de uma técnica inteligente de gerenciamento de daemons. Mas você terá que retirar a documentação se não a usar regularmente, porque tudo é muito diferente. Se você configurá-lo em sistemas que os outros mantêm também, você precisará escrevê-los documentação clara - que eles precisam ler em sua totalidade para fazer operações simples. Executar coisas fora do init é fofo, até inteligente. Mas também é desagradável, surpreendente e fora do padrão.
Além disso, tive problemas com djbdns causando sérios problemas devido a uma insistência em apenas respeitar os padrões e não na interoperabilidade de software. A solução desses problemas foi uma grande perda de tempo, porque dependia de pequenas diferenças nos pacotes DNS.
Além disso, o djbdns tem um comportamento estranho em certos casos que fará com que as pessoas que solucionem problemas em seu servidor DNS com ferramentas diferentes de djb (por exemplo, com nslookup) obtenham resultados surpreendentes. Você perderá seu tempo explicando "na verdade, eu uso esse servidor DNS obscuro chamado djbdns. O problema é que suas ferramentas de diagnóstico estão lhe dando uma mensagem estranha, mas está funcionando bem. Se você olhar para essa captura de pacotes, Isso não está relacionado ao problema que tivemos há alguns meses, onde o djbdns não estava interoperando corretamente com o seu servidor DNS, nem está relacionado ao problema que tivemos algumas semanas atrás, quando eu estava fora do escritório e isso me levou colegas de equipe uma hora para reiniciar o servidor DNS. "
Problemas semelhantes com o qmail ao redor.
Existe algum valor educacional na configuração do djbdns, se você estiver fazendo a pergunta e tiver tempo para matar. Você também pode aprender bastante apenas lendo o site do djb.
Existem dois conjuntos de problemas de segurança. Falhas de segurança que permitem que um invasor acesse o sistema - o djbdns quase definitivamente não possui nenhuma delas. Alguns anos atrás o bind tinha alguns poucos embaraçosos descobertos em pouco tempo, expondo também um design ruim. Eu esperaria que, ao longo de muitos anos, ele tenha sido completamente reescrito. Se você realmente quiser estar seguro a esse respeito, execute-o em uma máquina virtual (por exemplo, Xen). Considere também, se você estiver rodando em um sistema Linux com o SELinux no modo direcionado, você terá uma configuração para bind e provavelmente não se importará com um para djbdns. O sistema bind + SELinux é potencialmente mais seguro.
O outro problema é a segurança contra o envenenamento de cache. Meu palpite é que djbdns foi melhor quando foi lançado, e bind é provavelmente melhor agora devido a uma maior atenção. Esta é provavelmente a causa da sua audição que o bind é inseguro a menos que seja "configurado corretamente". Você deve pelo menos pesquisar e entender esse problema. No processo, você provavelmente descobrirá quais riscos de configuração existem para os dois servidores DNS.
Comportamento sob carga pesada é um critério sem sentido para a maioria dos usuários. Cuidado com o desempenho usado como um critério para avaliar software que raramente é um gargalo de desempenho. Você não está hospedando um servidor DNS de armazenamento em cache para uma grande base de usuários, onde você pode receber solicitações a uma taxa significativa. Você está executando o DNS autoritativo para fornecer serviços que provavelmente estão sendo executados no mesmo sistema. Esses serviços são milhares de vezes mais caros que o DNS. Seu link de Internet pode nem ser suficiente para carregar seu servidor DNS, mas se você estivesse recebendo uma carga tão pesada nos serviços que você fornece, o DNS não seria um provável gargalo.