DNS i TTL przy zmianie hostingu — jak uniknąć przerwy w działaniu strony i poczty

Zmiana hostingu nie sprowadza się do wpisania nowego adresu IP i czekania na „propagację DNS”. DNS jest systemem rozproszonym: serwery autorytatywne publikują dane, resolvery przechowują je w cache, a urządzenia i aplikacje mogą utrzymywać własne wyniki. Bezpieczna migracja polega więc na przygotowaniu nowego środowiska, kontrolowanej zmianie właściwych rekordów i czasowym utrzymaniu obu serwerów.

TTL może ograniczyć czas używania starej odpowiedzi z cache, ale nie przenosi strony ani poczty, nie poprawia błędnego rekordu i nie gwarantuje, że każdy użytkownik zobaczy zmianę w tej samej chwili.

DNS: kto odpowiada za wskazanie domeny?

Domena jest czytelną nazwą, na przykład example.pl. Informacje o niej publikuje strefa DNS obsługiwana przez serwery autorytatywne. Użytkownik zwykle nie pyta ich bezpośrednio. Jego system korzysta z resolvera rekurencyjnego operatora internetu, firmy albo publicznej usługi DNS. Resolver znajduje odpowiedź i może ją zachować w cache.

Jedna domena może kierować różne usługi do różnych miejsc. Najważniejsze podczas migracji są:

• A — adres IPv4 strony lub innej usługi,
• AAAA — odpowiednik dla IPv6,
• CNAME — alias jednej nazwy do innej, często używany dla www,
• MX — serwery odbierające pocztę dla domeny,
• TXT — między innymi konfiguracja SPF, DKIM, DMARC i weryfikacje usług,
• NS — informacja o serwerach autorytatywnych dla strefy.

Zmiana A lub AAAA może przenieść stronę bez zmiany poczty. Zmiana MX może przenieść odbiór poczty bez ruszania strony. Typy i role popularnych rekordów zestawia dokumentacja rekordów DNS Cloudflare. Jest to opis mechanizmu, nie zalecenie wyboru tego dostawcy.

Co oznacza TTL?

TTL, czyli Time To Live, jest podawanym w sekundach limitem czasu, przez który odpowiedź DNS może pozostawać w cache przed ponownym zapytaniem do źródła. TTL dotyczy konkretnego RRsetu, na przykład zestawu rekordów A dla danej nazwy, a nie całej domeny jako jednej niepodzielnej konfiguracji.

Jeżeli rekord A miał TTL 14 400 sekund, resolver, który pobrał go tuż przed zmianą, może korzystać ze starej odpowiedzi jeszcze prawie przez cały ten okres. Zmiana TTL na 300 sekund w chwili migracji nie skraca czasu odpowiedzi już zapisanej z poprzednim TTL. Najpierw musi wygasnąć wcześniejszy cache. Dlatego ewentualne obniżenie TTL wykonuje się odpowiednio wcześniej — co najmniej na tyle, by poprzednia wartość miała szansę wygasnąć u resolverów, które pobrały rekord przed obniżką.

Niższy TTL zwiększa częstotliwość odświeżania, ale też liczbę zapytań do serwerów autorytatywnych. Po ustabilizowaniu migracji warto wrócić do wartości dopasowanej do sposobu działania usługi, zamiast na stałe utrzymywać najniższą możliwą wartość. Aktualna terminologia DNS w RFC 9499 podkreśla, że TTL jest maksymalnym czasem cache; operator cache może zastosować krótszy czas.

„Propagacja DNS” nie jest jednym centralnym procesem

Po zmianie rekordu nowa wartość jest publikowana na serwerach autorytatywnych zgodnie z działaniem dostawcy DNS. Reservery, które nie mają odpowiedzi w cache, mogą ją pobrać szybko. Inne nadal zwracają poprzednią wartość do czasu wygaśnięcia swojego wpisu. Kolejne warstwy — system operacyjny, router, przeglądarka, aplikacja, proxy albo CDN — mogą mieć osobny cache lub utrzymywać istniejące połączenie.

