Warum ist georedundantes DNS für kleine Websites erforderlich?

31

Dies ist eine kanonische Frage zur DNS-Georedundanz.

Es ist allgemein bekannt, dass georedundante DNS-Server, die sich an verschiedenen physischen Standorten befinden, für die Bereitstellung ausfallsicherer Webdienste äußerst wünschenswert sind. Dies wird ausführlich in Dokument BCP 16 behandelt , aber einige der am häufigsten genannten Gründe sind:

  • Schutz vor Datencenter-Katastrophen. Erdbeben passieren. Brände ereignen sich in Racks und nehmen in der Nähe befindliche Server und Netzwerkgeräte heraus. Mehrere DNS-Server helfen nicht viel, wenn physische Probleme im Rechenzentrum beide DNS-Server gleichzeitig ausschalten, auch wenn sie nicht in derselben Reihe stehen.

  • Schutz vor vorgelagerten Peer-Problemen. Mehrere DNS-Server verhindern keine Probleme, wenn ein gemeinsam genutzter Upstream-Netzwerk-Peer ein Nickerchen macht. Unabhängig davon, ob das Upstream-Problem Sie vollständig offline macht oder alle Ihre DNS-Server von einem Bruchteil Ihrer Nutzerbasis isoliert, ist das Endergebnis, dass Benutzer nicht auf Ihre Domain zugreifen können, selbst wenn sich die Services in einem völlig anderen Rechenzentrum befinden.

Das ist alles in Ordnung und gut, aber sind redundante DNS-Server wirklich notwendig, wenn ich alle meine Dienste mit derselben IP-Adresse ausführe? Ich kann nicht sehen, wie ein zweiter DNS-Server mir Vorteile bringen würde, wenn ohnehin niemand auf etwas zugreifen kann, das von meiner Domain bereitgestellt wird.

Ich verstehe, dass dies eine bewährte Methode ist, aber das scheint wirklich sinnlos!

Andrew B
quelle

Antworten:

33

Hinweis: Streitige Inhalte finden Sie in den Kommentaren für beide Antworten. Es wurden Fehler gefunden, und diese Fragen und Antworten bedürfen einer Überarbeitung.

Ich entferne vorerst das Akzeptieren aus dieser Antwort, bis der Status dieser kanonischen Fragen und Antworten ordnungsgemäß behoben ist. (Wenn Sie diese Antwort löschen, werden auch die angehängten Kommentare gelöscht. Dies ist nicht der richtige Weg, um IMO zu nutzen. Möglicherweise wird daraus nach einer umfangreichen Bearbeitung eine Community-Wiki-Antwort.)


Ich könnte hier RFCs zitieren und technische Ausdrücke verwenden, aber dieses Konzept wird von vielen Menschen auf beiden Seiten des Wissensspektrums vermisst und ich werde versuchen, es für ein breiteres Publikum zu beantworten.

Ich verstehe, dass dies eine bewährte Methode ist, aber das scheint wirklich sinnlos!

Es mag sinnlos erscheinen ... aber es ist eigentlich nicht!

Rekursive Server können sich sehr gut erinnern, wenn Remoteserver auf eine Abfrage nicht antworten, insbesondere, wenn sie es erneut versuchen und immer noch keine Antwort erhalten. Viele implementieren eine negative Zwischenspeicherung dieser Kommunikationsfehler und setzen vorübergehend nicht reagierende Nameserver für einen Zeitraum von nicht mehr als fünf Minuten in die Strafbox. Irgendwann läuft diese "Straf" -Periode ab und sie nehmen die Kommunikation wieder auf. Wenn die fehlerhafte Abfrage erneut fehlschlägt, kehren sie direkt in die Box zurück, andernfalls wird wieder wie gewohnt verfahren.

Hier stoßen wir auf das einzelne Nameserver-Problem:

  • Die Strafzeit wird von Natur aus immer länger oder gleich der Dauer des Netzwerkproblems sein. In fast allen Fällen ist dieser Wert höher und beträgt maximal weitere fünf Minuten.
  • Wenn Ihr einzelner DNS-Server in das Straffeld eintritt, ist die mit dem Fehler verbundene Abfrage für die gesamte Dauer vollständig ungültig.
  • Kurze Routing-Unterbrechungen treten im Internet häufiger auf, als die meisten Leute glauben. TCP / IP-Neuübertragungen und ähnliche Schutzmaßnahmen für Anwendungen tun gut daran, dies vor dem Benutzer zu verbergen, sind jedoch unvermeidlich. Das Internet leistet einen guten Beitrag zur Umgehung dieses Schadens, zum größten Teil aufgrund von Sicherheitsvorkehrungen, die in den verschiedenen Standards enthalten sind, die den Netzwerkstapel unterstützen. Dazu gehören jedoch auch die in DNS eingebauten und georedundanten DNS-Server ein Teil davon.

