Frage Warum ist georedundantes DNS für kleine Sites erforderlich?


Das ist ein Kanonische Frage über DNS-Geo-Redundanz.

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

  • Schutz vor Datencenter-Katastrophen. Erdbeben passieren. Brände ereignen sich in Racks und entfernen in der Nähe befindliche Server und Netzwerkgeräte. Mehrere DNS-Server werden Ihnen nicht viel nützen, wenn physische Probleme im Datencenter beide DNS-Server auf einmal ausschalten, selbst wenn sie nicht in derselben Zeile sind.

  • Schutz vor Upstream-Peer-Problemen. Mehrere DNS-Server verhindern keine Probleme, wenn ein freigegebener Upstream-Netzwerk-Peer ein Dreck-Nickerchen macht. Unabhängig davon, ob das Upstream-Problem Sie vollständig offline schaltet oder alle DNS-Server von einem Bruchteil Ihrer Benutzerdatenbank isoliert, können Benutzer nicht auf Ihre Domäne zugreifen, selbst wenn sich die Dienste selbst in einem vollständig anderen Datencenter befinden.

Das ist alles gut und gut, aber sind redundante DNS-Server wirklich notwendig, wenn ich alle meine Dienste von derselben IP-Adresse aus betreibe? Ich kann nicht sehen, wie mir ein zweiter DNS-Server einen Vorteil bringen würde, wenn niemand auf irgendeine Weise von meiner Domain versorgt werden könnte.

Ich verstehe, dass dies als Best Practice gilt, aber das scheint wirklich sinnlos!


30
2017-08-01 06:22


Ursprung


Semi-verwandt: Sollten wir unsere eigenen Nameserver hosten? - Andrew B


Antworten:


Hinweis: Inhalt in Streit, beziehen sich auf Kommentare für beide Antworten. Es wurden Fehler gefunden und diese Q & A muss überarbeitet werden.

Ich entferne das Akzeptieren von dieser Antwort vorläufig, bis der Zustand dieser kanonischen Q & A richtig adressiert ist. (Das Löschen dieser Antwort würde auch die angehängten Kommentare löschen, was nicht die Art und Weise ist, IMO zu verwenden. Dies wird wahrscheinlich nach einer umfangreichen Bearbeitung in eine Community-Wiki-Antwort umgewandelt.)


Ich könnte RFCs hier zitieren und technische Begriffe verwenden, aber das ist ein Konzept, das von verpasst wird viel von Menschen an beiden Enden des Wissensspektrums und ich werde versuchen, dies für das breitere Publikum zu beantworten.

Ich verstehe, dass dies als Best Practice gilt, aber das scheint wirklich sinnlos!

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

Rekursive Server sind sehr Gut, wenn remote Server nicht auf eine Abfrage reagieren, insbesondere wenn sie es erneut versuchen und immer noch keine Antwort erhalten. Viele implementieren negative Zwischenspeicherung dieser Kommunikationsfehlerund wird vorübergehend nicht reagierende Nameserver für einen Zeitraum von nicht mehr als fünf Minuten in die Strafbox setzen. Diese Frist endet und die Kommunikation wird fortgesetzt. Wenn die fehlerhafte Abfrage erneut fehlschlägt, geht sie direkt zurück in die Box, ansonsten geht es wieder wie gewohnt weiter.

Hier stoßen wir auf das Problem des einzelnen Nameservers:

  • Die Strafzeit ist naturgemäß von der Umsetzung abhängig immer größer oder gleich der Dauer des Netzwerkproblems sein. In fast allen Fällen wird es größer, bis zu weiteren fünf Minuten.
  • Wenn Ihr einzelner DNS-Server in die Strafbox geht, ist die mit dem Fehler verbundene Abfrage für die gesamte Dauer vollständig inaktiv.
  • Kurze Routing-Unterbrechungen passieren im Internet mehr als die meisten Leute erkennen. TCP / IP-Übertragungswiederholungen und ähnliche Anwendungssicherungen machen es gut, dies vor dem Benutzer zu verbergen, aber es ist etwas unvermeidbar. Das Internet macht eine gute Arbeit, um diesen Schaden größtenteils durch Sicherheitsvorkehrungen zu umgehen, die in den verschiedenen Standards eingebaut sind, die den Netzwerkstack unterstützen ... aber das schließt auch diejenigen ein, die in DNS eingebaut sind und georedundante DNS-Server haben Teil davon.

