Richtige Methode zum Einrichten von DNS-Primär / Sekundär /… für Redundanz und Latenzreduzierung?

Ich dachte, dass DNS primär / sekundär aus Redundanzgründen einfach ist. Meines Erachtens sollten Sie eine primäre und mindestens eine sekundäre Version haben und die sekundäre Version an einem geografisch anderen Ort, aber auch hinter einem anderen Router einrichten (siehe z. B. /server/48087 / Warum gibt es mehrere Nameserver für meine Domain? )

Derzeit haben wir zwei Nameserver in unserem Hauptdatenzentrum. Vor kurzem hatten wir einige Ausfälle aus verschiedenen Gründen, die beide Nameserver ausfielen, und ließen uns und unsere Kunden für einige Stunden ohne DNS arbeiten. Ich habe mein Sysadmin-Team gebeten, die Einrichtung eines DNS-Servers in einem anderen Rechenzentrum abzuschließen und ihn als sekundären Nameserver zu konfigurieren.

Unsere Systemadministratoren behaupten jedoch, dass dies nicht viel hilft, wenn das andere Rechenzentrum nicht mindestens so zuverlässig ist wie das primäre Rechenzentrum. Sie behaupten, dass die meisten Clients nach wie vor nicht ordnungsgemäß suchen oder das Zeitlimit zu lang ist, wenn das primäre Rechenzentrum ausfällt.

Persönlich bin ich davon überzeugt, dass wir nicht die einzige Firma sind, die ein solches Problem hat und dass es höchstwahrscheinlich bereits ein gelöstes Problem ist. Ich kann mir nicht vorstellen, dass all diese Internetfirmen von unserem Problem betroffen sind. Ich kann jedoch keine guten Online-Dokumente finden, die erklären, was in Fehlerfällen (z. B. Client-Timeouts) passiert und wie man sie umgeht.

Mit welchen Argumenten kann ich Löcher in die Argumentation unserer Sysadmins stecken? Gibt es Online-Ressourcen, auf die ich zurückgreifen kann, um die behaupteten Probleme besser zu verstehen?

Einige zusätzliche Hinweise nach dem Lesen der Antworten:

• Wir sind auf Linux
• Wir haben zusätzliche komplizierte DNS-Anforderungen. Unsere DNS-Einträge werden von einer benutzerdefinierten Software verwaltet, wobei BIND derzeit von einer Twisted DNS-Implementierung und einigen Ansichten in der Mischung abgeleitet ist. Wir sind jedoch in der Lage, unsere eigenen DNS-Server in einem anderen Rechenzentrum einzurichten.
• Ich spreche von autorisierendem DNS, damit Außenstehende unsere Server finden, nicht von rekursiven DNS-Servern für unsere lokalen Clients.

Es gibt ein wirklich großartiges, wenn auch recht technisches "Best Practices" -Dokument, das sich bei der Bekämpfung Ihres Sysadmin als nützlich erweisen kann. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Wenn er die Gültigkeit von Artikeln, die von Cisco verfasst wurden, nicht erkennt, können Sie genauso gut aufhören, mit dem Systemadministrator zu streiten.

In vielen anderen "Best Practices" -Dokumenten wird empfohlen, die primären und sekundären Nameserver nicht nur nach IP-Block, sondern auch nach physischem Standort zu trennen. Tatsächlich empfiehlt RFC 2182, sekundäre DNS-Dienste geografisch zu trennen. Für viele Unternehmen bedeutet dies, einen Server in einem anderen Rechenzentrum zu mieten oder einen gehosteten DNS-Anbieter wie ZoneEdit oder UltraDNS zu abonnieren .

Unsere Systemadministratoren behaupten jedoch, dass dies nicht viel hilft, wenn das andere Rechenzentrum nicht mindestens so zuverlässig ist wie das primäre Rechenzentrum. Sie behaupten, dass die meisten Clients nach wie vor nicht ordnungsgemäß suchen oder das Zeitlimit zu lang ist, wenn das primäre Rechenzentrum ausfällt.

Ah, der Fokus ist zuverlässig . Es hört sich so an, als würden sie auf Ihre Verbindung nach außen einwirken, anstatt sekundären DNS einzurichten. Richten Sie trotzdem sekundären DNS ein und fahren Sie von dort fort. Es wird bei der Ladung helfen und die Dinge zur Not aufbocken ... aber erkundigen Sie sich, warum sie denken, dass der andere Ort nicht zuverlässig ist .

Persönlich bin ich davon überzeugt, dass wir nicht die einzige Firma sind, die ein solches Problem hat und dass es höchstwahrscheinlich bereits ein gelöstes Problem ist. Ich kann mir nicht vorstellen, dass all diese Internetfirmen von unserem Problem betroffen sind.