Um es kurz zu machen: Wenn Sie mit einem einzelnen DNS-Server arbeiten (dazu gehört auch die mehrfache Verwendung derselben IP-Adresse in NSDatensätzen), wird dies passieren. Es wird auch viel mehr passieren, als Sie denken, aber das Problem wird so sporadisch sein, dass die Wahrscheinlichkeit, dass der Fehler 1) Ihnen gemeldet wird, 2) reproduziert wird und 3) mit diesem spezifischen Problem verbunden ist, extrem nahe ist Null. Sie ziemlich viel waren Null , wenn Sie kam in das Q & A nicht zu wissen , wie dieser Prozess funktioniert, aber Gott sei Dank , dass sollte der Fall jetzt nicht sein!

Sollte dich das stören? Es ist nicht wirklich mein Platz zu sagen. Einige Leute interessieren sich überhaupt nicht für dieses fünfminütige Unterbrechungsproblem, und ich bin nicht hier, um Sie davon zu überzeugen. Ich bin hier, um Sie davon zu überzeugen, dass Sie tatsächlich etwas opfern, indem Sie nur einen einzigen DNS-Server ausführen, und zwar in allen Szenarien.

Andrew B
quelle
1
Einige Systeme sind auch hoffnungslos darauf angewiesen, dass DNS-Lookups nicht fehlschlagen. Dies ist eine häufige Fehlerursache, bei der es an einer Redundanz mangelt, die viele Probleme verursacht.
Artifex
18
Die zwischengespeicherte E-Mail ist ein klassisches Beispiel dafür, wie Sie sich mit heruntergefahrenem DNS und dem Rest Ihrer Infrastruktur in den Fuß schießen können. Bei redundantem DNS werden E-Mails, wenn Ihre Site inaktiv ist, nur auf den Servern der Absender in die Warteschlange gestellt und nach der Wiederherstellung zugestellt. Mit einem einzelnen DNS werden eingehende E-Mails, die während Ihrer Abwesenheit gesendet werden, häufig dauerhaft von Absenderservern mit nicht vorhandener Domäne oder ähnlichen Fehlern zurückgewiesen. Ausgehende E-Mails, die von Peripheriegeräten (noch in Betrieb) gesendet werden, können ebenfalls fehlschlagen, da die Absenderdomäne derzeit nicht aufgelöst wird.
MadHatter unterstützt Monica
5
Ein Domainname ist in der Regel nicht nur ein Webname, sondern auch eine E-Mail-Adresse. Wenn Sie einen E-Mail-Dienstanbieter für Ihre Domain verwenden, ist dieser möglicherweise nicht inaktiv, obwohl Ihr Webserver inaktiv ist. Wenn Sie über redundantes DNS verfügen, können Sie weiterhin E-Mails abrufen.
Jenny D sagt Reinstate Monica
Die 5m ist nur die Wiederholungsperiode eines einzelnen Servers? Wird dies nicht mit vielen Servern in der Kette multipliziert, und der Client wird auch fehlerhafte Abfragen zwischenspeichern?
Nils
@Nils Kannst du das etwas umformulieren? Ich habe Probleme beim Ermitteln, ob Sie viele Server in einem rekursiven Cluster oder viele autorisierende Server meinen. Das 5-minütige negative Caching-Intervall gilt für jeden Server. Daher müssen viele Anfragen eingehen, um ein einzelnes Datensatz-Negativ für einen gesamten rekursiven Cluster zwischenzuspeichern, was die Ausfälle noch sporadischer macht.
Andrew B
-1

OP fragt:

Das ist alles in Ordnung und gut, aber sind redundante DNS-Server wirklich notwendig, wenn ich alle meine Dienste mit derselben IP-Adresse ausführe? Ich kann nicht sehen, wie ein zweiter DNS-Server mir Vorteile bringen würde, wenn ohnehin niemand auf etwas zugreifen kann, das von meiner Domain bereitgestellt wird.

Gute Frage!

