# Runbook przełączenia domeny, DNS i TLS dla nowego serwera | SwissOctet Insights https://swissoctet.com/pl/insights/dns-tls-cutover-runbook/ SwissOctet / Spostrzeżenia / Web i onion Web i onion Praktyczne · 4 min czytania Runbook przełączenia domeny, DNS i TLS dla nowego serwera Przygotuj razem routing nazw hostów, certyfikaty i wycofanie, aby migracja zmieniła serwer bez psucia tożsamości witryny ani bezpiecznych połączeń. Autor: SwissOctet Editorial Zapisz przewodnik Kopiuj link NA TEJ STRONIE 01 Zinwentaryzuj nazwy i zależności 02 Przygotuj routing nazw hostów na nowym serwerze 03 Wybierz metodę walidacji certyfikatu 04 Zaplanuj okno buforowania przed zmianą DNS 05 Zweryfikuj DNS i TLS osobno 06 Uczyń wycofanie również decyzją o danych 07 Obserwuj witrynę po przełączeniu Twoja praktyczna lista kontrolna Źródła i dalsza lektura Powrót do biblioteki BEZPOŚREDNIA ODPOWIEDŹ 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. 01 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. 02 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. 03 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. 04 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 05 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. 06 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. 07 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. ZAMIEŃ TO W DZIAŁANIE 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. Pobierz listę kontrolną CZĘSTE PYTANIA 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. GŁÓWNE ŹRÓDŁA 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. POŁĄCZ WIEDZĘ Powiązana infrastruktura. Canvas Web Szwajcaria Vector VPS Szwajcaria Pulse NVMe Szwajcaria ZACHOWAJ WĄTEK Twoje następne notatki z terenu. Poznaj wszystkie przewodniki NOTATKA Z TERENU / 01 + Chmura i VPS Podstawy Jak wybrać VPS bez zgadywania Zamień pomysł na aplikację w użyteczny budżet zasobów, a następnie porównaj CPU, pamięć, storage i transfer razem. 4 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 02 + Web i onion Podstawy Hosting webowy lub VPS: wybierz pracę, którą chcesz wziąć na siebie Porównaj wymagania aplikacji, kontrolę i obowiązki utrzymaniowe, zamiast traktować VPS jako automatyczny następny krok dla każdej witryny. 6 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 03 + Web i onion Praktyczne Opublikuj usługę onion bez pomijania aplikacji Zaplanuj legalną publikację onion z kontrolowanym eksponowaniem backendu, starannym przeglądem treści, odzyskiwaniem kluczy usługi i wyraźnym modelem dostępu odbiorców. 4 min czytania Przeczytaj przewodnik