DNS und seine Funktionsweise gehen möglicherweise mit mehr Missverständnissen, Legenden, Aberglauben und Mythologie einher als jeder andere Aspekt der IT.
Sogar diejenigen von uns, die wissen, dass wir im Wesentlichen lügen (oder zumindest drastisch vereinfachen), wenn wir über die "Ausbreitung" von Änderungen sprechen, tendieren immer noch dazu, den Begriff zu verwenden, um etwas zu beschreiben, das - gleichzeitig - extrem einfach und unkompliziert ist ... noch schwer zu erklären ... und hat nichts mit Propagierung per se zu tun, sondern alles mit Caching und Negativ-Caching, die beide eine wesentliche Komponente der Funktionsweise des Systems sind (und wohl auch, wie es einen völligen Zusammenbruch verhindert) sein eigenes Gewicht) - im Wesentlichen das Inside-Out, das Gegenteil der tatsächlichen "Ausbreitung", ziehen - nicht schieben.
Bei all den Sorgen und Problemen mit kurzen TTLs funktionieren sie meistens so oft, dass es in Ihrem Interesse liegt, sie einfach auszuprobieren. Wenn unsere Websites bei $ {day_job} von einer "alten" Plattform auf eine "neue" Plattform migrieren, bedeutet dies häufig, dass sie so migriert werden, dass nichts in der Infrastruktur gemeinsam genutzt wird. Mein erster Schritt bei einer solchen Migration besteht darin, die TTL weit genug vor der Kürzung auf 60 Sekunden zu senken, damit die alte TTL über mehrere Vielfache von sich selbst verfügt, was mir eine angemessene Sicherheit gibt, dass sich diese Übergangs-RRs mit kurzen TTLs "ausbreiten" werden . " Wenn ich für den Schnitt bereit bin, konfiguriere ich den alten Balancer¹ neu, um den Datenverkehr auf das neue System zu übertragen - über das Internet - so, dass der Balancer nicht mehr mehrere interne Systeme balanciert, sondern "
Dann schneide ich den DNS um und beobachte den neuen Balancer und den alten.
Ich bin immer wieder positiv überrascht, wie schnell der Übergang erfolgt. Die Überbleibsel scheinen fast immer Suchspinnen und "Health Checking" -Standorte von Drittanbietern zu sein, die sich unerklärlicherweise an die alten Aufzeichnungen halten.
Es gibt jedoch ein Szenario, das vorhersehbar zusammenbricht: Wenn die Browserfenster eines Benutzers geöffnet bleiben, bleiben sie in der Regel an der bereits erkannten Adresse hängen und bleiben häufig bestehen, bis alle Browserfenster geschlossen werden.
In der obigen Beschreibung finden Sie jedoch die Lösung für das Problem: Ein "Load Balancer" - genauer gesagt ein Reverse Proxy - kann das System sein, auf das Ihr exponierter DNS-Eintrag verweist.
Der Reverse-Proxy leitet die Anforderung dann an die richtige Ziel-IP-Adresse weiter, die er mithilfe eines zweiten "Dummy" -Hostnamens mit einer kurzen TTL auflöst, die auf den realen Back-End-Server verweist Dummy-DNS-Eintrag, Sie können sich auf eine schnelle und vollständige Umstellung verlassen.
Der Nachteil ist, dass Sie den Datenverkehr möglicherweise über eine unnötige zusätzliche Infrastruktur leiten oder redundant mehr für den Transport über mehrere Netzwerkgrenzen zahlen.
Es gibt Dienste, die diese Art von Funktionen auf globaler Ebene bereitstellen, und derjenige, mit dem ich am vertrautesten bin, ist CloudFront. (Höchstwahrscheinlich würde Cloudflare genau den gleichen Zweck erfüllen, da die wenigen Tests, die ich durchgeführt habe, darauf hindeuten, dass es sich auch richtig verhält, und ich bin sicher, dass es noch andere gibt.)
Obwohl CloudFront in erster Linie als CDN vermarktet wird, handelt es sich in seinem Kern um ein globales Netzwerk von Reverse-Proxies mit der Möglichkeit, die Antworten optional zwischenzuspeichern. Wenn www.example.comPunkte auf CloudFront und CloudFront so konfiguriert sind, dass diese Anforderungen an weitergeleitet werden backend.example.com, und der DNS-Eintrag für backend.example.comeine kurze TTL verwendet, wird CloudFront das Richtige tun, da diese kurze TTL berücksichtigt wird. Wenn sich der Back-End-Datensatz ändert, wird der gesamte Datenverkehr bis zum Ablauf der TTL migriert.
Die TTL auf dem Front-Side-Datensatz, die auf CloudFront verweist, und ob Browser und Caching-Resolver dies berücksichtigen, ist unwichtig, da Änderungen am Back-End-Ziel keine Änderungen im www.example.comDatensatz erfordern. Hinsichtlich des richtigen Ziels www.example.comist dies konsistent, unabhängig davon, wo sich das Back-End-System gerade befindet.
Dies löst für mich das Problem vollständig, indem der Browser von der Notwendigkeit befreit wird, Änderungen an der IP des Ursprungsservers zu "verfolgen".
tl; dr: Leiten Sie die Anforderungen an ein System weiter, das als Proxy für den realen Webserver dient, sodass nur die Proxy-Konfiguration die Änderung der IP-Adresse des Ursprungsservers berücksichtigen muss, nicht das browserbasierte DNS.
Beachten Sie, dass Cloudfront minimiert auch die Latenzzeit von einiger DNS Magie es auf der Vorderseite erlegt, die Ergebnisse in der www.example.comLösung auf die optimalste Cloudfront Randlage an der Stelle des Browser - basierte , das heißt die Abfrage www.example.com, so gibt es minimale Chance des Verkehrs ein unnötig Umwege nehmen Vom Browser über die Kante bis zum Ursprung ... aber dieser Teil ist transparent und automatisch und liegt außerhalb des Rahmens der Frage.
Natürlich kann das Zwischenspeichern von Inhalten auch von Nutzen sein, indem die Auslastung des Ursprungsservers oder des Transports verringert wird. Ich habe Websites auf CloudFront konfiguriert, auf denen sich der Ursprungsserver in einem ADSL-Netzwerk befand, und ADSL ist inhärent auf die Bandbreite im Upstream beschränkt. Der Ursprungsserver, zu dem CloudFront eine Verbindung herstellt, um den Inhalt abzurufen, muss kein Server im AWS-Ökosystem sein.
¹ Ich spreche von Balancer als einer einzigen Entität, wenn er tatsächlich mehrere Knoten hat. Wenn es sich bei dem Balancer um einen ELB handelt, fungiert ein Computer hinter dem Balancer als Dummy-App-Server und übernimmt die eigentliche Haarnadelung für den Balancer der neuen Plattform, da ELB dies nicht alleine durchführen kann.
² Das einzige Wissen des neuen Balancers über den alten Balancer besteht darin, dass er dem X-Forwarded-For des alten Balancers vertrauen muss und keine IP-basierte Ratenbeschränkung für die Quelladressen des alten Balancers vornehmen sollte.
³ Wenn es sich bei dem Proxy um einen oder mehrere Server handelt, die Sie steuern, haben Sie die Möglichkeit, die Verwendung von DNS auf der Rückseite und die Verwendung von IP-Adressen in der Proxy-Konfiguration zu überspringen. Für das nachfolgend beschriebene gehostete / verteilte Szenario ist jedoch diese zweite DNS-Schicht erforderlich .