Ich habe meine TTL von 24 Stunden auf 5 Minuten geändert. Muss ich 24 Stunden warten, bevor ich die Aufzeichnungen ändere?

37

Ich migriere unsere App von einem Cloud-Server auf einem dedizierten Rackspace-Server.

Ich möchte die Anwendung für ca. 5 Minuten herunterfahren, um die Daten vom Cloud-Server auf den dedizierten Server zu kopieren. Ich möchte daher nicht, dass Anforderungen an den alten Server gesendet werden, nachdem ich die Daten kopiert habe.

Ich möchte unseren DNS-Eintrag auf den neuen Server verweisen, aber die TTL wurde auf 24 Stunden eingestellt. Ich habe es auf 300 Sekunden geändert. Muss ich die 24 Stunden warten, bevor ich die IP-Adresse aktualisiere, auf die die Domain verweist, oder die Daten kopiere?

domain-name-system  rackspace  ttl 
— wobbily_col
quelle
9
Übrigens, auch wenn Sie auf die TTL warten, empfehle ich dringend, die Konfiguration auf dem alten Server zu bearbeiten, um sicherzustellen, dass dort keine Updates mehr akzeptiert werden. Nicht alle DNS-Resolver folgen tatsächlich den Standards.
— Peter Green
5
Als ich eine Webanwendung von einem Hosting-Anbieter auf einen anderen umstellte, verwendete ich eine SSH-Portweiterleitung, um alle Besucher, die noch die alte IP-Adresse verwendeten, an den neuen Server weiterzuleiten.
— Kasperd

Antworten:

58

Jeder, der eine zwischengespeicherte Kopie des Domain-Datensatzes hat, wird sich nicht darum kümmern, ihn 24 Stunden lang zu aktualisieren. Wenn Sie also beabsichtigen, höchstens ein 5-minütiges Fenster der Nichtverfügbarkeit zu haben, sollten Sie warten, bis alle ausstehenden Caches aktualisiert wurden, um nicht mehr zu funktionieren als 5 Minuten.

— Jeff Meden
quelle
23
... es für 24 Stunden since they last cached it. Dies kann zwischen 1 und 86399 Sekunden liegen.
— user9517 unterstützt GoFundMonica
6
@Iain Sie müssen das Schlimmste annehmen, da einige oder alle es kurz vor der Änderung zwischengespeichert haben könnten.
— Barmar
6
@Barmar Nimm nichts an. Viele ISPs ignorieren TTL einfach.
— user9517 unterstützt GoFundMonica
13
@Iain Ich habe früher für Akamai gearbeitet, ein CDN, das kurze TTLs (wie 60 Sekunden) zum Lastenausgleich verwendet. Ich erinnere mich, dass wir eine Studie durchgeführt haben und festgestellt haben, dass die meisten ISPs unsere TTLs befolgt haben.
— Barmar
1
Ich arbeite für ein Webhosting-Unternehmen. Unsere Erfahrung zeigt, dass niedrige TTLs eher ignoriert werden als höher.
— Henrik - hör auf Monica
39

Es ist (möglicherweise) sogar noch schlimmer - Sie müssen 24 Stunden warten, nachdem alle autorisierenden Server aktualisiert wurden. Normalerweise werden Aktualisierungen durchgeführt, indem Sie eine Änderung an der Zone auf dem Primärserver vornehmen und dann die neuen Zonendaten von jedem Sekundärserver übertragen, wenn er das nächste Mal beim Primärserver eincheckt. Die Eincheckfrequenz wird durch das Aktualisierungsintervall im SOA-Datensatz der Zone gesteuert. Im schlimmsten Fall müssten Sie also auf das Aktualisierungsintervall der Zone und die TTL des Datensatzes warten.

Möglicherweise müssen Sie auch so lange auf die tatsächlichen Datensatzänderungen warten. Eine 5-minütige TTL bringt nicht viel, wenn die Sekundärdateien nur alle 6 Stunden aktualisiert werden. Daher möchten Sie wahrscheinlich auch das Aktualisierungsintervall für die Zone für den Zeitraum verringern, in dem Sie schnelle Änderungen vornehmen möchten.

Wohlgemerkt, dies trifft möglicherweise nicht auf Ihr Setup zu. Wenn Sie ein System haben, das alle autorisierenden Server zusammen aktualisiert, ist dies kein Problem (und ich bin mit der DNS-Einrichtung von Rackspace nicht vertraut). Ich empfehle jedoch, alle autorisierenden Server einzeln abzufragen ( dig server.example.com @secondaryserver.example.com), um sicherzustellen, dass sie die neue TTL haben, bevor Sie mit dem 24-Stunden-Countdown beginnen.