Nie istnieje jeden licznik obejmujący cały Internet ani uniwersalny moment zakończenia „propagacji”. Różni użytkownicy mogą w tym samym czasie trafiać do starego i nowego środowiska. Dodatkowo RFC 8767 dopuszcza wyjątkowe podanie danych po wygaśnięciu TTL, gdy resolver nie może odświeżyć ich z serwera autorytatywnego. Mechanizm ma zwiększać odporność DNS, ale pokazuje, dlaczego TTL nie jest bezwarunkową obietnicą czasu przełączenia.

Wynik na jednym komputerze nie dowodzi, że wszyscy widzą to samo. Publiczne resolvery mają własne, rozproszone cache; na przykład Google Public DNS opisuje swoją usługę jako resolver rekurencyjny korzystający z dużych współdzielonych cache. To inna rola niż hosting autorytatywnej strefy.

Zmiana rekordu a zmiana nameserverów

Zmiana A, AAAA, MX lub TXT w obecnej strefie

To punktowa zmiana danych na tych samych serwerach autorytatywnych. Przy migracji samej strony zwykle wystarczy zmienić A i — jeśli jest używany — AAAA oraz sprawdzić sposób obsługi www. Rekordy MX i TXT mogą pozostać bez zmian, jeżeli poczta nadal działa u dotychczasowego operatora.

Zmiana serwerów nazw i delegacji

Zmiana nameserverów przekazuje obsługę całej strefy innemu zestawowi serwerów autorytatywnych. Zanim zmienisz delegację u rejestratora, odtwórz w nowej strefie wszystkie potrzebne rekordy: A, AAAA, CNAME, MX, TXT, rekordy DKIM, weryfikacje usług, ewentualne rekordy SRV i CAA. Pusta albo niepełna strefa może pozostawić działającą stronę, ale wyłączyć pocztę, subdomeny lub integracje.

Delegacja i rekordy strefy mają własne cache oraz zależności. Jeżeli domena korzysta z DNSSEC, zmianę operatora DNS trzeba dodatkowo skoordynować z rekordem DS u rejestratora; niespójny łańcuch zaufania może spowodować błąd rozwiązywania domeny u walidujących resolverów. Sama zmiana A jest więc znacznie mniejszą operacją niż przeniesienie całej strefy.

Procedura zmiany hostingu bez niepotrzebnego przestoju

1. Zrób inwentaryzację. Zapisz obecne serwery nazw, rekordy A, AAAA, CNAME, MX i TXT, TTL, działanie proxy/CDN oraz termin wygaśnięcia starego hostingu.
2. Uruchom nowy hosting. Dodaj domenę, wersję PHP, bazę, zadania cron, przekierowania, certyfikat i pozostałą konfigurację potrzebną aplikacji.
3. Skopiuj stronę i dane. Przenieś pliki oraz bazę, ale zaplanuj też końcową synchronizację danych powstałych później. DNS nie wykonuje tego za Ciebie.
4. Przetestuj nowy serwer przed zmianą DNS. Sprawdź stronę pod właściwą domeną przez plik hosts albo rozwiązanie preview dostawcy. Szczegółową procedurę opisuje poradnik testowania strony na nowym hostingu przed zmianą DNS.
5. Obniż TTL wcześniej, jeśli operacja tego wymaga. Uwzględnij poprzednią wartość TTL i nie zakładaj, że nowa zacznie obowiązywać w istniejącym cache.
6. Wykonaj końcową synchronizację. Dla dynamicznej strony może być potrzebne krótkie ograniczenie zapisu, synchronizacja zamówień i formularzy albo inna kontrola rozbieżności.
7. Zmień tylko właściwe rekordy. Dla strony zwykle A/AAAA albo CNAME; dla poczty niezależnie MX i odpowiednie TXT.
8. Monitoruj oba środowiska. Sprawdzaj logi, odpowiedzi HTTP, certyfikat, formularze i przychodzącą pocztę. Użytkownicy mogą jeszcze trafiać do starego systemu.
9. Nie wyłączaj starego hostingu od razu. Pozostaw go aktywnego przez okres wynikający z wcześniejszych TTL, sposobu działania aplikacji i obserwowanego ruchu.
10. Po stabilizacji uporządkuj konfigurację. Przywróć rozsądny TTL, wyłącz stare środowisko dopiero po kontroli i usuń zbędne rekordy.

