djbdns vs bind [fermé]

Je suis un débutant qui veut apprendre à configurer un serveur de noms DNS. Dois-je utiliser djbdns, BIND ou autre chose?

Les exigences actuelles du réseau incluent la prise en charge des sous-domaines, SSL et le service de messagerie, le tout sur un trafic très léger. J'aimerais une solution qui pourrait un jour évoluer vers un trafic plus lourd et des exigences éventuellement plus délicates (comme l'équilibrage de charge). A cette époque, je courrais soit sur Linux.

J'ai lu que BIND a des problèmes de sécurité s'il n'est pas correctement configuré et que sa configuration peut être délicate. J'ai également lu que djbdns est plus facile à configurer, plus sûr et égal aux charges lourdes. Les arguments pour djbdns semblent plausibles, mais je n'ai pas l'expertise pour les évaluer correctement. Si BIND est meilleur, j'apprécierais une discussion de ces revendications pour djbdns.

Merci.

J'ai travaillé avec djbdns dans le passé et je gère actuellement un groupe de serveurs BIND.

Le plus gros problème avec djbdns est de mieux mettre la façon dont mon professeur de première année l'a mis sur mon bulletin: "ne joue pas bien avec les autres". Il ne se comporte tout simplement pas comme n'importe quoi d'autre sur une boîte Unix de toutes sortes de très petites manières qui peuvent vous mordre plus tard. Il utilise une syntaxe pour les fichiers de zone que vous ne verrez nulle part ailleurs.

Le plus grand avantage de djbdns est qu'il a été conçu dès le départ avec la sécurité comme objectif n ° 1.

Si vous deviez configurer un serveur DNS, l'exposer à Internet et ne jamais le maintenir, djbdns serait le chemin à parcourir.

Dans le monde réel, la plupart des administrateurs préfèrent utiliser les packages BIND du fournisseur du système d'exploitation et les corriger rapidement en cas de mise à jour. Mais l'exécuter en chrooté est une bonne idée, et garder vos serveurs DNS faisant autorité séparés de vos serveurs DNS résolveurs récursifs est une bonne idée.

Si vous trouvez des documents pour quelque chose avec DNS, BIND sera inclus et djbdns ne sera probablement pas inclus. Si vous utilisez dig, le format qu'il renvoie peut être collé dans un fichier de zone BIND et fonctionner. Il agit comme n'importe quel démon Unix normal au lieu de quelque chose d'une autre planète.

Nous utilisons des équilibreurs de charge matériels et équilibrons la charge de nos serveurs BIND résolveurs récursifs; fonctionne très bien. Assurez-vous simplement que les utilisateurs obtiennent la même IP source qu'ils ont envoyé leurs demandes et que toute configuration d'équilibrage de charge compatible UDP et TCP devrait fonctionner. Si vous faites du DNS faisant autorité, l'équilibrage de charge est aussi simple que d'avoir plus d'un serveur et de les publier tous dans les informations whois; les autres serveurs DNS chargeront l'équilibre de façon intelligente.

Pour un service faisant autorité, nsd .

Pour un récursif, non lié .

Les deux sont petits (donc ont probablement moins de trous de sécurité à découvrir), activement maintenus et prennent en charge toutes les choses DNS récentes (DNSSEC, IPv6, etc.).

Sinon, BIND est un bon logiciel.

djbdns est un projet individuel, non entretenu depuis longtemps, pas plus sûr (l'auteur le dit simplement), et le site Web officiel est plein d'erreurs. (Maintenant, je suis sûr que j'obtiendrai beaucoup de downvotes de djbboys, mon représentant était trop élevé à mon goût :-)

Si c'est pour vous et si vous voulez savoir comment fonctionne DNS, j'utiliserais djbdns.

Si vous souhaitez comprendre comment tout le monde utilise DNS et comment prendre en charge les déploiements d'entreprise typiques, découvrez bind.

Si votre objectif est un effort et un soutien minimes et que vous êtes raisonnablement compétent, djbdns a un coût de support beaucoup plus faible.

Si vous êtes plutôt du côté novice de la clôture, vous aurez probablement plus de facilité à vous lier et à courir, mais gardez à l'esprit qu'il est beaucoup plus susceptible d'exploser de manière étrange et loufoque.

Si je ne connaissais pas déjà djbdns (et bind), j'examinerais également les powerdns et les maradns, mais je doute que pour les petites installations, c'est mieux que la suite djbdns.

Quoi qu'il en soit, même si vous utilisez bind pour publier votre DNS sur Internet, vous devez toujours exécuter dnscache (qui fait partie de la suite djbdns) exécuté sur localhost pour le résolveur de votre système.

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.

Vous voudrez peut-être jeter un œil à MaraDNS , un serveur DNS sécurisé.

• Sécurise. MaraDNS a un historique de sécurité aussi bon ou meilleur que tout autre serveur DNS. Par exemple, MaraDNS a toujours randomisé, en utilisant un générateur de nombres aléatoires sécurisé, l'ID de requête et le port source des requêtes DNS; et n'a jamais été vulnérable à la "nouvelle" attaque d'empoisonnement de cache.

• Prise en charge. MaraDNS a une longue histoire de maintenance et de mise à jour. MaraDNS a été créé à l'origine en 2001. MaraDNS 1.0 a été publié en 2002 et MaraDNS 1.2 a été publié en décembre 2005. MaraDNS a été largement testé, à la fois avec un processus SQA et avec plus de quatre ans d'utilisation dans le monde réel. MaraDNS continue d'être pleinement pris en charge: la dernière version a été réalisée le 13 février 2009. Deadwood, le code qui fera partie de MaraDNS 2.0, est en cours de développement.

• Facile à utiliser. Une configuration récursive de base n'a besoin que d'un seul fichier de configuration à trois lignes. Une configuration faisant autorité de base n'a besoin que d'un fichier de configuration à quatre lignes et d'un fichier de zone à une ligne. MaraDNS est entièrement documenté, avec à la fois des didacticiels faciles à suivre et un manuel de référence complet et à jour.

• Petit. MaraDNS est bien adapté aux applications intégrées et autres environnements où le serveur doit utiliser le nombre minimum absolu de ressources possible. Le binaire de MaraDNS est plus petit que celui de tout autre serveur DNS récursif actuellement maintenu.

• Open source. MaraDNS est entièrement open-source, la licence est une licence BSD à deux clauses qui est presque identique à la licence FreeBSD.

Voir la page de plaidoyer maraDNS où il existe une comparaison de plusieurs logiciels de serveur DNS qui peuvent vous aider à choisir.

Si vous exécutez DNS uniquement pour vous-même, djbdns est le meilleur progiciel. C'était l'un des rares logiciels à avoir identifié le problème de sécurité DNS majeur de l'année dernière et a été construit / corrigé pour le résoudre des années auparavant. Pour la mise en cache DNS, j'installe dnscache (partie de djbdns) sur tous les serveurs qui ne fonctionnent pas en tant que serveurs DNS faisant autorité. Il fonctionne vraiment mieux que BIND pour la plupart des articles, mais étant donné le matériel d'aujourd'hui, le poids supplémentaire et la vitesse plus lente de BIND ne posent aucun problème.

Par expérience, j'apprendrais les bases de BIND, quel que soit le package que vous choisissez d'exécuter.

Djbdns est configuré pour être vraiment facile à administrer depuis la ligne de commande. Toutes les modifications apportées aux données DNS sont effectuées sous forme de commandes. Dans BIND, vous modifiez une série de fichiers texte.

Vous pouvez obtenir des packages pour les deux. Je considère la différence comme IE par rapport aux autres navigateurs. IE est intégré et fonctionne pour de nombreuses choses et ne change pas par défaut. Djbdns est différent et nécessite un ensemble différent de compromis. Pour un FAI, passer de BIND à djbdns peut être un peu délicat, car BIND fait par défaut la mise en cache et le service de nom, alors que djbdns le divise en deux parties. Cette solution de sécurité préférée, mais est plus difficile à configurer, donc de nombreuses installations BIND ne dérangent pas.

Personnellement, je dirais que vous devez apprendre les bases de BIND à titre de référence, mais que passer à autre chose fera de vous un administrateur système plus heureux à l'avenir :)

La plupart des endroits où j'ai travaillé dans l'industrie des FAI semblent utiliser djbdns, il fournit d'excellents blocs de construction et fondations pour superposer les services `` gérés '' - l'écriture de scripts pour générer des fichiers de zone est assez triviale, ce qui signifie que vous pouvez stocker toutes vos données DNS en SQL de toute façon. Il gère une quantité ridicule de requêtes par seconde et est sécurisé pour démarrer.

Si vous avez besoin de le faire évoluer, jetez un œil à http://haproxy.1wt.eu et faites apparaître quelques serveurs faisant autorité derrière cela! Je recommande également fortement de séparer les résolveurs des serveurs faisant autorité dans toute configuration que vous choisissez de déployer.

MaraDNS et PowerDNS méritent également d'être lus.

J'utilise principalement FreeBSD pour ce genre de choses et comme il est fourni avec BIND, je n'ai jamais vraiment pris l'effort d'apprendre autre chose. Cependant, je trouve que BIND est assez facile à configurer et comme il est maintenu dans une perspective de sécurité par FreeBSD, je n'ai qu'à suivre ce canal pour tout problème de sécurité.

Donc, je suppose que le meilleur pari pour vous est d'essayer les deux et de voir celle qui vous convient le plus, à moins que vous n'utilisiez un système d'exploitation fourni avec l'un d'eux.

Si vous souhaitez en savoir plus sur DNS, une copie du livre O'Reilly " DNS and BIND " et la dernière version de bind installée est probablement la meilleure solution.

Il est vrai que BIND a eu plus de problèmes de sécurité au cours de sa vie. dnjdns n'en avait pas jusqu'à l'année dernière, mais il a une architecture très différente de BIND et vous pouvez trouver plus difficile à récupérer si vous n'êtes pas familier avec le fonctionnement du système de nommage.

Si vous cherchez simplement à savoir comment exécuter un serveur DNS (par opposition à l'apprentissage des protocoles et autres), vous feriez mieux d'en choisir un et de vous y plonger. Je pense que vous trouverez des packages binaires pour les deux dans la distribution * nix que vous choisissez. Cela étant dit, il existe certains avantages à compiler à partir de la source avec un logiciel que vous devrez peut-être reconstruire si une vulnérabilité de sécurité est annoncée.

Comme pour tout service accessible sur Internet, le bon sens et la pensée pragmatique sont la meilleure façon de procéder, quel que soit le logiciel que vous utilisez. Si vous devez activer les mises à jour dynamiques, assurez-vous qu'elles sont signées. Si vous autorisez les transferts de zone, limitez qui peut les effectuer depuis votre serveur, etc.

LIER.

Si vous apprendrez à le configurer (tout en lisant tout un tas de RFC liés au DNS quelque peu fastidieux), vous pourrez facilement basculer vers un autre serveur DNS à l'avenir (pour toutes les finalités). J'utilise BIND comme serveurs principaux et secondaires partout sur FreeBSD, Linux et même sur l'ordinateur portable Vista (pour les hôtes VMware NAT).

Btw, c'est un peu amusant de lire la source de BIND et de découvrir comment, par exemple, des fonctions classiques comme gethostbyname () ou gethostbyaddr () fonctionnent.

Après des années d'utilisation de bind, j'ai finalement compris que la plupart de mes serveurs n'avaient pas du tout besoin d'exécuter leur propre démon DNS. Cela ne s'applique peut-être pas à vous, mais pensez-y: pratiquement tous les registraires de domaine proposent ces jours-ci de gérer vos enregistrements DNS pour vous (vous donnant généralement un moyen Web de modifier vos enregistrements DNS). Ils gèrent la diffusion des informations, la gestion des secondaires, etc. Si vous supprimez la nécessité pour votre serveur de répondre aux requêtes DNS, il ne vous reste plus qu'à effectuer des recherches DNS. Pour cela, je pointe mon /etc/resolv.conf sur 4.2.2.1 et 4.2.2.2, qui sont les serveurs DNS "anycast" de niveau 3 et semblent assez rapides et fiables.

Un avantage supplémentaire est que la configuration du pare-feu pour votre serveur n'a plus à laisser entrer le DNS. Vous avez juste besoin de la règle "établie et associée" pour permettre aux requêtes DNS de votre serveur de fonctionner.

D'accord, vous n'avez donc pas demandé si vous aviez besoin d'exécuter un démon DNS, mais c'est la question à laquelle j'ai répondu. Juste pour être complet, si vous trouvez que vous devez en exécuter un, je recommande de rester avec bind car il est si couramment utilisé que vous trouverez beaucoup de documentation et que vous l'aiderez à faire ce que vous voulez.