Sie sind nicht das einzige Unternehmen, und dies wurde wahrscheinlich millionenfach in Unternehmen auf der ganzen Welt nachgearbeitet.

Ich kann jedoch keine guten Online-Dokumente finden, die erklären, was in Fehlerfällen (z. B. Client-Timeouts) passiert und wie man sie umgeht.

Mit welchen Argumenten kann ich Löcher in die Argumentation unserer Sysadmins stecken? Gibt es Online-Ressourcen, die ich konsultieren kann, um die behaupteten Probleme besser zu verstehen?

• Ich spreche von autorisierendem DNS, damit Außenstehende unsere Server finden, nicht von rekursiven DNS-Servern für unsere lokalen Clients.

Sie können alles Mögliche tun, einschließlich der Einrichtung eines externen DNS-Dienstes, der als Autorität für Ihre Zone registriert ist, die (externen) autorisierenden Server jedoch geheim zu Ihren eigenen (internen) DNS-Servern sekundär macht. Diese Konfiguration ist schrecklich, falsch, zeigt, dass ich wirklich ein böser SysAdmin bin und jedes Mal, wenn ich sie empfehle, ein Kätzchen stirbt. Aber es macht zwei Dinge:

• Sie veranlassen Ihren DNS-Dienst, die Last zu bewältigen und Fragen zur Kapazität Ihres eigenen (internen) DNS zu beantworten.
• Sie sorgen dafür, dass Ihr DNS-Dienst verfügbar bleibt, während Ihre internen DNS-Server möglicherweise nicht verfügbar sind. Es spielt also keine Rolle, wie zuverlässig Ihr Link ist - was zählt, ist, wie zuverlässig Ihr DNS-Dienstanbieter ist.

Die Gründe, warum dies falsch ist:

• Sie würden einen so genannten "Stealth-Nameserver" einrichten, da dieser zwar in Ihren Zonendatensätzen angezeigt wird und Sie die IP-Adresse nach dem Namen des Servers abfragen können, von außen jedoch nicht berührt wird. Client-Anfragen werden es nie erreichen.
• Obwohl Ihr DNS weiterhin einwandfrei funktioniert (da Ihr gehosteter Dienst das Problem beheben würde), bedeutet dies nicht, dass Websites, die Sie haben, funktionieren würden, wenn Ihre Internetverbindung unterbrochen wäre, das heißt, dass nur die Hälfte des Problems behoben wird . Es hört sich wirklich so an, als gäbe es andere Probleme, um die sich die Administratoren kümmern.

Leider scheint der Linux-DNS-Resolver keine direkte Unterstützung für die Erkennung und Durchführung von Failovers für DNS-Server zu bieten. Es sendet weiterhin Anfragen an Ihren primären auflösenden Nameserver, wartet auf eine konfigurierte Zeitüberschreitung, versucht es erneut usw.

Dies bedeutet häufig eine Verzögerung von bis zu 30 Sekunden für jede Anforderung. Ohne zuerst den sekundären zu probieren, solange der primäre ausgefallen ist.

Ich wollte das lösen, da unser Amazon EC2-auflösender Nameserver für viele unserer Mitarbeiter nicht erreichbar ist. Dies führt zu großen Verzögerungen in unseren Prozessen und in einigen Fällen sogar zu Ausfallzeiten, da wir auf eine Lösung angewiesen sind. Ich wollte ein gutes Failover für Google / Level3-Nameserver, falls Amazon erneut ausfällt. Und greifen Sie so schnell wie möglich zurück, da Amazon dann Hostnamen gegebenenfalls in lokale Adressen auflöst und so die Latenz für die Kommunikation zwischen Instanzen verringert.

Unabhängig vom Verwendungszweck ist jedoch ein besseres Failover erforderlich. Ich wollte das lösen. Ich wollte mich von Proxy-Dämonen, Diensten usw. fernhalten, da dies nur mehr Single Point Of Failures einführen würde. Ich wollte so archaisch und robust wie möglich arbeiten.

Ich entschied mich für crontab & bash und schrieb nsfailover.sh . Hoffe das hilft.

Es klingt so, als ob das Problem darin besteht, dass Clients , bei denen es sich um jeden handeln kann, zwei DNS-Server sehen. Wenn einer ausfällt, erfolgt entweder kein Failover auf den sekundären Server, oder es liegt eine lange Zeitüberschreitung vor.

Ich bin damit einverstanden, dass sich der primäre und der sekundäre DNS-Server als bewährte Methode an verschiedenen Standorten befinden sollten, aber ich verstehe nicht, wie dies dieses bestimmte Problem beheben könnte.

