Ignorez les djbdns. Bien que djb soit un héros, il transmet l'arrogance d'un mathématicien au logiciel. Le fait qu'il ne se comporte pas comme les autres logiciels en ce qui concerne le démarrage / l'arrêt pourrait être une bonne démonstration d'une technique intelligente de gestion des démons. Mais vous devrez retirer la documentation si vous ne l'utilisez pas régulièrement, car tout est si différent. Si vous le configurez sur des systèmes que d'autres maintiennent également, vous devrez leur écrire une documentation claire - qu'ils devront lire dans son intégralité pour effectuer des opérations simples. Exécuter des trucs hors d'init est mignon, même intelligent. Mais c'est aussi désagréable, surprenant et non standard.
De plus, j'ai eu des problèmes avec djbdns causant de graves problèmes en raison de l'insistance à ne respecter que les normes et non l'interopérabilité des logiciels. La résolution de ces problèmes était une grande perte de temps, car elle reposait sur des différences mineures dans les paquets DNS.
De plus, djbdns a un comportement étrange dans certains cas qui amènera les gens à dépanner votre serveur DNS avec des outils autres que djb (par exemple avec nslookup) pour obtenir des résultats surprenants. Vous perdrez votre temps à expliquer "en fait, j'utilise juste ce serveur DNS obscur appelé djbdns. Le problème est que vos outils de diagnostic vous donnent un message étrange, mais ça marche bien. Si vous regardez cette capture de paquets, vous pouvez dire . Ce n'est pas lié au problème que nous avons eu il y a quelques mois où djbdns ne fonctionnait pas correctement avec votre serveur DNS. Ce n'est pas non plus lié au problème que nous avons eu il y a quelques semaines lorsque j'étais absent du bureau et cela m'a pris mon coéquipiers une heure pour redémarrer le serveur DNS. "
Problèmes similaires avec qmail tout autour.
Il y a une certaine valeur éducative à configurer des djbdns, si vous posez la question et avez le temps de tuer. Vous pouvez également en apprendre beaucoup en lisant simplement le site Web de djb.
Il existe deux types de problèmes de sécurité. Failles de sécurité qui permettent à un attaquant d'accéder au système - djbdns n'en a certainement aucun. Il y a quelques années, bind en avait découvert quelques-uns embarrassants en peu de temps, exposant également un mauvais design. Je m'attendrais à ce qu'au cours de ces nombreuses années, il soit complètement réécrit. Si vous voulez vraiment être sûr à cet égard, exécutez-le sous une machine virtuelle (par exemple Xen). Pensez également, si vous exécutez sur un système Linux avec SELinux en mode ciblé, vous aurez une configuration pour bind et ne vous embêtera probablement pas avec une pour djbdns. Le système bind + SELinux est potentiellement plus sécurisé.
L'autre problème est la sécurité contre l'empoisonnement du cache. Je suppose que djbdns était meilleur quand il a été publié et que bind est probablement meilleur maintenant en raison d'une plus grande attention. C'est probablement la cause de votre audition qui lie n'est pas sûr à moins que "correctement configuré". Vous devez au moins rechercher et comprendre ce problème. Dans le processus, vous découvrirez probablement les risques de configuration qui existent pour les deux serveurs DNS.
Le comportement sous forte charge est un critère absurde pour la plupart des utilisateurs. Méfiez-vous des performances utilisées comme critère pour évaluer un logiciel qui est rarement un goulot d'étranglement des performances. Vous n'hébergez pas de serveur DNS de mise en cache pour une énorme base d'utilisateurs, où vous pourriez recevoir des demandes à un taux important. Vous exécutez un DNS faisant autorité pour fournir des services qui s'exécutent probablement sur le même système. Ces services sont des milliers de fois plus chers que le DNS. Votre lien Internet n'est peut-être même pas suffisant pour charger fortement votre serveur DNS, mais si vous receviez une telle charge sur les services que vous fournissez, le DNS ne serait probablement pas un goulot d'étranglement.