Jeżeli migracja obejmuje wiele usług, planer migracji strony i poczty pomaga zachować kolejność czynności. Jest checklistą organizacyjną; nie zmienia rekordów ani nie przenosi danych.

Strona WWW: A, AAAA, www, SSL i dwa działające serwery

Rekord A kieruje nazwę na IPv4, a AAAA na IPv6. Jeżeli na starym hostingu istnieje AAAA, a na nowym nie ma poprawnej obsługi IPv6, pozostawienie starej wartości może sprawić, że część użytkowników nadal trafi na stary serwer albo zobaczy błąd. Sprawdź domenę główną oraz www; ta druga może mieć własny A/AAAA albo CNAME.

Nowy serwer musi rozpoznawać właściwą nazwę hosta i mieć gotowy certyfikat HTTPS. Sam poprawny DNS nie instaluje certyfikatu ani nie konfiguruje przekierowania HTTP do HTTPS. Jeśli certyfikat ma zostać wystawiony automatycznie, upewnij się, że metoda walidacji działa w planowanym momencie i że proxy nie zasłania błędnej konfiguracji originu.

Przez okres współistnienia starego i nowego wyniku oba serwery powinny obsługiwać domenę. Dla statycznej strony jest to proste. Dla WordPressa, sklepu lub serwisu z formularzami problemem są nowe zapisy. Dlatego migrację aplikacji, baz i uploadów trzeba zaplanować niezależnie; pomaga w tym poradnik jak przenieść WordPressa na inny hosting.

Poczta: MX zmieniaj niezależnie od strony

Zmiana hostingu WWW nie wymaga zmiany MX, jeżeli poczta pozostaje u dotychczasowego dostawcy. Jeżeli przenosisz również pocztę, najpierw utwórz skrzynki i aliasy na nowym serwerze, skopiuj dotychczasową zawartość, skonfiguruj klientów i uwierzytelnianie wysyłki, a dopiero potem zmień MX.

Podczas przejścia część serwerów wysyłających może nadal używać starego wyniku MX. Stary serwer powinien więc nadal przyjmować wiadomości, a po zmianie może być potrzebna dodatkowa synchronizacja skrzynek. Priorytety MX nie są mechanizmem stopniowego procentowego kierowania poczty — niższa liczba oznacza preferowany serwer, a kolejne cele są zwykle zapasowe.

Rekordy TXT dla SPF, selektory DKIM i polityka DMARC muszą odpowiadać wszystkim systemom wysyłającym po migracji. Zmiana samego MX ich nie aktualizuje. Zasady opisuje poradnik SPF, DKIM i DMARC na hostingu, a kolejność kopiowania skrzynek i kontroli odbioru — poradnik jak przenieść pocztę na inny hosting.

Jak sprawdzić, gdzie wskazuje domena?

Do odczytu rekordów można użyć poleceń dig, nslookup lub host. Przykłady dla syntetycznej domeny:

dig example.pl A
dig example.pl AAAA
dig example.pl MX
dig example.pl TXT
dig @8.8.8.8 example.pl A
nslookup -type=mx example.pl

Sprawdź odpowiedź serwera autorytatywnego oraz kilku resolverów, a nie tylko wynik z jednego komputera. Zwróć uwagę na typ rekordu, wartość, pozostały TTL i to, czy odpowiedź jest autorytatywna. Publiczne narzędzia DNS lookup mogą ułatwić porównanie lokalizacji, lecz ich wynik również jest tylko obserwacją konkretnego resolvera w danym momencie.

Jeżeli narzędzie pokazuje nowy adres, a przeglądarka nadal starą stronę, przyczyną może być cache DNS systemu lub routera, ale także cache przeglądarki, CDN, reverse proxy albo aplikacji. Te warstwy trzeba rozróżnić. Przy rekordach proxy, takich jak pomarańczowa chmura Cloudflare, publiczny A/AAAA wskazuje infrastrukturę proxy, nie bezpośrednio adres serwera źródłowego.

Testowanie nowego serwera przed zmianą DNS