Wenn der Client darauf besteht, eine bestimmte IP-Adresse abzufragen, die IP-Adresse des sekundären Servers zu ignorieren (oder eine Weile zu warten, bis eine Zeitüberschreitung eintritt), müssen Sie einfach eine Lösung finden, die diese IP-Adresse funktionsfähig hält, auch wenn die Primärserver ist inaktiv.

Einige zu untersuchende Richtungen wären ein Load Balancer, der den Datenverkehr für eine einzelne IP-Adresse an mehrere Server in verschiedenen Rechenzentren umleiten kann. oder vielleicht Anycast-Routing.

Solange sich jedes Ihrer Rechenzentren in verschiedenen Stromkreisen befindet (idealerweise mit verschiedenen Upstream-Anbietern bis weit in die Cloud), können Sie mit nur zwei Rechenzentren ein ziemlich zuverlässiges DNS einrichten. Sie müssen lediglich sicherstellen, dass der Registrar Ihrer Wahl die entsprechenden Leimdatensätze auf die großen Server im Himmel überträgt.

Unser Setup ist:

• 2 physische Rechenzentren (separate Leitungen, ISPs und Upstream-Anbieter)
• 2 physische Abfrageserver in einem Cluster hinter einem SLB in jeder Einrichtung
• 2 Lastausgleichsgeräte, um bestimmte Datensätze bereitzustellen, für die das Gleichgewicht zwischen den beiden Datacetnern verwaltet werden soll
• Hidden Master intern zugänglich für beide Servercluster (ich glaube sehr stark an Hidden Master Setups für Sicherheit)

Dieses Setup war effektiv genug, um uns in den letzten 6 oder 7 Jahren eine Betriebszeit von ungefähr 5 9 zu ermöglichen, selbst wenn der Server gelegentlich wegen Updates ausfällt Hosting der Zone mit jemandem wie Ultradns ...

Die von KPWINC erwähnte Ladekonversation ist zu 100% korrekt. Wenn Ihr kleinstes Rechenzentrum nicht 100% Ihrer Last bewältigen kann, werden Sie wahrscheinlich trotzdem entbeint, da Ihr Ausfall dann eintritt, wenn Sie es am wenigsten wollen =)

Ich nehme die maximale Last von allen meinen Edge-Routern, addiere sie alle und dividiere dann durch 0,65 ... das ist die minimale Bandbreite, die wir in jedem Rechenzentrum haben müssen. Ich habe diese Regel vor ungefähr 5 Jahren eingeführt, mit einigen Dokumenten, die ich beim CCO und über das Internet gesammelt habe, um sie zu rechtfertigen, und sie hat uns nie enttäuscht. Sie müssen diese Statistiken jedoch mindestens vierteljährlich überprüfen . Wir hatten zwischen November und Februar letzten Jahres eine fast dreifache Zunahme unseres Verkehrs und ich war nicht darauf vorbereitet. Diese positive Seite ist, dass ich aufgrund der Situation einige sehr klare, harte Daten generieren konnte, die besagen, dass wir bei 72% Auslastung unserer WAN-Verbindung anfangen, Pakete zu verwerfen. Für mehr Bandbreite wurde von mir noch nie eine zusätzliche Begründung verlangt.

Beim Lesen Ihrer Beschreibung wurde mir klar, dass es nicht klar ist, ob Sie autorisierendes DNS für Außenstehende zum Auffinden Ihrer Server oder rekursive DNS-Server für Ihre lokalen Clients meinen. Das Verhalten dieser beiden ist sehr unterschiedlich.

Bei autorisierenden DNS-Servern sind die "Clients" andere DNS-Server, die über Caching und viel Intelligenz verfügen. Sie tendieren dazu, mehrere Server gleichzeitig zu testen, wenn der erste überhaupt langsam ist, und bevorzugen denjenigen, der ihnen schnellere Antworten gibt. In diesem Fall würde die Ausfallzeit für ein Rechenzentrum die Leistung nur geringfügig beeinträchtigen.

Bei rekursiven DNS-Servern sind die Clients Ihre lokalen Clients, auf denen wahrscheinlich die DNS-Server in DHCP aufgeführt sind. Sie probieren ihre Server jedes Mal in der angegebenen Reihenfolge aus, mit einer schmerzhaften Zeitüberschreitung (mehrere Sekunden), bevor sie vom ersten auf den zweiten Server wechseln.

