Błąd DNS po migracji to jeden z tych problemów, które potrafią unieruchomić stronę, sklep internetowy i pocztę dokładnie wtedy, gdy wszystko miało działać lepiej. Migracja zakończona „sukcesem” na poziomie technicznym nie zawsze oznacza, że użytkownicy od razu widzą właściwą witrynę. Często dzieje się odwrotnie: część osób trafia na nowy serwer, część na stary, komuś pokazuje się komunikat o braku odpowiedzi DNS, a poczta przestaje dochodzić albo wpada do błędnej skrzynki.
To nie jest drobna niedogodność. W praktyce błąd DNS po migracji może oznaczać utratę ruchu, spadek sprzedaży, niedziałające formularze, problemy z logowaniem, niedostarczoną pocztę i chaos komunikacyjny, którego nie widać od razu z poziomu panelu administracyjnego. Dobra wiadomość jest taka, że większość takich awarii da się opanować metodycznie, bez zgadywania i bez nerwowych zmian w rekordach.
W tym artykule wyjaśniam, jak rozpoznać prawdziwą przyczynę problemu, jak odróżnić propagację DNS od błędnej konfiguracji oraz co zrobić krok po kroku, aby przywrócić poprawne działanie domeny po migracji. Pokażę też, kiedy nie warto działać samodzielnie, bo można pogorszyć sytuację.
Szybka odpowiedź
Jeżeli po migracji pojawia się błąd DNS, zacznij od sprawdzenia trzech rzeczy: czy domena deleguje na właściwe serwery DNS, czy rekordy A/AAAA/CNAME/MX zostały przeniesione poprawnie oraz czy nowy serwer odpowiada pod adresem IP, który widnieje w strefie DNS. Najczęstszy problem nie leży w samej migracji plików, tylko w tym, że świat DNS aktualizuje się z opóźnieniem albo wskazuje nie tam, gdzie trzeba.
Jeśli strona nie działa tylko u części użytkowników, najpewniej masz do czynienia z propagacją lub cache DNS. Jeśli nie działa nigdzie, problem jest zwykle w konfiguracji domeny, serwera lub rekordów. Jeżeli nie masz pewności, nie kasuj rekordów i nie zmieniaj wszystkiego naraz. Zrób kopię strefy DNS, porównaj stare i nowe ustawienia i dopiero wtedy wprowadzaj korekty.
Diagnoza problemu
Najważniejsze w diagnozie jest ustalenie, co dokładnie nie działa. Błąd DNS po migracji może oznaczać kilka różnych sytuacji, a każda wymaga innego podejścia. Inaczej postępuje się przy błędzie „DNS_PROBE_FINISHED_NXDOMAIN”, inaczej przy przekierowaniu na stary serwer, a jeszcze inaczej wtedy, gdy strona działa, ale poczta nie dochodzi.
Sprawdź najpierw, jak objawia się problem:
- przeglądarka wyświetla komunikat o błędzie DNS,
- domena nie rozwiązuje się do żadnego adresu IP,
- otwiera się stara wersja strony,
- strona działa tylko w niektórych sieciach lub na niektórych urządzeniach,
- poczta przestaje działać po zmianie DNS,
- formularze kontaktowe nie wysyłają wiadomości,
- subdomeny działają inaczej niż domena główna.
Jeśli masz dostęp do terminala, przydatne są podstawowe polecenia diagnostyczne, na przykład sprawdzenie rekordu A, AAAA, CNAME i MX. Jeśli nie korzystasz z narzędzi technicznych, wystarczy panel hostingu i panel DNS u rejestratora domeny. Kluczowe jest porównanie trzech elementów: gdzie domena jest delegowana, jakie rekordy są ustawione i gdzie faktycznie znajduje się nowy serwer.
W praktyce wiele osób myli dwa pojęcia: migrację strony i migrację DNS. Pliki strony mogą być już na nowym serwerze, ale domena nadal wskazuje na stary. Albo odwrotnie: DNS został przepięty, ale serwer docelowy nie ma jeszcze pełnej konfiguracji witryny, certyfikatu SSL czy właściwej wersji PHP. Wtedy problem wygląda jak „błąd DNS”, choć tak naprawdę źródło jest szersze.
Możliwe przyczyny
Po migracji błąd DNS najczęściej wynika z jednej lub kilku poniższych przyczyn.
1. Propagacja DNS jeszcze się nie zakończyła
Po zmianie rekordów lub serwerów nazw informacja musi rozprzestrzenić się po resolverach na całym świecie. Czas propagacji bywa krótki, ale może potrwać od kilkunastu minut do nawet 48 godzin, a czasem dłużej, jeśli wcześniejsze ustawienia miały wysoki TTL. W tym czasie jedni użytkownicy widzą nową wersję strony, inni starą, a jeszcze inni błąd pośredni.
2. Rekord A wskazuje na zły adres IP
To klasyk po migracji. Serwer strony został zmieniony, ale rekord A wciąż kieruje na stary adres IP. W rezultacie domena „działa”, ale trafia do niewłaściwego hosta. Gdy stary serwer zostanie wyłączony, użytkownicy widzą błąd lub puste odpowiedzi.
3. Brakuje rekordu AAAA lub jest błędny
Jeżeli domena ma rekord IPv6, a nowy serwer nie obsługuje IPv6 albo jest skonfigurowany inaczej niż poprzedni, część klientów może próbować łączyć się przez IPv6 i otrzymywać błąd. To bywa szczególnie mylące, bo nie wszyscy użytkownicy zobaczą ten sam rezultat.
4. Błędny rekord CNAME dla subdomen
Subdomena www, panel, sklep, poczta lub inne usługi mogą korzystać z CNAME. Jeśli rekord wskazuje na nieaktualny host albo zostanie wpisany w złej formie, subdomena przestaje działać mimo poprawnej konfiguracji domeny głównej.
5. Zmieniły się serwery DNS, ale strefa nie została odtworzona
Po przeniesieniu domeny do nowego DNS trzeba odtworzyć wszystkie potrzebne rekordy: A, AAAA, CNAME, MX, TXT, SRV, NS i ewentualnie wpisy dla weryfikacji usług. Jeśli ktoś przeniósł tylko część strefy, pewne usługi po prostu przestaną działać.
6. Rekordy pocztowe MX lub TXT zostały pominięte
Strona może działać poprawnie, ale poczta nie. Po migracji często zapomina się o rekordach MX, SPF, DKIM i DMARC. Efekt: wiadomości nie dochodzą, trafiają do spamu albo serwer odrzuca je jako nieautoryzowane.
7. TTL jest zbyt wysoki
TTL decyduje o tym, jak długo resolver przechowuje odpowiedź w pamięci. Jeśli przed migracją był ustawiony na kilka godzin lub dłużej, zmiany będą widoczne z opóźnieniem. W okresie migracji wysoki TTL utrudnia szybkie przełączenie ruchu.
8. Stary serwer nadal odpowiada i powoduje konflikt
Jeżeli stary hosting nie został odcięty albo nadal odpowiada na ten sam adres IP, część ruchu może trafiać do starej instancji, a część do nowej. To szczególnie problematyczne, gdy na obu serwerach działa inna wersja strony lub inne reguły przekierowań.
9. Błędy w strefie po stronie rejestratora domeny
Niektóre panele są mniej intuicyjne, niż się wydaje. Wystarczy pomylić strefę domeny głównej z subdomeną, dodać rekord w złej strefie lub przypadkowo nadpisać automatycznie generowane wpisy.
10. Lokalny cache DNS lub cache przeglądarki
Jeżeli problem występuje tylko na jednym komputerze, jednym telefonie lub w jednej sieci, winny może być lokalny cache DNS, router, system operacyjny albo przeglądarka. To nie musi oznaczać awarii globalnej, ale nie wolno tego zakładać bez sprawdzenia pozostałych punktów.
Rozwiązanie krok po kroku
Poniższa procedura pozwala uporządkować działania i zminimalizować ryzyko kolejnych błędów. Warto przechodzić przez nią po kolei, zamiast zmieniać kilka ustawień jednocześnie.
Krok 1: Zapisz obecny stan konfiguracji
Zanim cokolwiek zmienisz, zrób zrzut ekranu lub eksport strefy DNS. Zapisz obecne rekordy, aktualne serwery nazw, adres IP nowego serwera i ustawione TTL. To ważne zabezpieczenie, bo w razie pomyłki będziesz mógł odtworzyć poprzedni stan.
Krok 2: Sprawdź, gdzie faktycznie delegowana jest domena
Upewnij się, że domena wskazuje na właściwe serwery DNS. Jeśli po migracji przeniosłeś obsługę DNS do innego dostawcy, sama zmiana rekordów w starym panelu nic nie da. Domena musi korzystać z odpowiednich serwerów nazw, inaczej system nie odczyta nowych ustawień.
Krok 3: Zweryfikuj rekord A i AAAA
Sprawdź, czy rekord A prowadzi na nowy adres IPv4, a rekord AAAA na poprawny adres IPv6 lub czy w ogóle powinien istnieć. Jeśli nowy serwer nie obsługuje IPv6, a rekord AAAA nadal wskazuje na stary host, usuń go tylko wtedy, gdy masz pewność, że nie jest potrzebny. Nie usuwaj go „na próbę”, jeśli obsługują go inne usługi.
Krok 4: Porównaj rekordy subdomen
Sprawdź wpisy dla www, paneli, sklepów i subdomen technicznych. Częsty scenariusz wygląda tak: domena główna działa, ale www nie, albo odwrotnie. To znak, że nie przeniesiono wszystkich rekordów.
Krok 5: Upewnij się, że rekordy pocztowe są kompletne
Jeżeli razem ze stroną przenosisz pocztę, sprawdź MX, SPF, DKIM i DMARC. Brak jednego z nich może skutkować niedostarczaniem wiadomości lub obniżeniem wiarygodności domeny. Jeśli poczta działa na zewnętrznym serwerze, rekordy muszą pozostać zgodne z tą konfiguracją.
Krok 6: Zmniejsz TTL przed kolejną zmianą, jeśli to możliwe
Jeżeli migracja jeszcze trwa albo planujesz kolejny etap przełączenia, ustaw niższy TTL z wyprzedzeniem. Dzięki temu przyszłe zmiany rozprzestrzenią się szybciej. Pamiętaj jednak, że obniżenie TTL nie działa wstecz na rekordy już zapisane w cache.
Krok 7: Sprawdź odpowiedź serwera docelowego
Jeśli DNS wskazuje poprawnie, upewnij się, że sam serwer przyjmuje ruch pod nowym adresem. Serwer może odpowiadać na ping, ale nie obsługiwać strony WWW, może blokować port 80 lub 443, albo wymagać poprawnej konfiguracji vhosta, SSL czy reverse proxy.
Krok 8: Wyczyść cache lokalny i przetestuj z różnych źródeł
Sprawdź domenę z różnych sieci, urządzeń i przeglądarek. Wyczyść cache DNS na komputerze, zrestartuj router, jeśli to konieczne, i porównaj wyniki. Jeśli w jednej sieci działa, a w innej nie, problem może dotyczyć propagacji lub resolvera pośredniego.
Krok 9: Monitoruj logi i czas odpowiedzi
Po przełączeniu nie kończ obserwacji. Sprawdzaj logi serwera, błędy aplikacji, komunikaty o nieudanych połączeniach i spadki dostępności. Czasem problem nie jest stricte DNS, ale ujawnia się dopiero po tym, jak ruch zaczyna trafiać na nowy serwer.
Krok 10: Jeśli trzeba, przywróć poprzedni stan i działaj etapami
Jeżeli po zmianie wszystko się sypie, a biznes nie może czekać, tymczasowy powrót do poprzedniej konfiguracji może być rozsądniejszy niż dalsze eksperymenty. Lepiej zrobić kontrolowany rollback niż trwale przerwać dostęp do strony i poczty. Potem wykonaj migrację ponownie, ale etapami i z pełną kopią konfiguracji.
Najczęstsze błędy
- zmienianie kilku rekordów jednocześnie bez kopii zapasowej,
- pomijanie rekordów MX, SPF, DKIM i DMARC,
- założenie, że „DNS sam się naprawi”,
- usunięcie rekordu AAAA bez sprawdzenia, czy nie jest potrzebny,
- przeniesienie strony bez przeniesienia całej strefy DNS,
- testowanie zmian tylko z jednego komputera,
- ignorowanie cache routera i resolverów operatora,
- zbyt szybkie wyłączanie starego serwera,
- ustawianie rekordów w niewłaściwej strefie lub dla niewłaściwej subdomeny,
- mylenie problemu DNS z problemem SSL, CMS lub firewall.
Warto podkreślić jedno: wiele błędów powstaje nie dlatego, że ktoś „źle wpisał IP”, ale dlatego, że migracja była traktowana jak pojedyncza czynność, a nie jak zestaw zależnych konfiguracji. DNS, hosting, poczta, certyfikat i aplikacja muszą być spójne.
Kiedy nie robić tego samodzielnie
Nie warto działać samemu, jeśli:
- strona generuje przychód i każda godzina przestoju kosztuje pieniądze,
- na domenie działa sklep, panel klienta lub system rezerwacji,
- obsługujesz pocztę firmową i nie możesz pozwolić sobie na utratę wiadomości,
- nie masz pewności, który rekord odpowiada za który element usługi,
- migracja obejmuje kilka serwerów, subdomen i zewnętrzne usługi,
- na tej samej domenie działają dodatkowe systemy: CDN, WAF, poczta, aplikacje zewnętrzne,
- doszło do podejrzenia błędnego delegowania domeny lub konfliktu serwerów nazw.
Jeżeli sprawa dotyczy infrastruktury produkcyjnej, eksperymentowanie „na czuja” może pogorszyć sytuację. Przy błędach DNS małe zmiany potrafią mieć duży zasięg. Jeden niewłaściwy rekord może odciąć stronę, pocztę i część integracji jednocześnie.
Kiedy zgłosić się do specjalisty
Do specjalisty warto zgłosić się od razu, jeśli problem utrzymuje się dłużej niż przewidywany czas propagacji, jeśli błąd dotyczy więcej niż jednej usługi, albo jeśli po migracji strona zachowuje się niestabilnie w różnych lokalizacjach. Pomoc eksperta jest szczególnie potrzebna wtedy, gdy nie masz pełnego dostępu do strefy DNS, panelu hostingu lub logów serwera.
Również wtedy, gdy:
- nie jesteś pewien, czy domena jest delegowana do właściwego dostawcy,
- serwery nazw są ustawione nietypowo lub mieszają usługi kilku operatorów,
- poczta firmowa przestała działać po zmianie DNS,
- zniknęły subdomeny używane przez aplikacje, API lub sklep,
- chcesz wykonać migrację bez ryzyka kolejnego przestoju.
Specjalista DNS lub administrator systemowy nie tylko naprawi problem, ale też sprawdzi, czy konfiguracja jest odporna na podobne awarie w przyszłości. To szczególnie ważne przy firmach, które nie mogą sobie pozwolić na ręczne „gaszenie pożarów” po każdej zmianie serwera.
Praktyczne ostrzeżenia bezpieczeństwa
Podczas naprawy problemu DNS po migracji zachowaj ostrożność w kilku obszarach. Po pierwsze, nie wprowadzaj zmian w rekordach, jeśli nie masz pewności, co robią. Zmiana jednego wpisu może odciąć pocztę lub panel administracyjny. Po drugie, nie udostępniaj publicznie zrzutów ekranu z pełną konfiguracją DNS, jeśli zawierają dane poufne lub wewnętrzne adresy usług. Po trzecie, nie wyłączaj starego serwera natychmiast po przełączeniu domeny, dopóki nie masz pewności, że całość ruchu kieruje się na nowy adres i że nie ma już aktywnego cache po stronie użytkowników.
Jeśli korzystasz z certyfikatu SSL, upewnij się, że domena jest już poprawnie wskazywana na nowy serwer, zanim zaczniesz wymuszać przekierowania HTTPS. W przeciwnym razie możesz wywołać dodatkowe błędy, które będą wyglądały jak awaria DNS, choć w rzeczywistości wynikają z niepełnej konfiguracji hosta.
Podsumowanie
Błąd DNS po migracji to najczęściej efekt niekompletnej konfiguracji, propagacji lub pominiętych rekordów, a nie „zepsutego internetu”. Aby rozwiązać problem, trzeba metodycznie sprawdzić delegację domeny, rekordy A, AAAA, CNAME i MX, porównać stary i nowy serwer oraz upewnić się, że cała strefa DNS została odtworzona poprawnie. Jeśli problem dotyczy tylko części użytkowników, zwykle chodzi o cache i propagację. Jeśli dotyczy wszystkich, najprawdopodobniej coś jest błędnie ustawione w DNS, na serwerze albo w obu miejscach naraz.
Najważniejsza zasada brzmi: nie zgaduj. Zbierz dane, porównaj konfigurację, testuj etapami i zachowaj kopię zapasową. Dzięki temu unikniesz wielogodzinnego przestoju i dodatkowych szkód po migracji.
CTA do kontaktu
Jeżeli po migracji nadal widzisz błąd DNS, strona otwiera się niestabilnie albo poczta nie działa tak, jak powinna, nie warto tracić kolejnych godzin na przypadkowe zmiany. Skontaktuj się ze specjalistą, który przeanalizuje strefę DNS, serwer docelowy i konfigurację po migracji oraz wskaże dokładną przyczynę problemu. Dobrze wykonana diagnostyka oszczędza czas, nerwy i pieniądze.