Lange Rede, kurzer Sinn, wenn Sie mit einem einzigen DNS-Server arbeiten (dazu gehört die mehrfache Verwendung derselben IP-Adresse) NS Aufzeichnungen), wird dies passieren. Es wird auch viel mehr passieren, als du denkst, aber das Problem wird so sporadisch sein, dass die Chancen des Scheiterns 1) dir gemeldet werden, 2) reproduziert werden, und 3) an dieses spezifische Problem gebunden zu sein, sind extrem nah Null. Sie ziemlich wurden Null, wenn Sie in diese Fragen und Antworten kamen, ohne zu wissen, wie dieser Prozess funktioniert hat, aber zum Glück sollte das jetzt nicht der Fall sein!

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


33
2017-08-01 06:22



Manche Systeme sind hoffnungslos davon abhängig, dass DNS-Lookups nicht fehlschlagen. Es ist ein gemeinsamer Punkt des Scheiterns, der eine Redundanz fehlt, die viel Ärger verursacht. - artifex
Mail, die im Cache gespeichert wird, ist ein klassisches Beispiel dafür, wie Sie sich mit DNS gleichzeitig und mit der restlichen Infrastruktur in den Fuß schießen können. Bei redundantem DNS stapelt Mail bei fehlender Site nur auf den Servern der Absender und wird nach der Wiederherstellung zugestellt. Bei einem einzelnen DNS wird eingehende E-Mails, die gesendet werden, während Sie nicht erreichbar sind, häufig von den Servern der Absender dauerhaft abgelehnt nicht existierende Domain oder ähnliche Fehler. Ausgehende E-Mails, die von peripheren (noch aktiven) Systemen gesendet werden, können ebenfalls fehlgeschlagen, da die Absenderdomäne derzeit nicht aufgelöst wird. - MadHatter
Ein Domain-Name ist in der Regel nicht nur Web, sondern auch E-Mail. Wenn Sie einen E-Mail-Dienstanbieter für Ihre Domain verwenden, sind diese möglicherweise nicht inaktiv, obwohl Ihr Webserver dies ist, und wenn Sie über redundante DNS verfügen, können Sie weiterhin E-Mails erhalten. - Jenny D
Die 5m ist nur die Wiederholungsperiode eines einzelnen Servers? Wird sich dies nicht mit vielen Servern in der Kette multiplizieren, und der Client wird auch schlechte Abfragen zwischenspeichern? - Nils
@Nils Kannst du das leicht umschreiben? Ich habe Probleme festzustellen, ob Sie viele Server in einem rekursiven Cluster oder viele autoritative Server meinen. Das 5-m-negative Caching-Intervall ist pro Server, so dass Sie viele Anfragen erhalten müssen, um einen einzelnen negativen Datensatz im Cache eines gesamten rekursiven Clusters zu speichern - was die Fehler noch sporadischer macht. - Andrew B


OP fragt:

Das ist alles gut und gut, aber sind redundante DNS-Server wirklich notwendig, wenn ich alle meine Dienste von derselben IP-Adresse aus betreibe? Ich kann nicht sehen, wie mir ein zweiter DNS-Server einen Vorteil bringen würde, wenn niemand auf irgendeine Weise von meiner Domain versorgt werden könnte.

Gute Frage!

Die beste Antwort wird geliefert von Professor Daniel J. Bernstein, Dr. Berkeley, der nicht nur ein weltberühmter Forscher, Wissenschaftler und Kryptologe ist, sondern auch eine sehr populäre und gut erhaltene DNS-Suite, bekannt als DJBDNS (zuletzt veröffentlicht am 2001-02-11, noch heute beliebt).

