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.
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.
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.
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.
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 |
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.
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.
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.
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.
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.
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.