Przygotuj serwer i certyfikat dla zamierzonej nazwy hosta, przetestuj aplikację przed zmianą publicznego DNS i utrzymuj stare środowisko dostępne w trakcie przejścia. Zweryfikuj niezależnie rekordy autorytatywne, buforowane odpowiedzi i TLS. Sama aktualizacja DNS nie dowodzi, że obsługiwana jest właściwa aplikacja i certyfikat.
Zinwentaryzuj nazwy i zależności
Wymień każdą nazwę hosta używaną przez witrynę, w tym domenę główną, aliasy, punkty końcowe API i wywołania zwrotne aplikacji. Zapisz, kto kontroluje rejestrację i autorytatywne DNS. Hostowanie aplikacji nie rejestruje automatycznie jej domeny ani nie daje operatorowi serwera kontroli nad jej rekordami. Zachowaj dostęp do istniejącego środowiska, dopóki nowe nie zostanie zweryfikowane.
Zidentyfikuj także rekordy poczty e-mail i weryfikacji stron trzecich, które przeniesienie powinno zachować. Migracja witryny nie powinna pochopnie zastępować całej strefy DNS. Utwórz plan zmian na poziomie rekordów z zamierzonymi adresami i wartością wycofania. Przechowuj dane logowania w poufności; runbook potrzebuje właścicieli i procedur, a nie rzeczywistych haseł czy tokenów API.
Przygotuj routing nazw hostów na nowym serwerze
Maszyna przyjmująca połączenie musi obsługiwać zamierzoną aplikację dla swojej nazwy hosta. Skonfiguruj odpowiednio serwer WWW lub panel hostingowy, z publicznym katalogiem głównym dokumentów oddzielonym od prywatnej konfiguracji i danych logowania. Przetestuj wszystkie wymagane nazwy i przekierowania, a nie tylko ogólną stronę powitalną osiąganą przez adres serwera.
Użyj kontrolowanej metody testowej, która przed zmianą publiczną wysyła zamierzoną nazwę hosta do nowego punktu końcowego. Sprawdź logowanie, przesyłanie plików i linki generowane przez aplikację, jeśli ma to zastosowanie. Wyłącz zadania, które podczas testów mogłyby duplikować działania produkcyjne. Test powinien dowieść działania aplikacji bez wysyłania prawdziwej poczty, przyjmowania płatności lub niezamierzonej modyfikacji starej produkcyjnej bazy danych.
Wybierz metodę walidacji certyfikatu
Wydanie certyfikatu wymaga dowodu kontroli nad żądanymi nazwami. Let's Encrypt dokumentuje HTTP-01 i DNS-01 wśród swoich metod walidacji. Walidacja HTTP zależy od poprawnego obsłużenia wymaganego wyzwania; walidacja DNS używa określonego rekordu DNS i może obsługiwać wydawanie certyfikatów wieloznacznych. Wybierz metodę pasującą do rzeczywistego wdrożenia, którą można bezpiecznie utrzymywać.
W miarę możliwości utrzymuj wąski zakres danych logowania do walidacji. Automatyzacja DNS jest szczególnie wrażliwa, ponieważ szerokie dane logowania DNS mogą wpływać na więcej niż jedną witrynę. Zaplanuj odnawianie certyfikatów i sposób, w jaki odnowione pliki trafiają do procesu obsługującego. Udane pierwsze wydanie jest przydatne, ale witryna potrzebuje także działającego procesu odnawiania i monitorowania certyfikatu, który faktycznie prezentuje.
Zaplanuj okno buforowania przed zmianą DNS
Rekordy DNS mają czas życia używany przez resolvery podczas buforowania odpowiedzi. Zmiana rekordu nie zastępuje natychmiast każdego buforowanego wyniku. Jeśli przejściu sprzyja krótszy TTL, zaplanuj korektę wystarczająco wcześnie, aby wcześniej buforowane odpowiedzi mogły wygasnąć. Utrzymuj zarówno stare, jak i nowe środowisko zdolne do obsłużenia zaprojektowanego przez Ciebie przejścia.
Ta przykładowa sekwencja oddziela przygotowanie od publicznego przełączenia. Jej harmonogram trzeba dostosować do domeny, zachowania resolverów i aplikacji. Nie jest to uniwersalny harmonogram propagacji. Migracja obejmująca zapisy na żywo wymaga także przełączenia danych specyficznego dla aplikacji, ponieważ dwa działające serwery WWW mogą w przeciwnym razie przyjmować zmiany do różnych zbiorów danych.
| Etap | Działanie | Warunek przed kontynuowaniem |
|---|---|---|
| Przygotowanie | Zinwentaryzuj rekordy i skonfiguruj nowy punkt końcowy | Aplikacja działa dla zamierzonych nazw |
| Certyfikat | Wydaj i zainstaluj certyfikat | Poprawny łańcuch i nazwa hosta przechodzą walidację |
| Przejście | Zaktualizuj tylko zaplanowane rekordy DNS | Przełączenie danych i wycofanie są zdefiniowane |
| Obserwacja | Sprawdź wyniki autorytatywne i po stronie klienta | Ścieżki użytkownika kończą się sukcesem przez nowy punkt końcowy |
| Ukończenie | Wycofaj starą usługę po walidacji | Sprawdzono ruch resztkowy i potrzeby w zakresie odzyskiwania |
Zweryfikuj DNS i TLS osobno
Najpierw sprawdź autorytatywny rekord, a następnie porównaj odpowiedzi od klientów lub resolverów uczestniczących w migracji. Poprawna wartość autorytatywna i starsza wartość z pamięci podręcznej mogą współistnieć. Sprawdź punkt końcowy, do którego dociera przeglądarka, zamiast zakładać, że każde połączenie korzysta już z nowego adresu. Prowadź obserwacje ze znacznikami czasu, aby migracja była zrozumiała.
W przypadku TLS zweryfikuj zamierzoną nazwę hosta, ważność certyfikatu i łańcuch poprzez rzeczywiste połączenie klienta. Sprawdź każdy wymagany alias i ścieżkę przekierowania. Dokumentacja TLS Mozilli wyjaśnia uwierzytelnianie serwera i problemy z mieszaną zawartością: strona i jej podzasoby powinny być dostarczane bezpiecznie. Certyfikat na jednej nazwie hosta nie obejmuje automatycznie innego punktu końcowego aplikacji.
Uczyń wycofanie również decyzją o danych
Wycofanie DNS może przekierować ruch, ale nie odwraca zapisów wykonanych w nowej aplikacji. Zdefiniuj, jak obsłużysz te dane przed przełączeniem. W przypadku publikacji statycznej wycofanie może być proste; w przypadku usługi przyjmującej przesyłane pliki lub zamówienia stan aplikacji wymaga jasnego właściciela i procedury uzgodnienia.
Wyobraź sobie migrację małego serwisu wydawniczego z komentarzami. Możesz przygotować okno konserwacyjne lub kontrolowane przejście w trybie tylko do odczytu, podczas gdy końcowe dane są kopiowane. Przetestuj procedurę ponownego otwarcia i utrzymuj gotowość starego wdrożenia. Wybierz podejście pasujące do aplikacji, zamiast używać zmiany DNS jako substytutu planowania spójności.
Obserwuj witrynę po przełączeniu
Zweryfikuj rzeczywiste ścieżki użytkowników, wskaźniki błędów, prezentację certyfikatu i zadania w tle po tym, jak nowy punkt końcowy zacznie odbierać ruch. Potwierdź, że kopie zapasowe obejmują teraz zamierzoną aplikację i dane. Przejrzyj dostęp do starego serwera przed wycofaniem i usuń przestarzałe poświadczenia, gdy potrzeby w zakresie odzyskiwania i wycofywania zostaną rozwiązane. Zapisz końcową konfigurację DNS i certyfikatu.
Wybierając hosting stron internetowych lub moc obliczeniową SwissOctet, potwierdź rzeczywiste obowiązki w zakresie domeny, certyfikatu i administracji dla danej konfiguracji. Katalog zapewnia miejsce docelowe hostingu i zasoby; nie potwierdza, że Twoja domena została już podłączona ani że skonfigurowano odnawianie certyfikatu. Utrzymaj te kroki konkretnymi i weryfikowalnymi w planie wdrożenia.
Twoja praktyczna lista kontrolna.
- Zinwentaryzuj każdą nazwę hosta i zachowaj niepowiązane rekordy DNS.
- Przetestuj routing nazw hostów przed publicznym przełączeniem.
- Wybierz i zautomatyzuj odpowiednie wyzwanie certyfikatu.
- Zaplanuj zmiany TTL i przejście danych.
- Zweryfikuj DNS i TLS poprzez oddzielne kontrole.
- Zachowaj dostęp do wycofania i rozwiąż nowe zapisy przed przywróceniem.
Szczegóły, które mają znaczenie.
Czy zmiana rekordu A aktywuje HTTPS?+
Nie. DNS wybiera punkt końcowy; ten punkt końcowy nadal wymaga poprawnego routingu nazwy hosta oraz ważnego, zainstalowanego certyfikatu.
Czy mogę przywrócić tylko rekord DNS, jeśli coś się zepsuje?+
Ruch można przekierować, ale zapisy aplikacji wymagają oddzielnej obsługi. Zdefiniuj plan wycofania danych lub uzgodnienia przed migracją.
Czy certyfikat wieloznaczny jest zawsze konieczny?+
Nie. Wybierz nazwy certyfikatów i walidację zgodnie z rzeczywistymi nazwami hostów. Certyfikat wieloznaczny ma określone wymagania dotyczące pokrycia i walidacji; nie jest uniwersalnym skrótem migracyjnym.
Przejdź do źródła.
Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją.
- Let's Encrypt: Typy wyzwań letsencrypt.org
- IETF RFC 1034: Koncepcje i udogodnienia DNS datatracker.ietf.org
- Mozilla MDN: Transport Layer Security developer.mozilla.org
Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno.