djbdns vs bind [geschlossen]

Ich bin ein Neuling, der lernen möchte, wie man einen DNS-Nameserver einrichtet. Soll ich djbdns, BIND oder etwas anderes verwenden?

Zu den aktuellen Netzwerkanforderungen gehören Subdomain-Support, SSL und Mail-Service bei sehr geringem Datenverkehr. Ich hätte gerne eine Lösung, die eines Tages auf einen höheren Datenverkehr und möglicherweise schwierigere Anforderungen (wie Lastausgleich) skaliert werden könnte. Zu diesem Zeitpunkt lief ich entweder unter Linux.

Ich habe gelesen, dass BIND Sicherheitsprobleme hat, wenn es nicht richtig konfiguriert ist, und dass seine Konfiguration schwierig sein kann. Ich habe auch gelesen, dass djbdns einfacher zu konfigurieren, sicherer und für hohe Lasten geeignet ist. Die Argumente für djbdns scheinen plausibel, aber ich habe nicht das Fachwissen, um sie richtig zu bewerten. Wenn BIND besser ist, würde ich eine Diskussion dieser Behauptungen für djbdns begrüßen.

Vielen Dank.

Ich habe in der Vergangenheit mit djbdns gearbeitet und derzeit eine Reihe von BIND-Servern ausgeführt.

Das größte Problem mit djbdns ist, wie mein Lehrer in der ersten Klasse es auf mein Zeugnis geschrieben hat: "Spielt nicht gut mit anderen". Es verhält sich einfach nicht wie irgendetwas anderes auf einer Unix-Box in allerlei sehr kleinen Situationen, die Sie später beißen können. Es verwendet eine Syntax für Zonendateien, die Sie sonst nirgendwo sehen.

Der größte Vorteil von djbdns ist, dass es von Grund auf mit Sicherheit als Ziel # 1 entworfen wurde.

Wenn Sie einen DNS-Server einrichten, ihn dem Internet aussetzen und ihn dann niemals warten würden, wäre djbdns der richtige Weg.

In der Praxis ist es für die meisten Administratoren besser, die BIND-Pakete des Betriebssystemherstellers zu verwenden und sie bei einem Update umgehend zu patchen. Es ist jedoch eine gute Idee, es in einer Chroot-Umgebung auszuführen, und Ihre autorisierenden DNS-Server von Ihren DNS-Servern mit rekursivem Resolver zu trennen.

Wenn Sie Dokumente für etwas mit DNS finden, wird BIND eingeschlossen, und es ist unwahrscheinlich, dass djbdns eingeschlossen wird. Wenn Sie dig verwenden, kann das zurückgegebene Format in eine BIND-Zonendatei eingefügt werden und funktionieren. Es verhält sich wie ein normaler Unix-Daemon anstelle von etwas von einem anderen Planeten.

Wir verwenden einige Hardwarelastausgleichsmodule und gleichen unsere BIND-Server für rekursive Resolver aus. funktioniert super. Stellen Sie einfach sicher, dass die Benutzer dieselbe Quell-IP erhalten, an die sie ihre Anforderungen gesendet haben, und dass alle UDP- und TCP-fähigen Lastenausgleichs-Setups funktionieren sollten. Wenn Sie autorisierendes DNS ausführen, ist der Lastenausgleich so einfach wie das Veröffentlichen mehrerer Server in den whois-Informationen. Die anderen DNS-Server werden den Lastenausgleich intelligent durchführen.

Für einen autorisierenden Dienst, nsd .

Für eine rekursive, ungebunden .

Beide sind klein (wahrscheinlich haben sie weniger Sicherheitslücken, die entdeckt werden müssen), werden aktiv gewartet und unterstützen alle aktuellen DNS-Dinge (DNSSEC, IPv6 usw.).

Ansonsten ist BIND eine gute Software.

djbdns ist ein Ein-Mann-Projekt, das lange Zeit nicht mehr gewartet wurde, nicht sicherer ist (der Autor sagt es nur so), und die offizielle Website ist voller Fehler. (Jetzt bin ich mir sicher, dass ich von DJBboys eine Menge Downvotes kriegen werde, mein Repräsentant war zu hoch für meinen Geschmack :-)

Wenn es für Sie selbst ist und Sie erfahren möchten, wie DNS funktioniert, würde ich djbdns verwenden.

Wenn Sie wissen möchten, wie jeder andere DNS ausführt und wie typische Unternehmensbereitstellungen unterstützt werden, lernen Sie Binden.

Wenn Ihr Ziel minimaler Aufwand und Support ist und Sie einigermaßen kompetent sind, hat djbdns einen weitaus geringeren Support-Aufwand.

Wenn Sie mehr auf der Neulingsseite des Zauns sind, wird es Ihnen wahrscheinlich leichter fallen, sich an die Arbeit zu machen, aber denken Sie daran, dass es viel wahrscheinlicher ist, dass es auf seltsame und verrückte Weise explodiert.

Wenn ich djbdns (und bind) nicht schon kenne, würde ich auch powerdns und maradns untersuchen, aber ich bezweifle, dass es für winzige Installationen besser ist als die djbdns-Suite.

Unabhängig davon sollten Sie dnscache (Teil der djbdns-Suite) auf localhost für den Resolver Ihres Systems ausführen, auch wenn Sie bind für die Werbung Ihres DNS im Internet verwenden.

Überspringe djbdns. Obwohl DJB ein Held ist, übertreibt er die Arroganz eines Mathematikers gegenüber Software. Die Tatsache, dass es sich beim Starten / Stoppen nicht wie andere Software verhält, könnte ein gutes Beispiel für eine clevere Technik zum Verwalten von Daemons sein. Aber Sie müssen die Dokumentation herausziehen, wenn Sie sie nicht regelmäßig verwenden, weil alles so anders ist. Wenn Sie es auf Systemen einrichten, die auch von anderen verwaltet werden, müssen Sie ihnen eine klare Dokumentation schreiben, die sie vollständig lesen müssen, um einfache Vorgänge ausführen zu können. Es ist niedlich, sogar klug, Sachen aus init herauszulaufen. Aber es ist auch abscheulich, überraschend und unüblich.

Außerdem habe ich Probleme mit djbdns gehabt, die schwerwiegende Probleme verursacht haben, weil ich darauf bestanden habe, nur die Standards und nicht die Software-Interoperabilität zu beachten. Die Behebung dieser Probleme war eine große Zeitverschwendung, da sie von geringfügigen Unterschieden bei DNS-Paketen abhing.

Außerdem weist djbdns in bestimmten Fällen ein seltsames Verhalten auf, das dazu führt, dass Benutzer, die Ihren DNS-Server mit anderen Tools als djbs (z. B. mit nslookup) reparieren, überraschende Ergebnisse erzielen. Sie werden Ihre Zeit damit verschwenden, zu erklären, "dass ich nur diesen obskuren DNS-Server mit dem Namen djbdns verwende. Das Problem ist, dass Ihre Diagnosetools eine seltsame Meldung anzeigen, die jedoch in Ordnung ist. Wenn Sie sich diese Paketerfassung ansehen, können Sie feststellen, Dies hat nichts mit dem Problem zu tun, das wir vor ein paar Monaten hatten, als djbdns nicht richtig mit Ihrem DNS-Server zusammengearbeitet hat Teamkollegen eine Stunde, um den DNS-Server neu zu starten. "

Ähnliche Probleme mit qmail gibt es überall.

Die Einrichtung von djbdns ist etwas lehrreiches, wenn Sie die Frage stellen und Zeit zum Töten haben. Sie können auch viel lernen, indem Sie einfach die Website von djb lesen.