Die beste Antwort liefert Professor Daniel J. Bernstein, PhD Berkeley , der nicht nur ein weltberühmter Forscher, Wissenschaftler und Kryptologe ist, sondern auch eine sehr beliebte und gut aufgenommene DNS-Suite namens DJBDNS geschrieben hat ( zuletzt veröffentlicht 2001- 02-11 , bis heute beliebt).

http://cr.yp.to/djbdns/third-party.html (11.01.2003)

Kosten und Nutzen des DNS-Dienstes eines Drittanbieters

Achten Sie auf diesen kurzen und prägnanten Teil:

Fehlerhafte Argumente für den DNS-Dienst eines Drittanbieters

Die zweite Taktik ist, zu behaupten, dass weit verbreitete DNS-Clients etwas besonders Böses tun, wenn sie nicht in der Lage sind, alle DNS-Server zu erreichen. Das Problem mit diesem Argument ist, dass die Behauptung falsch ist. Ein solcher Client ist eindeutig fehlerhaft und kann auf dem Markt nicht bestehen. Überlegen Sie, was passiert, wenn die Router des Clients kurzzeitig ausfallen oder das Netzwerk des Clients vorübergehend überlastet ist.

Daher könnte die ursprüngliche Antwort auf diese Frage nicht falscher sein.

Ja, gelegentlich treten kurze, vorübergehende Netzwerkausfälle von einigen Sekunden Dauer auf. Nein, ein Fehler beim Auflösen eines Namens während eines solchen Ausfalls würde nicht für eine beliebige Anzahl von Minuten zwischengespeichert (andernfalls hilft es nicht, selbst die weltweit beste Konfiguration von hochverfügbaren autoritativen Nameservern zu haben).

Jede Software, die die konservative Richtlinie von bis zu 5 Minuten vom RFC 1998-03 bis zu Cachefehlern großzügig umsetzt, ist konstruktionsbedingt fehlerhaft , und ein zusätzlicher georedundanter Server ist kein Problem.

Tatsächlich laut Wie lange wird ein DNS-Timeout zwischengespeichert? In BIND wurde die SERVFAILBedingung traditionell vor 2014 überhaupt NICHT zwischengespeichert. Seit 2015 wird sie standardmäßig nur für eine Sekunde zwischengespeichert. Dies ist weniger, als ein durchschnittlicher Benutzer benötigt, um ein Resolver-Timeout zu erreichen und die Schaltfläche "Aktualisieren" erneut zu betätigen .

(Und noch bevor wir zum obigen Punkt kommen, ob ein Auflösungsversuch zwischengespeichert werden soll oder nicht, dauert es mehr als ein paar verworfene Pakete, selbst wenn das erste SERVFAIL überhaupt auftritt.)

Darüber hinaus haben die BIND-Entwickler sogar eine Obergrenze für das Feature von nur 30 Sekunden implementiert , die selbst als Obergrenze (z. B. der maximale Wert, den das Feature jemals akzeptieren wird) bereits zehnmal niedriger ist als der Vorschlag von 5 Minuten (300 Sekunden) vom RFC, um sicherzustellen, dass selbst die wohlmeinendsten Administratoren (der Eye-Ball-Benutzer) nicht in der Lage sind, ihren eigenen Benutzern in den Fuß zu schießen.


Darüber hinaus gibt es viele Gründe , warum Sie können nicht ein Drittanbieter - DNS - Dienst ausführen möchten - lesen Sie das ganze djbdns/third-party.htmlfür alle Details und einen kleinen Extra - Server nur für DNS zu verwalten Anmietung selbst kaum , wenn keine Notwendigkeit gerechtfertigt ist für ein solches Unterfangen gibt es ein anderes als das BCP 16.

In meiner persönlichen "anekdotischen" Erfahrung, seit mindestens 2002 Domain-Namen zu besitzen und einzurichten, kann ich mit aller Gewissheit und Ehrlichkeit sagen, dass ich tatsächlich insgesamt eine erhebliche Ausfallzeit meiner verschiedenen Domains aufgrund der professionell betriebenen hatte Die Server von Drittanbietern meiner Registrare und Hosting-Anbieter , die über die Jahre hinweg jeweils für einen Anbieter nicht verfügbar waren, haben meine Domains unnötig heruntergefahren, und zwar genau zu dem Zeitpunkt, an dem meine eigene IP-Adresse (wo Das HTTP und SMTP für eine bestimmte Domain wurde von gehostet) war ansonsten vollständig erreichbar. Beachten Sie, dass diese Ausfälle bei mehreren unabhängigen, angesehenen und professionell geführten Anbietern aufgetreten sind und keinesfalls ein Einzelfall sind. Sie treten jährlich auf und treten als Drittanbieter-Service auf.sind völlig außerhalb Ihrer Kontrolle ; Es kommt einfach so vor, dass nur wenige Menschen langfristig darüber sprechen.


