Po czym poznać, że to awaria DNS, a nie awaria serwera?
Najpewniejszy sygnał daje sama przeglądarka. Gdy pada serwer, dostajesz stronę błędu, na przykład z kodem 500 albo 502, albo przeglądarka długo czeka i kończy przekroczeniem czasu. Gdy pada DNS, przeglądarka w ogóle nie wie, dokąd iść, i od razu mówi, że nie może znaleźć adresu serwera. W Chrome towarzyszy temu kod DNS_PROBE_FINISHED_NXDOMAIN.
Drugi sygnał: kłopoty dotyczą wszystkiego, co korzysta z tej samej domeny. Jeśli razem ze stroną przestała dochodzić poczta na adresy w firmowej domenie, a panel hostingu otwierany pod technicznym adresem działa normalnie, przyczyna prawie na pewno leży w DNS.
Trzeci sygnał bywa najbardziej mylący. Część osób widzi stronę, a część nie. To nie znaczy, że awaria jest połowiczna. Komputery i operatorzy przez jakiś czas pamiętają poprzednią odpowiedź, więc ci, którzy byli na stronie niedawno, jeszcze trafiają pod stary adres, a reszta już nie trafia nigdzie.
Czym jest DNS i dlaczego jego awaria wygląda jak zniknięcie strony?
DNS to książka adresowa internetu. Przeglądarka zna nazwę, na przykład twojsklep.pl, ale połączyć się umie tylko z adresem IP. Zanim wyśle pierwsze żądanie do serwera, pyta system nazw, pod jakim adresem ta nazwa mieszka. Jeśli odpowiedzi nie ma albo jest błędna, do serwera nigdy nie dochodzi, więc serwer nie ma nawet czego zapisać w swoich logach.
Odpowiedź składa się z rekordów. Rekord A wskazuje adres IPv4, AAAA adres IPv6, CNAME przekierowuje nazwę na inną nazwę, MX mówi, gdzie dostarczać pocztę, a NS wskazuje serwery nazw, które w ogóle mają prawo odpowiadać za domenę. Każdy rekord ma też czas życia, czyli TTL: tyle sekund inni mogą trzymać odpowiedź w pamięci, zanim zapytają ponownie.
Stąd bierze się podstępność tej awarii. Hosting sprawdza swój serwer i widzi, że działa. Monitoring, który łączy się bezpośrednio z adresem IP, też widzi, że działa. Problem jest pomiędzy, w miejscu, którego nikt nie pilnuje, bo przez większość czasu po prostu działa.
Co sprawdzić po kolei, gdy podejrzewasz awarię DNS?
Kolejność ma znaczenie, bo pierwsze dwa kroki zajmują minutę i rozstrzygają najczęściej spotykane przypadki, a kolejne wymagają już wiersza poleceń.
1. Czy domena jest opłacona
Zaloguj się do panelu rejestratora i sprawdź datę ważności domeny. Wygasła domena przestaje odpowiadać w DNS, choć serwer i strona są nietknięte. To najprostsza przyczyna i najłatwiej ją przeoczyć, bo faktura przyszła rok temu na adres, którego nikt już nie czyta.
2. Czy domena wskazuje właściwe serwery nazw
W tym samym panelu sprawdź, jakie serwery nazw są przypisane do domeny. Po przenosinach hostingu albo zmianie dostawcy DNS często wskazują stare serwery, na których rekordów już nie ma.
3. Co odpowiada DNS
W wierszu poleceń wpisz nslookup twojsklep.pl 1.1.1.1, a potem to samo z 8.8.8.8. Na Linuksie i macOS: dig twojsklep.pl. Porównaj otrzymany adres z adresem serwera z panelu hostingu. Brak odpowiedzi to problem z rekordami albo z serwerami nazw, inny adres to rekord, który ktoś zmienił.
4. Czy problem widać z innej sieci
Otwórz stronę na telefonie z wyłączonym Wi-Fi. Jeśli przez sieć komórkową działa, a w biurze nie, kłopot może leżeć po stronie lokalnego serwera nazw albo pamięci Twojego komputera, a nie domeny.
5. Czy to nie pamięć Twojego komputera
Na Windows polecenie ipconfig /flushdns czyści zapamiętane odpowiedzi. Jeśli po nim strona wraca, awaria mogła się już skończyć, a Ty oglądałeś jej zapamiętany ślad.
6. Czy nie pada sam dostawca DNS
Jeśli rekordy są poprawne, a zapytania kończą się przekroczeniem czasu, zajrzyj na stronę statusu dostawcy DNS albo rejestratora. Wtedy pozostaje kontakt ze wsparciem i czekanie.
Skąd biorą się awarie DNS?
Rzadko z ataku, prawie zawsze ze zmiany. Rekord usunięty przy porządkach w panelu, przenosiny strony na nowy serwer bez aktualizacji rekordu A, zmiana serwerów nazw przed skopiowaniem strefy, literówka w adresie, wygasła domena. Wspólny mianownik jest jeden: ktoś coś zmienił albo ktoś czegoś nie zmienił w terminie.
Osobna kategoria to podpisy DNSSEC. Jeśli domena ma włączone podpisywanie, a po zmianie dostawcy klucze u rejestratora nie zgadzają się z kluczami w strefie, serwery nazw sprawdzające podpisy odrzucają odpowiedź. Strona znika wtedy dla części użytkowników, zależnie od tego, czy ich operator podpisy weryfikuje, co bardzo utrudnia diagnozę.
Z tego wynika praktyczna rada: zmiany w DNS rób w godzinach, w których ktoś może zareagować, i zapisuj, co zmieniłeś. Połowa czasu awarii DNS to szukanie odpowiedzi na pytanie, co było wpisane wcześniej.
Dlaczego po naprawie strona nie wraca od razu u wszystkich?
Przez TTL. Jeśli rekord miał czas życia ustawiony na godzinę, serwery nazw operatorów mogą przez godzinę oddawać swoim klientom starą, błędną odpowiedź. Naprawa działa od razu u źródła, a u odbiorców dopiero wtedy, gdy ich zapamiętana odpowiedź wygaśnie. Nie da się tego przyspieszyć z Twojej strony.
Da się natomiast przygotować na planowaną zmianę. Kilka dni przed przenosinami obniż TTL rekordów, które będziesz zmieniać, na przykład do pięciu minut. Po zmianie błąd, jeśli się pojawi, zniknie szybko, a po kilku dniach spokoju możesz przywrócić dłuższy czas.
Po naprawie sprawdzaj z kilku miejsc naraz: z publicznych serwerów nazw, z telefonu, z komputera po wyczyszczeniu pamięci. Sam fakt, że u Ciebie już działa, nic nie mówi o kliencie, który był na stronie godzinę temu.
Jak dowiedzieć się o awarii DNS, zanim napisze klient?
Postawić dwa osobne sprawdzenia tej samej strony. Pierwsze pyta DNS, czy domena odpowiada. Drugie wysyła żądanie HTTP pod adres strony. Razem nie tylko alarmują, ale od razu wskazują przyczynę: gdy padają oba, winny jest DNS; gdy DNS odpowiada, a strona nie, problem leży po stronie serwera i wiadomo, do kogo dzwonić.
W Uptimo sprawdzenie DNS jest w każdym planie, także w darmowym planie Solo, który pilnuje 3 usług z interwałem od 5 minut. Wystarczy to na parę DNS i HTTP dla jednej domeny, z zapasem na certyfikat albo serwer poczty. W planach Zespół i Agencja lekkie sprawdzenia, w tym DNS, chodzą co minutę. Powiadomienia e-mail są w każdym planie, a od planu Start dochodzą Slack, Teams, SMS i webhook, więc alarm o trzeciej w nocy nie musi czekać na poranną pocztę.
Sprawdzenie DNS warto założyć także dla domen, od których zależy sprzedaż, a które nie są Twoje, na przykład adresu bramki płatności. Jeśli to ta nazwa przestaje odpowiadać, klienci zobaczą błąd dopiero przy kliknięciu „Zapłać”, a strona główna będzie cały czas zielona. Pełną drogę do płatności pilnuje scenariusz przeglądarkowy, który przechodzi ją krok po kroku.
Czego monitoring DNS nie zobaczy?
Nie zobaczy zapowiedzi awarii, tylko jej skutek. Najlepszy przykład to wygasająca domena. Uptimo nie pilnuje dziś terminu rejestracji domeny i mówimy to wprost: gdy domena wygaśnie, sprawdzenie DNS zaalarmuje, ale dopiero wtedy. Datę ważności znajdziesz u rejestratora. Włącz tam automatyczne odnawianie i sprawdź, czy dane karty albo adres do faktur są aktualne.
Nie zobaczy też awarii, która dotyczy tylko części internetu. Sprawdzenia w Uptimo wychodzą dziś z jednego miejsca, a problem z podpisami albo z serwerem nazw jednego operatora może stamtąd wyglądać jak zdrowa domena. Jeśli klient pisze, że strona nie działa, a monitoring jest zielony, przejdź kroki 3 i 4 z listy wyżej, zamiast zakładać, że klient się myli.
I wreszcie nie zastąpi porządku przy zmianach. Najtańsza ochrona przed awarią DNS to notatka z poprzednimi wartościami rekordów przed każdą edycją i obniżony TTL przed przenosinami. Monitoring skraca czas do wykrycia, ale nie cofnie zmiany, której nikt nie zapisał.
Zacznij od pary: DNS i HTTP
Dwa sprawdzenia tej samej domeny wystarczą, żeby następnym razem wiedzieć o awarii pierwszym i od razu wiedzieć, czy dzwonić do rejestratora, czy do hostingu. Plan Solo jest bezpłatny bezterminowo, nie wymaga karty i obejmuje oba razem z pilnowaniem certyfikatu.