http://cr.yp.to/djbdns/third-party.html (2003-01-11)

Kosten und Nutzen von Drittanbieter-DNS-Diensten

Achten Sie auf diesen kurzen und prägnanten Teil:

Fehlerhafte Argumente für den DNS-Dienst von Drittanbietern

...

Die zweite Taktik besteht darin zu behaupten, dass weit verbreitete DNS-Clients etwas besonders Böses tun, wenn sie nicht alle DNS-Server erreichen können. Das Problem mit diesem Argument ist, dass die Behauptung falsch ist. Jeder dieser Kunden ist eindeutig fehlerhaft und wird nicht in der Lage sein, auf dem Markt zu überleben: Überlegen Sie, was passiert, wenn die Kunden Router werden kurz unterbrochen oder wenn das Netzwerk des Clients vorübergehend überflutet wird.

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

Ja, kurze zeitweilige Netzwerkausfälle von ein paar Sekunden kommen immer wieder vor. Nein, ein Fehler, einen Namen während eines solchen Ausfalls aufzulösen, wird nicht für eine bestimmte Anzahl von Minuten zwischengespeichert (anderenfalls hilft nicht einmal die beste Einrichtung von hochverfügbaren autoritativen Nameservern auf der Welt).

Jede Software, die die konservative Richtlinie der bis zu 5 Minuten aus dem RFC 1998-03 Cache-Ausfälle werden einfach durch das Design unterbrochen, und ein zusätzlicher georedundanter Server macht keine Delle.

In der Tat, wie Wie lange wird ein DNS-Timeout zwischengespeichert?, in BIND, der SERVFAIL Zustand war traditionell NICHT Zwischen 2014 und 2015 wird Cached standardmäßig für nur 1 Sekunde, weniger als das, was ein durchschnittlicher Benutzer benötigt, um ein Ziel zu erreichen Resolver-Zeitüberschreitung und drücke die Refresh-Taste erneut.

(Und noch bevor wir zu dem obigen Punkt kommen, ob ein Auflösungsversuch zwischengespeichert werden sollte oder nicht, braucht es mehr als ein paar verworfene Pakete, selbst wenn der erste SERVFAIL überhaupt auftritt.)

Darüber hinaus haben die BIND-Entwickler sogar ein Decke für das Feature, von nur 30s, die sogar als eine Decke (zB der maximale Wert, den die Funktion jemals annehmen wird), ist bereits 10 mal niedriger als die 5min (300s) Vorschlag aus dem RFC, so dass auch die am besten - Erwähnte Admins (der Augenbälle) werden nicht in der Lage sein, ihre eigenen Benutzer in den Fuß zu schießen.


Darüber hinaus gibt es viele Gründe, warum Sie können nicht möchte einen Drittanbieter-DNS-Dienst ausführen - lese das Ganze durch djbdns/third-party.html für alle Detailsund das Mieten eines winzigen zusätzlichen Servers, den nur DNS verwalten kann, ist kaum gerechtfertigt, wenn für ein solches Unterfangen kein anderer Bedarf als BCP 16 besteht.

In meiner persönlichen "anekdotischen" Erfahrung mit dem Besitz und der Einrichtung von Domainnamen seit mindestens 2002 kann ich Ihnen mit aller Gewissheit und Ehrlichkeit sagen, dass ich tatsächlich insgesamt eine hatte erhebliche Ausfallzeiten meiner verschiedenen Domains aufgrund der professionell betriebenen Drittanbieter-Server meiner Registrare und Hosting-Provider, die, jeweils ein Provider, und über die Jahre hinweg alle ihre Incidents hatten, nicht erreichbar waren, brachte meine Domains unnötig herunter, genau zur gleichen Zeit, als meine eigene IP-Adresse (wo HTTP und SMTP für eine bestimmte Domain gehostet wurde) von) war ansonsten voll erreichbar. Beachten Sie, dass diese Ausfälle mit mehreren unabhängigen, respektierten und professionell betriebenen Anbietern zusammenkamen und keineswegs nur vereinzelte Vorkommnisse sind, die sich jährlich ereignen, und als Service von Drittanbietern sind völlig außerhalb Ihrer Kontrolle; Es kommt einfach vor, dass nur wenige Menschen jemals darüber reden.