Es gibt zwei Arten von Sicherheitsproblemen. Sicherheitslücken, die einem Angreifer den Zugriff auf das System ermöglichen - djbdns hat fast definitiv keine davon. Vor einigen Jahren hatte bind einige peinliche in kurzer Zeit entdeckt und auch ein schlechtes Design aufgedeckt. Ich würde erwarten, dass es in diesen vielen Jahren komplett neu geschrieben wurde. Wenn Sie in dieser Hinsicht wirklich sicher sein möchten, führen Sie es unter einer virtuellen Maschine (z. B. Xen) aus. Berücksichtigen Sie auch, dass Sie auf einem Linux-System mit SELinux im Zielmodus ein Setup für bind haben und sich wahrscheinlich nicht mit einem für djbdns beschäftigen werden. Das bind + SELinux-System ist möglicherweise sicherer.

Das andere Problem ist die Sicherheit gegen Cache-Vergiftungen. Ich vermute, dass djbdns besser war, als es veröffentlicht wurde, und bind ist jetzt wahrscheinlich besser, weil es mehr Aufmerksamkeit schenkt. Dies ist wahrscheinlich die Ursache für Ihr Gehör, dass die Bindung unsicher ist, es sei denn, "richtig konfiguriert". Sie sollten dieses Problem zumindest untersuchen und verstehen. Dabei werden Sie wahrscheinlich herausfinden, welche Konfigurationsrisiken für beide DNS-Server bestehen.

Verhalten unter hoher Last ist für die meisten Benutzer ein Unsinnskriterium. Achten Sie auf die Leistung, die als Kriterium für die Bewertung von Software verwendet wird, bei der es sich selten um einen Leistungsengpass handelt. Sie hosten keinen DNS-Cache-Server für eine große Benutzerbasis, auf dem möglicherweise Anfragen mit einer erheblichen Rate eingehen. Sie führen autorisierendes DNS aus, um Dienste bereitzustellen, die wahrscheinlich auf demselben System ausgeführt werden. Diese Dienste sind tausende Male teurer als DNS. Ihre Internetverbindung reicht möglicherweise nicht einmal aus, um Ihren DNS-Server stark zu belasten. Wenn Sie jedoch eine derart hohe Belastung für die von Ihnen bereitgestellten Dienste erhalten, ist DNS wahrscheinlich kein Engpass.

Vielleicht möchten Sie einen Blick auf MaraDNS werfen , einen sicherheitsbewussten DNS-Server.

• Sichern. MaraDNS hat einen Sicherheitsverlauf, der so gut oder besser ist als jeder andere DNS-Server. Beispielsweise hat MaraDNS die Abfrage-ID und den Quellport von DNS-Abfragen immer mithilfe eines sicheren Zufallszahlengenerators randomisiert. und war nie anfällig für den "neuen" Cache-Vergiftungsangriff.

• Unterstützt. MaraDNS wird seit langem gepflegt und aktualisiert. MaraDNS wurde ursprünglich im Jahr 2001 erstellt. MaraDNS 1.0 wurde im Jahr 2002 und MaraDNS 1.2 im Dezember 2005 veröffentlicht. MaraDNS wurde ausgiebig getestet, sowohl mit einem SQA-Prozess als auch mit über vier Jahren Praxiserfahrung. MaraDNS wird weiterhin voll unterstützt: Die neueste Version wurde am 13. Februar 2009 veröffentlicht. Deadwood, der Code, der Teil von MaraDNS 2.0 wird, wird derzeit aktiv weiterentwickelt.

• Einfach zu verwenden. Eine grundlegende rekursive Konfiguration benötigt nur eine einzige dreizeilige Konfigurationsdatei. Eine grundlegende autorisierende Konfiguration benötigt nur eine vierzeilige Konfigurationsdatei und eine einzeilige Zonendatei. MaraDNS ist vollständig dokumentiert und enthält sowohl einfach zu befolgende Tutorials als auch ein vollständiges und aktuelles Referenzhandbuch.

