Ignore djbdns. Embora djb seja um herói, ele carrega a arrogância de um matemático ao software. O fato de ele não se comportar como outro software em relação a iniciar / parar pode ser uma boa demonstração de uma técnica inteligente de gerenciar 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 mantidos por outras pessoas, precisará escrever uma documentação clara - que eles precisam ler na íntegra para realizar 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 o djbdns causando problemas sérios devido à insistência em respeitar apenas os padrões e não à 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 possui um comportamento estranho em certos casos, que fará com que as pessoas que solucionam problemas no servidor DNS com outras ferramentas que não o djb (por exemplo, com nslookup) obtenham resultados surpreendentes. Você vai perder seu tempo explicando "na verdade, eu apenas uso esse servidor DNS obscuro chamado djbdns. O problema é que suas ferramentas de diagnóstico estão lhe enviando uma mensagem estranha, mas está funcionando bem. Se você observar esta captura de pacote, poderá dizer Isso não está relacionado ao problema que tivemos há alguns meses atrás, em que o djbdns não estava interoperando corretamente com o servidor DNS, nem ao problema que tivemos há algumas semanas, em que eu estava fora do escritório e levou meu colegas de equipe por hora para reiniciar o servidor DNS ".
Problemas semelhantes com o qmail ao redor.
Existe algum valor educacional na configuração de djbdns, se você estiver fazendo a pergunta e tiver tempo para matar. Você também pode aprender bastante lendo o site do djb.
Existem dois conjuntos de problemas de segurança. Falhas de segurança que permitem ao invasor acessar o sistema - o djbdns quase definitivamente não possui nenhum deles. Alguns anos atrás, o bind teve alguns embaraçosos descobertos em pouco tempo, também expondo um design ruim. Eu esperaria que, ao longo de muitos anos, tenha sido completamente reescrito. Se você realmente quer estar seguro nesse aspecto, execute-o em uma máquina virtual (por exemplo, Xen). Considere também, se você estiver executando em um sistema Linux com o SELinux no modo de destino, você terá uma configuração para o bind e provavelmente não se incomodará com o djbdns. O sistema bind + SELinux é potencialmente mais seguro.
A outra questão é a segurança contra envenenamento de cache. Meu palpite é que o djbdns era melhor quando foi lançado, e o bind provavelmente está melhor agora devido a uma atenção maior. Essa é provavelmente a causa da sua audição que o vínculo é inseguro, a menos que esteja "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.
O comportamento sob carga pesada é um critério sem sentido para a maioria dos usuários. Cuidado com o desempenho usado como critério para avaliar software que raramente é um gargalo de desempenho. Você não está hospedando um servidor DNS em cache para uma enorme 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 em execução no mesmo sistema. Esses serviços são milhares de vezes mais caros que o DNS. Seu link da Internet pode até não ser suficiente para carregar muito o servidor DNS, mas se você estivesse recebendo uma carga tão pesada nos serviços que fornece, o DNS não seria um provável gargalo.