Zusamenfassend:

Das georedundante DNS ist für kleine Sites NICHTS notwendig.

Wenn du rennst alles Ihrer Dienstleistungen von der gleiche IP-AdresseDas Hinzufügen eines zweiten DNS führt am ehesten 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, ist in der Tat ein sehr populärer Mythos; GEHACKT.

Natürlich wäre der Rat völlig anders, sollten einige der Dienste der Domäne, sei es Web (HTTP / HTTPS), Mail (SMTP / IMAP) oder Sprache / Text (SIP / XMPP), bereits von Drittanbietern bedient werden Anbieter, in welchem ​​Fall die Beseitigung Ihrer eigenen IP als ein Single-Point-of-Failure wäre in der Tat ein sehr kluger Ansatz, und Geo-Redundanz wäre in der Tat sehr nützlich.

Ebenso, wenn Sie eine besonders beliebte Website 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 zutrifft. Viel Glück!


-3
2018-01-06 19:00



Während ich mehr als glücklich bin, etablierte Experten einzuladen, um beide Antworten zu überprüfen, bekomme ich mehr als nur eine kleine Atmosphäre von Theatralik aus diesem Wort. Während ich akzeptieren werde, welche Meinungen auch immer von Parteien abgegeben werden, deren Meinung ich mehr vertraue als du oder meins, entscheide ich mich dafür, mich von der weiteren Teilnahme an diesem Kommentar zu verabschieden. - Andrew B
Ich bin mir nicht sicher, was dein Kommentar sagen soll. Du hast deine eigene Frage mit einem Argument beantwortet, das laut dem Punkt in meiner Antwort, der direkt von DJB zitiert wurde, einfach ungültig ist. Deine Antwort ist falsch. Als solcher machst du der Gemeinschaft einen schlechten Dienst, indem du einen Mythos aufrechterhältst. Wenn Sie Ihre Antwort rückgängig machen und meine akzeptieren möchten, nehme ich gerne konstruktive Kritiken / Bearbeitungen an. - cnst
Gute Software erkennt eine SERVFAIL-Antwort (die von einem rekursiven Server erzeugt wird, wenn keiner der autorisierenden Server erreicht werden kann) und handhabt sie entsprechend, d. H. Indem sie SMTP-Mail in eine Warteschlange stellt. Leider ist nicht jede Software gut. Es gibt einen gewissen Professor, dessen dogmatische Vorgehensweise bei der Implementierung von Protokollen bekanntermaßen zu erheblichen Interoperabilitätsproblemen führt ... - Alnitak
Der aktuelle Stand der Branche und das, was frei herumliegt, ist weitaus relevanter als alles andere seit 2003, ganz zu schweigen von 2001. Aus diesem Grund waren relevante Stellungnahmen Dritter wertvoller als die Beurteilung der Angelegenheit durch einen datierten Leitartikel, der jedoch hätte führen können überlebte möglicherweise den Test der Zeit. Alnitak wies darauf hin, dass meine Erinnerung daran, wie BIND diesen Fall gehandhabt hat, ein Fehler war, und dass ich diese Erinnerung mit Worten aus RFC 2308 bekräftigte, war in der Tat falsch. Die Retraktion wird diese Woche folgen, wenn ich Zeit finde. - Andrew B
Randnotiz: Ich habe darauf verzichtet, Sie zu engagieren, um einen sachlichen Fehler meinerseits anzuerkennen, aber es scheint, als wären wir wieder im Grenzgebiet der Kriegsführung. Ich entschuldige mich für die Verbreitung von Fehlinformationen und habe den Fehler bestätigt, aber ich möchte Sie nicht weiter engagieren. (noch soll ich, wie Sie scheinen, eine Geschichte davon hier zu haben) - Andrew B