• Klein. MaraDNS eignet sich gut für eingebettete Anwendungen und andere Umgebungen, in denen der Server die absolut geringstmögliche Anzahl von Ressourcen verwenden muss. Die Binärdatei von MaraDNS ist kleiner als die aller anderen derzeit verwalteten rekursiven DNS-Server.

• Open Source. MaraDNS ist vollständig Open Source. Die Lizenz ist eine BSD-Lizenz mit zwei Klauseln, die fast identisch mit der FreeBSD-Lizenz ist.

Auf der Seite von maraDNS advocacy finden Sie einen Vergleich verschiedener DNS-Serversoftware, die Ihnen bei der Auswahl helfen können.

Wenn Sie DNS nur für sich selbst ausführen, ist djbdns das bessere Softwarepaket. Es war eines der wenigen Softwarepakete, bei denen das größte DNS-Sicherheitsproblem des letzten Jahres festgestellt wurde, und es wurde erstellt / gepatcht, um es Jahre zuvor zu beheben. Für das DNS-Caching installiere ich dnscache (Teil von djbdns) auf allen Servern, die nicht als autorisierende DNS-Server ausgeführt werden. Es funktioniert bei den meisten Artikeln besser als BIND, aber angesichts der heutigen Hardware ist das zusätzliche Gewicht und die langsamere Geschwindigkeit von BIND kein Problem.

Aus Erfahrung lerne ich die Grundlagen von BIND, unabhängig davon, welches Paket Sie ausführen möchten.

Djbdns ist so eingestellt, dass es über die Befehlszeile sehr einfach zu verwalten ist. Alle Änderungen an DNS-Daten werden als Befehle ausgeführt. In BIND bearbeiten Sie eine Reihe von Textdateien.

Sie können Pakete für beide bekommen. Ich betrachte den Unterschied als IE gegenüber anderen Browsern. IE ist eingebaut und funktioniert für viele Dinge und ändert sich nicht von der Standardeinstellung. Djbdns ist anders und erfordert unterschiedliche Kompromisse. Für einen ISP kann der Wechsel von BIND zu djbdns etwas schwierig sein, da BIND standardmäßig Caching und Name Serving ausführt, wobei djbdns dies in zwei Teile aufteilt. Diese bevorzugte Sicherheitslösung ist jedoch schwieriger einzurichten, sodass sich viele BIND-Installationen nicht darum kümmern.

Persönlich würde ich sagen, dass Sie die Grundlagen von BIND als Referenz erlernen müssen, aber wenn Sie sich für etwas anderes entscheiden, werden Sie für die Zukunft ein zufriedener Systemadministrator sein :)

Die meisten Stellen, an denen ich in der ISP-Branche gearbeitet habe, scheinen von djbdns Gebrauch zu machen. Es bietet hervorragende Bausteine ​​und Grundlagen, um "verwaltete" Dienste zu überlagern - das Schreiben von Skripten zum Generieren von Zonendateien ist ziemlich trivial, dh Sie können alle Ihre DNS-Daten speichern in SQL sowieso. Es verarbeitet eine lächerliche Menge von Abfragen pro Sekunde und ist sicher zu booten.

Wenn Sie es skalieren müssen, werfen Sie einfach einen Blick auf http://haproxy.1wt.eu und stecken Sie ein paar autorisierende Server dahinter! Ich würde auch dringend empfehlen, die Resolver von autorisierenden Servern in jedem Setup, das Sie bereitstellen möchten, aufzuteilen.

Weitere lesenswerte Themen sind MaraDNS und PowerDNS.

Ich benutze FreeBSD hauptsächlich für diese Art von Dingen und da es Bundles mit BIND gibt, habe ich nie wirklich die Mühe gemacht, etwas anderes zu lernen. Wie auch immer ich finde, BIND ist ziemlich einfach zu konfigurieren und da es von FreeBSD unter Sicherheitsaspekten gepflegt wird, muss ich diesen Kanal nur auf Sicherheitsprobleme hin verfolgen.