Wpis w pliku hosts pozwala na jednym komputerze skierować właściwą domenę na nowe IP, zachowując nagłówek Host i nazwę używaną przez HTTPS. Trzeba jednak uważać na IPv4 i IPv6 oraz usunąć wpis po teście. Tymczasowy URL dostawcy może być wygodny, ale nie zawsze odtwarza zachowanie aplikacji zależne od domeny, cookies, przekierowań i certyfikatu.

Formularzy, płatności, webhooków i wysyłki poczty nie należy uruchamiać bez kontroli skutków ubocznych. Test może utworzyć realne zamówienie, wysłać wiadomość albo zmienić dane w zewnętrznym systemie. W środowisku testowym użyj atrap lub odłączonych integracji, a końcowy test produkcyjny zaplanuj świadomie.

Najczęstsze błędy podczas zmiany DNS

• Zmiana rekordów przed przygotowaniem nowego hostingu. Nowy adres odpowiada, ale aplikacja, baza albo HTTPS nie są gotowe.
• Wyłączenie starego hostingu od razu. Użytkownicy ze starym cache trafiają na niedziałające środowisko.
• Zmiana nameserverów bez pełnej kopii strefy. Znikają MX, TXT, CNAME, subdomeny lub weryfikacje usług.
• Brak MX albo błędne priorytety. Poczta nie dociera tam, gdzie oczekiwano.
• Brak aktualizacji SPF, DKIM i DMARC. Odbiór działa, ale wysyłka traci poprawne uwierzytelnienie.
• Pominięcie AAAA. Część klientów IPv6 nadal trafia do starego serwera.
• Obniżenie TTL dopiero podczas zmiany. Resolver nadal ma starą odpowiedź zapisaną z wcześniejszym wysokim TTL.
• Test z jednego komputera. Jeden cache nie pokazuje sytuacji innych użytkowników.
• Edycja złej strefy. Rekord zmieniono w panelu hostingu, choć domena korzysta z innych serwerów autorytatywnych.
• Nieuwzględnienie proxy lub CDN. Zmiana originu i zmiana publicznego DNS są mylone, a cache treści zasłania rezultat.
• Mylenie cache HTTP z DNS. Stara strona nie zawsze oznacza stary rekord.

Czego DNS i TTL nie rozwiązują?

TTL nie naprawia błędnego IP, brakującego MX ani niespójnej delegacji. Niska wartość nie zapewnia natychmiastowej aktualizacji wszędzie, zwłaszcza gdy stary cache powstał wcześniej albo resolver wyjątkowo podaje dane stale. DNS nie kopiuje plików, bazy, zamówień ani skrzynek. Nie instaluje certyfikatu i nie sprawdza konfiguracji aplikacji.

Poprawna odpowiedź DNS oznacza jedynie, że nazwa prowadzi zgodnie z opublikowanymi danymi. Serwer docelowy nadal może zwracać błąd, niewłaściwą stronę, problem SSL albo niekompletną aplikację. Bezpieczna migracja wymaga więc kontroli całego przepływu, nie tylko rekordu.

Końcowa checklista

• Zapisz pełną obecną strefę, TTL i autorytatywne serwery nazw.
• Ustal osobno zakres zmiany strony, poczty, DNS, proxy i certyfikatu.
• Uruchom i przetestuj nowe środowisko pod właściwą domeną.
• Obniż TTL z wyprzedzeniem tylko dla rekordów, które będą zmieniane.
• Zaplanuj końcową synchronizację danych i ograniczenie nowych zapisów.
• Sprawdź A, AAAA, CNAME, MX i potrzebne TXT.
• Przy zmianie nameserverów odtwórz całą strefę przed delegacją.
• Monitoruj stary i nowy serwer, HTTPS, formularze oraz pocztę.
• Nie wyłączaj starej usługi na podstawie jednego lokalnego wyniku.
• Po stabilizacji przywróć właściwy TTL i usuń konfigurację przejściową.

Najważniejsza zasada jest prosta: najpierw przygotuj i sprawdź usługę docelową, później zmień możliwie mały zakres DNS, a stare środowisko wyłącz dopiero po obserwacji. Taki plan nie tworzy gwarancji absolutnego braku przerwy, ale usuwa najczęstsze przyczyny przestoju kontrolowane przez właściciela strony.