# Ein Cutover-Runbook für Domain, DNS und TLS für einen neuen Server | SwissOctet Insights https://swissoctet.com/de/insights/dns-tls-cutover-runbook/ SwissOctet / Einblicke / Web & Onion Web & Onion Angewandt · 4 Min. Lesezeit Ein Cutover-Runbook für Domain, DNS und TLS für einen neuen Server Bereiten Sie Hostname-Routing, Zertifikate und Rollback gemeinsam vor, damit eine Migration den Server ändert, ohne die Identität der Website oder sichere Verbindungen zu beeinträchtigen. Von SwissOctet Editorial Leitfaden speichern Link kopieren AUF DIESER SEITE 01 Namen und Abhängigkeiten inventarisieren 02 Hostname-Routing auf dem neuen Server vorbereiten 03 Eine Zertifikatsvalidierungsmethode wählen 04 Das Cache-Fenster planen, bevor DNS geändert wird 05 DNS und TLS separat verifizieren 06 Rollback auch zu einer Datenentscheidung machen 07 Die Website nach der Umschaltung beobachten Ihre praktische Checkliste Quellen & weiterführende Literatur Zurück zur Bibliothek DIE DIREKTE ANTWORT Bereiten Sie Server und Zertifikat für den vorgesehenen Hostnamen vor, testen Sie die Anwendung, bevor Sie öffentliches DNS ändern, und halten Sie die alte Umgebung während des Übergangs verfügbar. Verifizieren Sie autoritative Datensätze, zwischengespeicherte Antworten und TLS unabhängig voneinander. Eine DNS-Aktualisierung allein belegt nicht, dass die richtige Anwendung und das richtige Zertifikat ausgeliefert werden. 01 Namen und Abhängigkeiten inventarisieren Listen Sie jeden Hostnamen auf, den die Website verwendet, einschließlich Hauptdomain, Aliase, API-Endpunkte und Anwendungs-Callbacks. Erfassen Sie, wer die Registrierung und das autoritative DNS kontrolliert. Das Hosten einer Anwendung registriert nicht automatisch ihre Domain und gibt dem Serverbetreiber nicht die Kontrolle über ihre Datensätze. Behalten Sie den Zugang zur bestehenden Umgebung, bis die neue validiert wurde. Identifizieren Sie außerdem E-Mail- und Drittanbieter-Verifizierungsdatensätze, die der Umzug erhalten soll. Eine Website-Migration sollte nicht beiläufig eine gesamte DNS-Zone ersetzen. Erstellen Sie einen Änderungsplan auf Datensatzebene mit den vorgesehenen Adressen und einem Rollback-Wert. Bewahren Sie Zugangsdaten privat auf; das Runbook benötigt Verantwortliche und Verfahren, nicht die tatsächlichen Passwörter oder API-Tokens. 02 Hostname-Routing auf dem neuen Server vorbereiten Eine Maschine, die eine Verbindung empfängt, muss die vorgesehene Anwendung für ihren Hostnamen ausliefern. Konfigurieren Sie den Webserver oder das Hosting-Panel entsprechend, wobei das öffentliche Dokument-Root von privater Konfiguration und Zugangsdaten getrennt ist. Testen Sie alle erforderlichen Namen und Weiterleitungen, nicht nur eine generische Willkommensseite, die über die Adresse des Servers erreicht wird. Verwenden Sie eine kontrollierte Testmethode, die den vorgesehenen Hostnamen vor der öffentlichen Änderung an den neuen Endpunkt sendet. Prüfen Sie gegebenenfalls Anmeldung, Uploads und von der Anwendung erzeugte Links. Deaktivieren Sie Jobs, die während des Tests Produktionsaktionen duplizieren könnten. Der Test sollte das Anwendungsverhalten belegen, ohne echte E-Mails zu senden, Zahlungen anzunehmen oder die alte Live-Datenbank unbeabsichtigt zu verändern. 03 Eine Zertifikatsvalidierungsmethode wählen Die Ausstellung eines Zertifikats erfordert den Nachweis der Kontrolle über die angeforderten Namen. Let's Encrypt dokumentiert unter anderem HTTP-01 und DNS-01 als Validierungsmethoden. Die HTTP-Validierung hängt davon ab, die erforderliche Challenge korrekt auszuliefern; die DNS-Validierung verwendet einen festgelegten DNS-Datensatz und kann Wildcard-Ausstellung unterstützen. Wählen Sie eine Methode, die zur tatsächlichen Bereitstellung passt und sicher gepflegt werden kann. Halten Sie Validierungs-Zugangsdaten nach Möglichkeit eng begrenzt. Die DNS-Automatisierung ist besonders sensibel, weil weitreichende DNS-Zugangsdaten mehr als eine Website betreffen können. Planen Sie die Zertifikatserneuerung und wie die erneuerten Dateien den ausliefernden Prozess erreichen. Eine erfolgreiche Erstausstellung ist nützlich, aber eine Website benötigt auch einen funktionierenden Erneuerungsprozess und eine Überwachung des Zertifikats, das sie tatsächlich präsentiert. 04 Das Cache-Fenster planen, bevor DNS geändert wird DNS-Datensätze tragen eine Time-to-Live, die Resolver beim Zwischenspeichern von Antworten verwenden. Eine Datensatzänderung ersetzt nicht sofort jedes zwischengespeicherte Ergebnis. Wenn ein Übergang von einer kürzeren TTL profitiert, planen Sie die Anpassung früh genug, damit zuvor zwischengespeicherte Antworten auslaufen können. Halten Sie sowohl die alte als auch die neue Umgebung in der Lage, den von Ihnen geplanten Übergang zu bewältigen. Diese beispielhafte Abfolge trennt die Vorbereitung vom öffentlichen Cutover. Ihr Zeitplan muss an Domain, Resolver-Verhalten und Anwendung angepasst werden. Es ist kein universeller Propagationsplan. Eine Migration mit Live-Schreibvorgängen benötigt außerdem einen anwendungsspezifischen Daten-Cutover, da sonst zwei funktionierende Webserver Änderungen in unterschiedlichen Datensätzen akzeptieren können. Phase Aktion Bedingung vor dem Fortfahren Vorbereitung Datensätze inventarisieren und neuen Endpunkt konfigurieren Anwendung funktioniert für vorgesehene Namen Zertifikat Zertifikat ausstellen und installieren Korrekte Kette und Hostname validieren Übergang Nur geplante DNS-Datensätze aktualisieren Daten-Cutover und Rollback sind definiert Beobachtung Autoritative und Client-Ergebnisse prüfen Nutzerabläufe gelingen über den neuen Endpunkt Abschluss Alten Dienst nach der Validierung außer Betrieb nehmen Resttraffic und Wiederherstellungsbedarf geprüft 05 DNS und TLS separat verifizieren Prüfen Sie zuerst den autoritativen Datensatz und vergleichen Sie dann Antworten von Clients oder Resolvern, die am Übergang beteiligt sind. Ein korrekter autoritativer Wert und ein älterer zwischengespeicherter Wert können gleichzeitig bestehen. Untersuchen Sie den vom Browser erreichten Endpunkt, statt anzunehmen, dass jede Verbindung bereits die neue Adresse verwendet. Halten Sie Beobachtungen mit Zeitstempel fest, damit der Übergang nachvollziehbar ist. Validieren Sie für TLS den vorgesehenen Hostnamen, die Zertifikatsgültigkeit und die Kette über eine tatsächliche Client-Verbindung. Prüfen Sie jeden erforderlichen Alias und Weiterleitungspfad. Die TLS-Dokumentation von Mozilla erläutert Serverauthentifizierung und Mixed-Content-Probleme: Die Seite und ihre Unterressourcen sollten sicher ausgeliefert werden. Ein Zertifikat für einen Hostnamen deckt nicht automatisch einen anderen Anwendungsendpunkt ab. 06 Rollback auch zu einer Datenentscheidung machen Ein DNS-Rollback kann Traffic umleiten, aber er macht Schreibvorgänge auf der neuen Anwendung nicht rückgängig. Definieren Sie vor dem Cutover, wie Sie mit diesen Daten umgehen. Bei einer statischen Veröffentlichung kann Rollback unkompliziert sein; bei einem Dienst, der Uploads oder Bestellungen akzeptiert, benötigt der Anwendungsstatus einen klaren Verantwortlichen und ein Abstimmungsverfahren. Stellen Sie sich die Migration einer kleinen Veröffentlichungswebsite mit Kommentaren vor. Sie können ein Wartungsintervall oder einen kontrollierten Read-only-Übergang vorbereiten, während die endgültigen Daten kopiert werden. Testen Sie das Verfahren zum Wiederöffnen und halten Sie die alte Bereitstellung bereit. Wählen Sie den Ansatz, der zur Anwendung passt, statt eine DNS-Änderung als Ersatz für Konsistenzplanung zu verwenden. 07 Die Website nach der Umschaltung beobachten Verifizieren Sie echte Nutzerabläufe, Fehlerraten, Zertifikatspräsentation und Hintergrundaufgaben, nachdem der neue Endpunkt Traffic empfängt. Bestätigen Sie, dass Backups nun die vorgesehene Anwendung und die Daten abdecken. Prüfen Sie den Zugang zum alten Server vor der Außerbetriebnahme und entfernen Sie veraltete Zugangsdaten, wenn Wiederherstellungs- und Rollback-Bedarf geklärt sind. Dokumentieren Sie die endgültige DNS- und Zertifikatskonfiguration. Bestätigen Sie bei der Auswahl von SwissOctet-Webhosting oder Compute die tatsächlichen Verantwortlichkeiten für Domain, Zertifikat und Administration der Konfiguration. Der Katalog bietet ein Hosting-Ziel und Ressourcen; er belegt nicht, dass Ihre Domain bereits verbunden oder die Zertifikatserneuerung konfiguriert wurde. Halten Sie diese Schritte im Bereitstellungsplan konkret und überprüfbar. MACHEN SIE ES ZU HANDLUNG Ihre praktische Checkliste. ✓ Jeden Hostnamen inventarisieren und nicht zusammenhängende DNS-Datensätze erhalten. ✓ Hostname-Routing vor dem öffentlichen Cutover testen. ✓ Eine geeignete Zertifikats-Challenge wählen und automatisieren. ✓ TTL-Änderungen und den Datenübergang planen. ✓ DNS und TLS durch separate Prüfungen verifizieren. ✓ Rollback-Zugang behalten und neue Schreibvorgänge klären, bevor Sie zurückkehren. Checkliste herunterladen HÄUFIGE FRAGEN Die Details, die zählen. Aktiviert die Änderung eines A-Datensatzes HTTPS? + Nein. DNS wählt einen Endpunkt; dieser Endpunkt benötigt weiterhin das korrekte Hostname-Routing und ein gültiges, installiertes Zertifikat. Kann ich bei Problemen nur den DNS-Datensatz zurücksetzen? + Traffic kann umgeleitet werden, aber Anwendungsschreibvorgänge erfordern eine separate Behandlung. Definieren Sie vor der Migration einen Daten-Rollback- oder Abstimmungsplan. Ist ein Wildcard-Zertifikat immer erforderlich? + Nein. Wählen Sie Zertifikatsnamen und Validierung entsprechend den tatsächlichen Hostnamen. Ein Wildcard hat bestimmte Abdeckungs- und Validierungsanforderungen; es ist keine universelle Migrationsabkürzung. PRIMÄRE REFERENZEN Gehen Sie zur Quelle. Diese Referenzen unterstützen die technischen Konzepte in diesem Leitfaden. Folgen Sie der aktuellen Dokumentation, bevor Sie ein Produktionssystem ändern. Let's Encrypt: Challenge-Typen letsencrypt.org IETF RFC 1034: DNS-Konzepte und -Einrichtungen datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Redaktionelle Beratung durch SwissOctet. Beispiele sind illustrativ. Servicespezifikationen, verfügbare Optionen und vertragliche Bedingungen müssen separat überprüft werden. VERBINDEN SIE DAS WISSEN Verwandte Infrastruktur. Canvas Web Schweiz Vector VPS Schweiz Pulse NVMe Schweiz HALTEN SIE DEN FADEN Ihre nächsten Feldnotizen. Alle Leitfäden entdecken FELDNOTIZ / 01 + Cloud & VPS Grundlagen Wie man einen VPS ohne Raten wählt Verwandeln Sie eine Anwendungsidee in ein nützliches Ressourcenbudget und vergleichen Sie dann CPU, Speicher, Storage und Transfer gemeinsam. 4 Min. Lesezeit Den Leitfaden lesen FELDNOTIZ / 02 + Web & Onion Grundlagen Webhosting oder eine VPS: Wählen Sie die Arbeit, die Sie übernehmen möchten Vergleichen Sie Anwendungsanforderungen, Kontrolle und Wartungsverantwortlichkeiten, statt eine VPS als automatischen nächsten Schritt für jede Website zu behandeln. 6 Min. Lesezeit Den Leitfaden lesen FELDNOTIZ / 03 + Web & Onion Angewandt Einen Onion-Dienst veröffentlichen, ohne die Anwendung zu übersehen Planen Sie eine legitime Onion-Veröffentlichung mit kontrollierter Backend-Exposition, sorgfältiger Inhaltsprüfung, Wiederherstellung der Dienstschlüssel und einem ausdrücklichen Modell für den Publikumszugang. 4 Min. Lesezeit Den Leitfaden lesen