Ich schätze, die beste Wahl für Sie ist, beide zu testen und herauszufinden, welche am besten zu Ihnen passt, es sei denn, Sie verwenden ein Betriebssystem, das mit einem der beiden mitgeliefert wurde.

Wenn Sie mehr über DNS erfahren möchten, ist eine Kopie des O'Reilly-Buches " DNS and BIND " und die neueste Version von bind wahrscheinlich der beste Weg.

Es ist wahr, dass BIND in seinem Leben mehr Sicherheitsprobleme hatte. dnjdns hatte bis letztes Jahr keine, aber es hat eine ganz andere Architektur als BIND und Sie werden es möglicherweise schwieriger finden, wenn Sie nicht mit der Funktionsweise des Benennungssystems vertraut sind.

Wenn Sie sich nur mit dem Betreiben eines DNS- Servers befassen möchten (im Gegensatz zum Erlernen der Protokolle und dergleichen), sollten Sie sich nur eines aussuchen und darin eintauchen. Ich gehe davon aus, dass Sie für beide Pakete Binärpakete finden in welcher * nix Distribution auch immer du dich entscheidest. Abgesehen davon bietet das Kompilieren aus dem Quellcode mit Software einige Vorteile, die möglicherweise neu erstellt werden müssen, wenn eine Sicherheitslücke gemeldet wird.

Wie bei jedem internetbasierten Dienst ist ein gesunder Menschenverstand und ein pragmatisches Denken der beste Weg, unabhängig davon, welche Software Sie verwenden. Wenn Sie dynamische Updates aktivieren müssen, stellen Sie sicher, dass diese signiert sind. Wenn Sie Zonenübertragungen zulassen, schränken Sie ein, wer diese von Ihrem Server usw. ausführen darf.

BINDEN.

Wenn Sie lernen, wie man es konfiguriert (während Sie eine ganze Reihe von etwas mühsamen DNS-bezogenen RFCs lesen), können Sie in Zukunft problemlos zu einem anderen DNS-Server wechseln (für welche Zwecke auch immer). Ich verwende BIND als primären und sekundären Server unter FreeBSD, Linux und sogar auf dem Vista-Laptop (für VMware NAT-Hosts).

Übrigens macht es Spaß, die Quelle von BIND zu lesen und herauszufinden, wie beispielsweise klassische Funktionen wie gethostbyname () oder gethostbyaddr () funktionieren.

Nachdem ich jahrelang Bind verwendet hatte, wurde mir klar, dass die meisten meiner Server überhaupt keinen eigenen DNS-Daemon ausführen müssen. Dies trifft möglicherweise nicht auf Sie zu, aber denken Sie darüber nach: Praktisch jeder Domain-Registrar bietet heutzutage an, Ihre DNS-Einträge für Sie zu servern (und bietet Ihnen normalerweise eine webbasierte Möglichkeit, Ihre DNS-Einträge zu bearbeiten). Sie übernehmen die Bereitstellung der Informationen, die Verwaltung der Sekundärdateien usw. Wenn Ihr Server nicht mehr auf DNS-Abfragen antworten muss, muss Ihr Server nur noch DNS-Suchvorgänge durchführen. Dafür verweise ich meine /etc/resolv.conf auf 4.2.2.1 und 4.2.2.2, die die Level3 "Anycast" DNS-Server sind und recht schnell und zuverlässig zu sein scheinen.

Ein zusätzlicher Bonus ist, dass die Firewall-Konfiguration für Ihren Server kein DNS mehr zulassen muss. Sie müssen nur die "etablierte, verwandte" Regel anwenden, damit die DNS-Abfragen Ihres Servers funktionieren.

Okay, Sie haben nicht gefragt, ob Sie einen DNS-Daemon ausführen müssen, aber diese Frage habe ich beantwortet. Um vollständig zu sein, wenn Sie feststellen, dass Sie eines ausführen müssen, empfehle ich, bei bind zu bleiben, da es so häufig verwendet wird, dass Sie eine Menge Dokumentation finden und mithelfen können, das zu tun, was Sie wollen.