Wenn Ihr primäres Rechenzentrum nicht erreichbar ist, kann sowieso niemand auf diese Server zugreifen. Oft sind die daraus resultierenden Fehler jedoch verständlicher als die Fehler von nicht erreichbaren DNS-Servern. "Server konnte nicht kontaktiert werden" oder "Zeitüberschreitung der Verbindung" anstelle von "Server konnte nicht gefunden werden" oder "Server nicht gefunden". Beispielsweise werden die meisten SMTP-Server eine Woche lang E-Mails in die Warteschlange stellen, wenn sie den Server im DNS sehen, ihn aber einfach nicht erreichen können. Wenn sie es in DNS überhaupt nicht finden können, lehnen sie es möglicherweise sofort ab, auch nur zu versuchen, es Ihrer Domain zuzustellen.

Sekundäres DNS, das geografisch und netzwerkgetrennt ist, ist eine gute Sache. Möglicherweise können Sie sekundäres DNS mit einer freundlichen Firma tauschen, und Sie können eine Vielzahl von DNS-Anbietern bezahlen, um dies für Sie zu tun. Einige Registrare haben auch sekundäres DNS als Dienst.

Thomas,

Nachdem ich Ihr Update gelesen habe, habe ich meinen Beitrag überarbeitet (der vorherige Beitrag bezieht sich auf Windows-Software).

Es hört sich für mich fast so an, als würden Ihnen Ihre Systemadministratoren sagen, dass Ihr sekundärer Standort nicht über die erforderliche Hardware verfügt, um die VOLLSTÄNDIGE LAST zu bewältigen?

Es hört sich so an, als würde er sagen: "Hey Kumpel, wenn unser primärer Standort (der den primären DNS enthält) ausfällt, ist DNS das WENIGSTE unserer Sorgen, denn wenn COLO1 ausfällt, kann COLO2 die Last sowieso nicht bewältigen."

In diesem Fall würde ich vorschlagen, dass Sie sich Ihre Infrastruktur ansehen und versuchen, ein besseres Design zu finden. Dies ist leichter gesagt als getan, besonders jetzt, wo Sie in einer Produktionsumgebung leben.

Abgesehen davon wären COLO1 und COLO2 in einer perfekten Welt in der Lage, allein zu stehen und Ihre Ladung zu handhaben.

Sobald dies geschehen ist, ist das DNS nichts weiter als genügend DNS-Server mit einer ausreichend schnellen Aktualisierung. Wenn eine Seite ausfällt, können Sie Ihr DNS neu schreiben, um auf die UP-Server zu verweisen.

Ich habe diese Methode in kleinen bis mittelgroßen Umgebungen verwendet und sie funktioniert hervorragend. Das Failover dauert in der Regel weniger als 10 Minuten.

Sie müssen nur sicherstellen, dass Ihre DNS-Server die zusätzliche Last einer kurzen TTL (Time to Live) verarbeiten können.

Hoffe das hilft.

Ihre Sysadmins liegen (meistens) falsch.

Die rekursiven Server, die Ihre autorisierenden Server abfragen, bemerken dies sehr schnell, wenn einer der Standorte nicht reagiert.

Ja, es besteht die Möglichkeit, dass Clients bei einem Ausfall nur geringfügige Verzögerungen bei der DNS-Auflösung feststellen. Es sind jedoch nur ein oder zwei Sekunden erforderlich, und sobald die eigenen DNS-Server des Clients erfahren haben, dass einer der Server außer Betrieb ist, werden sie verwendet Die verbleibenden Server werden dem ausgefallenen vorgezogen.

Führen Sie bei Bedarf (um die Systemadministratoren zu beruhigen) weiterhin zwei Server in Ihrem primären Rechenzentrum aus, stellen Sie jedoch mindestens einen weiteren Server nach außen.

Ein sekundärer DNS-Server schadet nie, je nachdem, wo er gehostet wird, bietet er Ihnen mehr oder weniger Funktionalität.

Wenn Ihr primärer Host ausfällt, kann ein sekundärer Host übernehmen, unabhängig davon, ob er sich neben dem Host oder an einem Remotestandort befindet. Wenn jedoch Ihre Datencenter-Uplink-Verbindung ausfällt, erhalten Sie möglicherweise weiterhin DNS-Antworten vom Server in einem anderen Datencenter, können Ihre Server jedoch ohnehin nicht erreichen. So können Ihre Endbenutzer nicht direkt vom sekundären DNS am Remotestandort profitieren.

Verschiedene Clients reagieren auf andere Art und Weise darauf, dass DNS-Server nicht verfügbar sind, sodass das Zeitlimit für Clients ein gewisses Maß an Wahrheit ist, jedoch nicht für alle.

Ein sekundärer DNS in einem Remote-Rechenzentrum kann jedoch weiterhin die IP-Adresse des Servers auflösen, den Sie erreichen möchten, sodass Sie das Routing debuggen und sehen können, wann sie wieder angezeigt werden. Und wenn Sie die sekundären MX-Server korrekt eingerichtet haben, gehen nicht einmal E-Mails verloren.