Zusamenfassend:

Das georedundante DNS ist für kleine Standorte NICHT erforderlich.

Wenn Sie alle Ihre Dienste über dieselbe IP-Adresse ausführen, führt das Hinzufügen eines zweiten DNS höchstwahrscheinlich zu einem zusätzlichen Fehlerpunkt und wirkt sich nachteilig auf die weitere Verfügbarkeit Ihrer Domain aus. Die „Weisheit“ von immer es in jeder erdenklichen Situation zu tun hat , ist ein sehr beliebter Mythos, in der Tat; GEHACKT.

Der Ratschlag wäre natürlich völlig anders, wenn einige der Dienste der Domain, sei es Web (HTTP / HTTPS), Mail (SMTP / IMAP) oder Voice / Text (SIP / XMPP), bereits von Drittanbietern bedient würden In diesem Fall wäre es in der Tat sehr sinnvoll, die eigene IP als Single-Point-of-Failure zu eliminieren, und Georedundanz wäre in der Tat sehr nützlich.

Wenn Sie eine besonders beliebte Site mit Millionen von Besuchern haben und wissentlich die zusätzliche Flexibilität und den Schutz von georedundantem DNS gemäß BCP 16 benötigen, dann… verwenden Sie wahrscheinlich keinen einzigen Server / Site für Web / Mail / Stimme / Text bereits, so dass diese Frage und Antwort offensichtlich nicht zutreffen. Viel Glück!

cnst
quelle
Ich bin mehr als glücklich, etablierte Fachleute einzuladen, beide Antworten zu überprüfen, aber ich bekomme mehr als nur eine kleine Stimmung von Theatralik aus diesem Gerede. Obwohl ich die Meinungen von Parteien akzeptieren werde, denen ich weit mehr vertraue als Ihren oder meinen, entscheide ich mich, mich für eine weitere Teilnahme an diesem Kommentarthread zu entscheiden.
Andrew B
Ich bin nicht sicher, was Ihr Kommentar sagen soll. Sie haben Ihre eigene Frage mit einem Argument beantwortet, das gemäß dem in meiner Antwort dargestellten Punkt, der direkt von DJB zitiert wurde, einfach ungültig ist. Ihre Antwort ist falsch. Als solches tun Sie der Gemeinschaft einen schlechten Dienst, indem Sie einen Mythos aufrechterhalten. Wenn Sie Ihre Antwort widerrufen und meine annehmen möchten, nehme ich gerne konstruktive Kritik / Änderungen an.
6.
2
Gute Software erkennt eine SERVFAIL-Antwort (die von einem rekursiven Server generiert wird, wenn keiner der autorisierenden Server erreicht werden kann) und verarbeitet sie entsprechend, dh indem sie SMTP-Mail in die Warteschlange stellt. Leider ist nicht alle Software gut. Es gibt einen bestimmten Professor, dessen dogmatischer Ansatz bei der Implementierung von Protokollen bekanntermaßen erhebliche Interoperabilitätsprobleme verursacht ...
Alnitak
2
Der gegenwärtige Stand der Branche und der Natur ist weitaus relevanter als alles andere aus dem Jahr 2003, geschweige denn aus dem Jahr 2001. Aus diesem Grund waren einschlägige Stellungnahmen Dritter von größerem Wert, als die Angelegenheit anhand eines datierten Leitartikels zu beurteilen, auch wenn dies möglich gewesen wäre überlebte möglicherweise den Test der Zeit. Alnitak wies darauf hin, dass meine Erinnerung daran, wie BIND mit diesem Fall umgegangen war, fehlerhaft war, und dass ich diese Erinnerung mit Worten aus RFC 2308 untermauerte, war in der Tat trügerisch. Rückzug folgt diese Woche, da ich Zeit finde.
Andrew B
2
Randbemerkung: Ich habe mich darauf eingelassen, Sie nicht zu engagieren, um meinen sachlichen Fehler anzuerkennen, aber es scheint, als wären wir wieder auf dem Territorium der Grenzkämpfe. Ich entschuldige mich für die Verbreitung von Fehlinformationen und habe den Fehler bestätigt, aber ich möchte Sie nicht weiter beschäftigen. (Ich auch nicht, wie es scheint, haben Sie eine Geschichte davon hier)
Andrew B