— Gordon Davisson
quelle
1
Dies sollte die akzeptierte Antwort sein.
— Dotancohen
4
Sie scheinen das DNS-Benachrichtigungsprotokoll zu ignorieren, mit dem Slave-Server angewiesen werden, kurz nach der Aktualisierung des Masters eine Aktualisierung durchzuführen. Die meisten DNS-Server verwenden diese Funktion.
— Barmar
@Barmar: Das stimmt, aber zur gleichen Zeit kann es je nach Anbieter eine Weile dauern, bis der Master aktualisiert ist. (Zum Beispiel
— erstellen
1
Mein Kommentar bezog sich nur auf das Problem des Wartens auf das Aktualisierungsintervall, das heutzutage größtenteils veraltet ist. Das Warten auf die Aktualisierung des Masters ist wahr, es sei denn, Sie betreiben Ihren eigenen Master. Ich halte es jedoch für unwahrscheinlich, dass sie sich mit dem genauen Zeitpunkt befassen müssen, zu dem alles sicher aktualisiert werden kann. 5-15 Minuten mehr sollten keinen großen Unterschied machen. Der Punkt der ursprünglichen Frage ist, ob sie einen ganzen Tag warten müssen.
— Barmar
1
@ GordonDavisson: Wenn Sie nicht vertrauen - überprüfen. dig +nssearch example.comist ein nützliches Tool zum schnellen Vergleichen von SOAs auf allen Servern. nsdiff zeigt die tatsächlichen Unterschiede an.
— Grawity
23

Ja, du solltest warten. Selbst dann ist es natürlich nicht garantiert, dass jeder die TTL respektiert.

— Sven
quelle
6
+1, da nicht jeder der TTL gehorcht. Ich habe eine Woche nach einer DNS-Änderung Nachzügler kommen sehen. Eine Möglichkeit, mit der ich in der Vergangenheit umgegangen bin, bestand darin, einen neuen eindeutigen Namen als Alias ​​für die neue Site einzurichten und mithilfe einer Umleitung von der alten Site Benutzer von der alten Domain zu den neuen umzuleiten, z. B. von www.mycompany .com -> newsite.mycompany.com
— Johnny
Ja, aber viele Menschen werden die Vorstellung, einen neuen Namen verwenden zu müssen, zu Recht verachten. Namen sind Marken. Dies funktioniert auch nur für HTTP und für so ziemlich nichts anderes.
— Sven
8
Eine andere Möglichkeit besteht darin, den alten Server als Reverse-Proxy für den neuen Server zu konfigurieren. Sie können das dann nach dem Umschalten etwa eine Woche lang stehen lassen und es ausschalten, wenn kein Datenverkehr durch das Gerät fließt.
— BDSL
1
Personen, deren DNS-Server sich gut verhalten und die TTL einhalten, werden die neue Domäne nie sehen. Und obwohl es "nur" mit HTTP (S) funktioniert, werden Sie wahrscheinlich feststellen, dass HTTP ein ziemlich verbreitetes Protokoll im Internet ist. bdsls Vorschlag, einen Reverse-Proxy einzurichten, ist noch besser, aber es ist mehr Arbeit
— Johnny
@ Johnny Das Problem mit einer neuen Domain ist, dass Sie das Risiko eingehen, dass Personen diese Domain mit Lesezeichen versehen. Es sei denn, Sie planen, die neue Domain für immer zugänglich zu lassen.
— Bob
5

Das Zusammenfassen verschiedener Kommentare und Antworten wäre ungefähr so.

  1. Stellen Sie sicher, dass Sie Ihre autorisierten Server rechtzeitig aktualisieren können.
  2. Reduzieren Sie die TTL.
  3. Überprüfen Sie, ob alle autoritativen Server das neue TTL haben.
  4. Warten Sie die alte TTL ab, damit zwischengespeicherte Werte mit der alten TTL (meistens) aus den Caches entfernt werden (Sie können nicht garantieren, dass sie aus jedem Cache entfernt werden, da einige Caches die Standards möglicherweise ignorieren).
  5. Versetzen Sie die Site auf dem alten Server in den schreibgeschützten Modus (oder ersetzen Sie sie durch die Seite "Wir warten nicht", falls dies nicht möglich ist).
  6. Führen Sie die endgültige Kopie vom alten Server auf den neuen Server aus (was zu einer schreibgeschützten Site auf dem neuen Server führt).
  7. Ändern Sie die DNS-Einträge.
  8. Stellen Sie sicher, dass alle autorisierenden Server über die neuen DNS-Einträge verfügen.
  9. Warten Sie auf das neue ttl (Sie können diesen Schritt überspringen, wenn Sie nicht möchten, dass einige Benutzer zur Website beitragen können und andere Benutzer die Ergebnisse dieser Beiträge nicht sehen).
  10. Versetzen Sie die Site auf dem neuen Server in den Lese- / Schreibmodus.
  11. Stellen Sie auf dem alten Server fest, dass es sich um eine veraltete Nur-Lese-Kopie handelt und dass der Benutzer wahrscheinlich das DNS beschädigt hat.
  12. Warten Sie eine Weile, bis die Datensätze aus nicht kompatiblen DNS-Caches gelöscht wurden.
  13. Nehmen Sie den alten Server außer Betrieb.
— Peter Green
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.