Awaria DNS – dlaczego domena nie działa i jak rozpoznać problem?

Kiedy strona przestaje się otwierać, pierwsza myśl zwykle pada na serwer albo na hosting. W praktyce bardzo często winowajcą okazuje się awaria DNS, czyli problem z systemem, który tłumaczy nazwę domeny na adres serwera. Domena może być opłacona, serwer może działać bez zarzutu, a mimo to w przeglądarce pojawia się komunikat, że domena nie działa. Dzieje się tak, ponieważ przeglądarka nie potrafi ustalić, pod jaki adres IP ma się połączyć.

DNS to tylko jedna z możliwych przyczyn niedostępności, obok problemów z hostingiem, certyfikatem czy samą aplikacją www. Szerszy przegląd tych przyczyn opisuje osobny wpis o tym, dlaczego strona internetowa nie działa.

Tutaj skupiamy się na jednym wątku: na tym, czym jest problem z DNS, po czym go rozpoznać i jak odróżnić go od awarii serwera. Cały materiał dotyczy konkretnej domeny i jej konfiguracji, a nie naprawiania niedziałającego internetu w domu lub biurze.

Co to jest awaria DNS?

System nazw domenowych (w skrócie DNS, od Domain Name System) działa jak książka telefoniczna internetu. Ludzie posługują się nazwami, takimi jak naszafirma.pl, natomiast serwery komunikują się za pomocą adresów liczbowych, czyli adresów IP. DNS zamienia jedno na drugie. Bez tego mechanizmu każda strona byłaby dostępna tylko po wpisaniu długiego ciągu cyfr.

Awaria DNS oznacza, że proces rozwiązywania nazwy domeny został przerwany. Zapytanie o adres nie dociera tam, gdzie powinno, albo wraca z błędem czy z nieprawidłową odpowiedzią. Efekt jest zawsze podobny: urządzenie użytkownika nie wie, dokąd wysłać żądanie, więc połączenie się nie nawiązuje.

Warto od razu rozróżnić dwie sytuacje, które w codziennym języku bywają mylone:

• Awaria po stronie domeny: rekordy DNS są błędne, wygasły albo serwery obsługujące domenę przestały odpowiadać. Wtedy strona nie działa dla wszystkich lub dla większości odwiedzających.
• Problem po stronie użytkownika: komunikat „serwer DNS nie odpowiada” na jednym komputerze zwykle wskazuje na lokalny resolver DNS, na router albo na ustawienia sieci. Domena może być wtedy sprawna, a problem dotyczy tylko jednego urządzenia lub jednej sieci.

Ten drugi przypadek pojawia się w dalszej części, bo umiejętność jego odsiania to podstawa dobrej diagnozy. Na razie wystarczy zapamiętać, że awaria DNS związana z domeną i lokalny problem z internetem to dwa różne zjawiska, choć na ekranie potrafią wyglądać identycznie.

Jak działa rozwiązywanie nazwy domeny?

Żeby zrozumieć, gdzie błąd DNS może się pojawić, przydaje się prosty obraz całej drogi zapytania. Kiedy w przeglądarce pojawia się adres strony, w tle uruchamia się sekwencja kroków.

1. Przeglądarka pyta resolver DNS, najczęściej należący do operatora internetu albo publiczny, taki jak Google Public DNS czy Cloudflare DNS, o adres IP domeny.
2. Resolver, jeśli nie ma odpowiedzi w pamięci, kieruje pytanie do serwerów głównych i domeny najwyższego poziomu, na przykład .pl.
3. Te wskazują serwery nazw NS przypisane do konkretnej domeny, czyli miejsce, które zna jej właściwe ustawienia.
4. Serwer autorytatywny DNS danej domeny zwraca właściwy rekord A (adres IPv4) lub rekord AAAA (adres IPv6).
5. Resolver przekazuje adres przeglądarce, a ta łączy się z serwerem strony.

Każdy z tych etapów może zawieść.

• Jeśli serwery DNS domeny są niedostępne, odpowiedź nie przyjdzie.
• Jeśli rekordy są błędne, przeglądarka trafi pod zły adres.
• Jeśli sama domena wygasła, cała ścieżka urywa się na poziomie rejestru.

Dlatego diagnoza polega na ustaleniu, na którym odcinku tej drogi zapytanie się zatrzymuje.

Istotną rolę odgrywa tu pamięć podręczna DNS, nazywana też cache DNS. Odpowiedzi są zapamiętywane na czas określony przez parametr TTL DNS (Time To Live), podawany w sekundach. Dzięki temu kolejne wizyty są szybsze, ale ma to też skutek uboczny: po zmianie ustawień stare dane potrafią jeszcze przez pewien czas krążyć w sieci. To zjawisko wraca przy temacie propagacji DNS.

Jakie są objawy awarii DNS?

Objawy bywają mylące, bo różne problemy dają podobny efekt końcowy w postaci niedostępnej strony. Mimo to kilka sygnałów dość mocno wskazuje właśnie na DNS.

Najczęstsze komunikaty i zachowania, które sugerują, że domena nie odpowiada z powodu DNS:

• Przeglądarka pokazuje DNS_PROBE_FINISHED_NXDOMAIN albo ERR_NAME_NOT_RESOLVED, co wprost mówi, że nazwy nie udało się rozwiązać.
• Pojawia się komunikat w stylu „nie można znaleźć adresu DNS serwera” lub „nie można odnaleźć adresu IP serwera”.
• Strona nie ładuje się po nazwie, ale połączenie z serwerem po jego adresie IP działa. To silny sygnał, że warstwa sieciowa jest sprawna, a zawodzi tłumaczenie nazwy na adres.
• Przestaje działać jednocześnie strona i poczta w tej samej domenie, mimo że serwer pocztowy fizycznie funkcjonuje.
• Domena działa u jednych użytkowników, a u innych nie, zależnie od tego, jakiego resolvera używają i czy mają jeszcze zapamiętaną starą odpowiedź.

Ten ostatni objaw jest szczególnie charakterystyczny dla świeżych zmian w konfiguracji. Kiedy jedni widzą stronę, a inni komunikat błędu, zwykle mamy do czynienia z trwającą propagacją DNS albo z niespójnymi rekordami. Trudno wtedy mówić o klasycznej awarii serwera, bo ten działa tak samo dla wszystkich.

Dlaczego domena nie działa? Najczęstsze przyczyny

Przyczyn, dla których pojawia się awaria DNS, jest kilka, a ich rozróżnienie od razu podpowiada kierunek naprawy. Warto je omówić po kolei, bo każda ma inne objawy i inne rozwiązanie.

Pierwszą grupą jest nieprawidłowa konfiguracja DNS na poziomie rekordów. Brakujący albo błędny rekord A sprawia, że domena nie ma przypisanego adresu, więc domena nie wskazuje na serwer. Błędny rekord CNAME, który zamiast na właściwą nazwę wskazuje w pustkę albo tworzy pętlę, daje podobny efekt. Zła wartość rekordu MX nie wyłączy strony, ale zablokuje pocztę, co bywa mylące, gdy witryna działa, a wiadomości znikają.

Drugą grupą są problemy z serwerami nazw. Jeśli w panelu rejestratora ustawiono nieprawidłowe serwery nazw, albo wskazano serwery, które przestały istnieć, to cała delegacja domeny prowadzi donikąd. Nawet poprawne rekordy nie pomogą, skoro nikt nie wie, gdzie ich szukać. To częsty skutek przenosin między firmami hostingowymi, gdy stare serwery zostały wyłączone, a nowe jeszcze nie zostały wpisane.

Trzecia grupa to awaria serwerów DNS obsługujących domenę. Serwery autorytatywne mogą po prostu przestać odpowiadać z powodu problemów u dostawcy. Rekordy są poprawne, konfiguracja się zgadza, ale nie ma komu udzielić odpowiedzi. Taka sytuacja zwykle mija sama, gdy dostawca usunie usterkę, choć bywa odczuwalna tak długo, jak trwa problem po jego stronie.

Czwartym powodem jest wygasła domena. Po upływie okresu ważności rejestr zawiesza delegację, a zapytania zaczynają zwracać błąd NXDOMAIN, tak jakby domena nigdy nie istniała. To jedna z najprostszych do przeoczenia przyczyn, bo wszystko inne pozostaje na swoim miejscu, a strona i tak znika.

Piątą grupą są problemy z DNSSEC, czyli mechanizmem podpisywania odpowiedzi DNS. Kiedy podpisy są niespójne, na przykład po zmianie dostawcy bez aktualizacji kluczy, resolwery odrzucają odpowiedź i zwracają błąd SERVFAIL. Domena wygląda na skonfigurowaną, a mimo to część użytkowników nie może się połączyć.

Jak odróżnić awarię DNS od awarii serwera, hostingu, SSL lub aplikacji?

To najważniejszy element całej diagnozy, bo od trafnej identyfikacji zależy, czy w ogóle zabieramy się za właściwy problem. Kilka prostych obserwacji pozwala szybko zawęzić pole.

Jeśli po wpisaniu nazwy pojawia się błąd NXDOMAIN albo komunikat o niemożności rozwiązania nazwy, mamy do czynienia z DNS. Serwer nie zdążył nawet wejść do gry, bo przeglądarka nie ustaliła adresu. Kiedy natomiast strona się otwiera, ale zwraca kod 500, białą stronę albo komunikat aplikacji, DNS zadziałał poprawnie, a problem leży w warstwie serwera lub kodu. Innymi słowy, jeśli widać cokolwiek pochodzącego z serwera, to znaczy, że nazwa została rozwiązana.

Test z adresem IP bywa rozstrzygający. Gdy serwer odpowiada po adresie IP, a nie odpowiada po nazwie, to warstwa sieciowa i sam serwer działają, a zawodzi rozwiązywanie nazwy domeny. Odwrotna sytuacja, czyli brak reakcji także po adresie IP, przesuwa podejrzenie na hosting albo na zaporę sieciową.

Osobnego omówienia wymaga sytuacja po zmianie hostingu, adresu IP albo serwerów DNS. Bardzo często zdarza się wtedy, że domena zaczyna kierować do serwera, na którym nie ma jeszcze poprawnego certyfikatu. Strona się otwiera, ale przeglądarka blokuje ją ostrzeżeniem o bezpieczeństwie. To już nie jest awaria DNS, tylko błąd certyfikatu SSL będący skutkiem przekierowania ruchu na nowy serwer. DNS zadziałał prawidłowo, tyle że w nowym miejscu brakuje ważnego certyfikatu. Warto o tym pamiętać, bo objaw łatwo pomylić z problemem konfiguracji domeny, a rozwiązanie leży zupełnie gdzie indziej.

Sygnałem odróżniającym DNS od awarii serwera jest też zasięg problemu. Awaria serwerów DNS albo błędna konfiguracja zwykle daje efekt zależny od resolvera i od zapamiętanych danych, więc jedni widzą stronę, a inni nie. Klasyczna awaria hostingu jest bardziej jednolita: serwer nie odpowiada tak samo dla wszystkich, niezależnie od tego, jakiego DNS używają.

Jak sprawdzić DNS domeny?

Do rozpoznania, czy mamy problem z DNS, wystarczy kilka narzędzi. Część z nich jest wbudowana w systemy operacyjne, część działa w przeglądarce. Poniżej opis tego, jak sprawdzić DNS domeny w typowych sytuacjach.

Sprawdzanie DNS przez nslookup

Polecenie nslookup jest dostępne w systemach Windows, macOS i Linux. Pozwala zadać pytanie o rekordy konkretnej domeny i zobaczyć, jaki adres zwraca.

Podstawowe użycie wygląda tak:

nslookup naszafirma.pl

W odpowiedzi widać adres IP przypisany domenie. Brak adresu albo komunikat o nieistniejącej domenie wskazuje, że domena nie wskazuje na serwer albo że wystąpił błąd NXDOMAIN. Można też odpytać konkretny resolver, żeby porównać wyniki:

nslookup naszafirma.pl 8.8.8.8

Jeśli publiczny resolver zwraca poprawny adres, a lokalny nie, problem leży bliżej użytkownika niż domeny. To prosty sposób na odróżnienie awarii domeny od kłopotu z resolverem operatora.

Sprawdzanie DNS przez dig

Narzędzie dig jest dokładniejsze i bardziej czytelne dla osób technicznych. Standardowo działa w systemach macOS i Linux, a w Windowsie dostępne jest po instalacji odpowiedniego pakietu.

Zapytanie o rekord adresowy:

dig naszafirma.pl A

W sekcji odpowiedzi widać rekord A wraz z wartością TTL DNS, czyli czasem, przez jaki odpowiedź pozostaje ważna w pamięci podręcznej. Można też sprawdzić serwery nazw NS:

dig naszafirma.pl NS

oraz status DNSSEC, dodając odpowiednią flagę. Kiedy dig zwraca status SERVFAIL, a przy pominięciu weryfikacji podpisów odpowiedź jest poprawna, silnie wskazuje to na problem z DNSSEC.

DNS checker i sprawdzanie propagacji DNS

Osobną kategorią są narzędzia webowe typu DNS checker, które sprawdzają rekordy domeny z wielu lokalizacji na świecie naraz. Ich największą zaletą jest sprawdzanie propagacji DNS. Kiedy w jednym regionie widać nowy adres, a w innym stary, wiadomo, że zmiana jeszcze się rozchodzi. To pozwala odróżnić trwającą propagację od trwałego błędu konfiguracji.

Takie narzędzia przydają się zwłaszcza po przenosinach domeny, gdy część odwiedzających trafia na nowy serwer, a część wciąż na stary. Zamiast zgadywać, można zobaczyć rzeczywisty stan rekordów DNS domeny widziany z różnych miejsc.

Co oznaczają błąd NXDOMAIN i błąd SERVFAIL

Te dwa komunikaty pojawiają się w diagnostyce najczęściej i warto rozumieć różnicę między nimi, bo prowadzą w zupełnie inne strony.

Błąd NXDOMAIN (Non-Existent Domain) oznacza, że system nazw uznał domenę za nieistniejącą. Serwer autorytatywny odpowiedział, że nie zna takiej nazwy. Najczęstsze przyczyny to wygasła domena, literówka w nazwie, brak rekordu dla konkretnej subdomeny albo błędna delegacja domeny. W przeglądarce ten stan przekłada się na komunikat DNS_PROBE_FINISHED_NXDOMAIN. Kluczowe jest to, że odpowiedź przyszła, tylko była negatywna. Ktoś na końcu łańcucha jednoznacznie stwierdził, że domeny nie ma.

Błąd SERVFAIL (Server Failure) to sytuacja inna. Oznacza, że resolver nie był w stanie uzyskać wiarygodnej odpowiedzi. Nie chodzi o brak domeny, tylko o awarię procesu jej rozwiązywania. Typowe przyczyny to niespójny DNSSEC, niedostępne serwery DNS domeny albo błędy w łańcuchu delegacji. SERVFAIL bywa podstępny, bo część resolverów przy tej samej konfiguracji zwróci błąd, a inne odpowiedzą poprawnie, zależnie od tego, jak rygorystycznie sprawdzają podpisy.

W skrócie: NXDOMAIN mówi „domeny nie ma”, a SERVFAIL mówi „nie umiem tego sprawdzić”. Pierwszy kieruje uwagę na istnienie i delegację domeny, drugi na stan serwerów i na DNSSEC.

Nieprawidłowa konfiguracja DNS: typowe błędy w rekordach

Skoro część awarii bierze się wprost z ustawień, warto przyjrzeć się temu, co dokładnie się psuje. Rekordy DNS domeny to zestaw wpisów, z których każdy pełni inną funkcję. Poniżej krótkie objaśnienie tych, które najczęściej stoją za niedostępnością.

• Rekord A: przypisuje domenie adres IPv4. Jego brak albo błędna wartość powoduje, że domena nie wskazuje na serwer, a strona się nie otwiera.
• Rekord AAAA: odpowiednik rekordu A dla adresów IPv6. Błąd w nim potrafi dotknąć tylko część użytkowników korzystających z IPv6, co daje efekt „działa u jednych, nie działa u drugich”.
• Rekord CNAME: tworzy alias, czyli wskazanie jednej nazwy na inną. Pętla albo wskazanie na nieistniejącą nazwę kończy się błędem rozwiązywania.
• Rekord MX: kieruje pocztę do właściwego serwera. Nie wpływa na stronę, ale jego błąd blokuje odbieranie i wysyłanie wiadomości w domenie.
• Rekord NS: określa serwery nazw odpowiedzialne za domenę. Błąd tutaj podważa całą delegację domeny.

Częstym scenariuszem jest sytuacja, w której zmiana jednego rekordu została wprowadzona, ale nie zdążyła się jeszcze rozejść. Wtedy w grę wchodzi propagacja DNS, którą warto omówić osobno, bo bywa źródłem fałszywego alarmu.

Propagacja DNS: dlaczego zmiany nie działają od razu

Po zmianie serwerów DNS domeny albo pojedynczego rekordu nowe ustawienia nie stają się widoczne natychmiast na całym świecie. Stare odpowiedzi krążą jeszcze w pamięci podręcznej resolverów, dopóki nie wygaśnie ich TTL DNS. Ten proces stopniowego rozchodzenia się zmian to właśnie propagacja DNS.

Czas trwania zależy od wartości TTL ustawionej przed zmianą oraz od polityki poszczególnych resolverów. W praktyce część użytkowników widzi nowy stan po kilku minutach, a inni dopiero po kilkunastu godzinach. W skrajnych przypadkach pełne rozejście się zmian bywa liczone w dziesiątkach godzin. Dlatego zaraz po zmianie domena działa tylko u niektórych użytkowników, a to naturalny etap, nie awaria.

Kilka praktycznych wniosków wynikających z tego mechanizmu:

• Przed planowaną zmianą warto obniżyć TTL z wyprzedzeniem, żeby stare dane szybciej wygasały. Robi się to na tyle wcześnie, by nowa niska wartość zdążyła się rozejść.
• Bezpośrednio po zmianie ocena stanu domeny na jednym komputerze bywa myląca. Lepszym obrazem jest sprawdzanie propagacji DNS z wielu lokalizacji.
• Jeśli po upływie doby część resolverów wciąż zwraca stary wynik, warto zweryfikować, czy zmiana rzeczywiście została zapisana po stronie autorytatywnej, a nie tylko w panelu.

Delegacja domeny i serwery nazw po zmianie hostingu

Przenosiny między firmami hostingowymi to jeden z najczęstszych momentów, w których pojawia się awaria DNS. Delegacja domeny polega na tym, że w panelu rejestratora domena wskazuje na konkretne serwery nazw NS, a te przechowują właściwe rekordy. Kiedy przenosimy stronę, trzeba zadbać, żeby oba te poziomy się zgadzały.

Problem pojawia się, gdy stare serwery nazw zostają wyłączone, zanim domena zacznie wskazywać na nowe, albo gdy nowe serwery nie mają jeszcze przygotowanych rekordów. W obu wypadkach zapytania trafiają w próżnię i użytkownicy widzą, że domena nie działa. Bezpieczna kolejność wygląda następująco:

1. Na nowym hostingu przygotować pełny zestaw rekordów DNS domeny, w tym rekord A, ewentualny rekord AAAA oraz rekordy pocztowe MX.
2. Upewnić się, że nowe serwery nazw zwracają te rekordy, zanim nastąpi przełączenie delegacji.
3. Dopiero wtedy w panelu rejestratora zmienić serwery nazw na nowe.
4. Przez czas propagacji utrzymywać stary hosting w gotowości, żeby użytkownicy z zapamiętanym starym adresem trafiali na działającą wersję.

Po takiej zmianie łatwo o wspomniany wcześniej problem z certyfikatem po zmianie DNS. Gdy ruch trafia już na nowy serwer, a certyfikat nie został tam jeszcze poprawnie wystawiony, strona zostaje zablokowana ostrzeżeniem. To odrębna kwestia od samego DNS, choć występuje w tym samym momencie, więc warto sprawdzić certyfikat tuż po przełączeniu.

Czy błędny DNS może wyłączyć stronę i pocztę jednocześnie?

Tak, i to jeden z bardziej niedocenianych skutków. Ta sama domena obsługuje zwykle wiele usług naraz: stronę przez rekord A, pocztę przez rekordy MX oraz inne wpisy pomocnicze. Kiedy zawiodą serwery DNS domeny albo wygasa cała domena, przestaje działać wszystko, co się na niej opiera.

Bywa też odwrotnie, że problem dotyka tylko jednej usługi. Błąd w rekordzie A wyłączy stronę, ale poczta z poprawnym rekordem MX będzie działać. Zła wartość MX zablokuje pocztę, a strona pozostanie dostępna. Dlatego przy diagnozie warto sprawdzać rekordy oddzielnie, bo objaw „część rzeczy działa, część nie” często wskazuje właśnie na pojedynczy błędny wpis, a nie na całkowitą awarię DNS.

Co może zrobić użytkownik, a co właściciel strony

Podział ról jest tu istotny, bo część działań ma sens tylko po stronie odwiedzającego, a część wyłącznie po stronie osoby zarządzającej domeną.

Po stronie użytkownika, gdy pojawia się komunikat „serwer DNS nie odpowiada”, a chodzi raczej o lokalny problem niż o awarię domeny, pomocne bywają:

• Zmiana resolvera na publiczny, na przykład Google Public DNS lub Cloudflare DNS, żeby sprawdzić, czy problem leży po stronie operatora.
• Wyczyszczenie lokalnej pamięci podręcznej DNS, co usuwa nieaktualne odpowiedzi zapamiętane na urządzeniu.
• Sprawdzenie tej samej domeny w innej sieci, na przykład przez dane komórkowe, co szybko pokazuje, czy problem jest lokalny.

Jeśli po tych krokach domena nadal się nie otwiera, a inni użytkownicy potwierdzają to samo, sprawa najpewniej leży po stronie domeny.

Po stronie właściciela strony zakres działań jest szerszy i dotyczy samej konfiguracji:

• Weryfikacja, czy domena jest opłacona i nie mamy do czynienia z wygasłą domeną.
• Sprawdzenie rekordów DNS domeny narzędziami nslookup i dig oraz porównanie ich z zamierzonym stanem.
• Kontrola delegacji domeny, czyli tego, czy w panelu rejestratora ustawiono właściwe serwery nazw.
• Ocena stanu DNSSEC, zwłaszcza jeśli pojawia się błąd SERVFAIL.
• Obserwacja propagacji DNS po każdej zmianie, zamiast oceniania stanu na jednym komputerze.

Rozdzielenie tych dwóch perspektyw zapobiega typowemu błędowi, jakim jest wielogodzinne naprawianie ustawień domeny, podczas gdy problem tkwił w lokalnym resolverze, albo odwrotnie.

Zapobieganie awariom i kontrola odpowiedzi DNS

Skoro część awarii wynika z niezauważonych zmian albo z wygasających terminów, sporo da się osiągnąć samą prewencją. Podstawą jest wczesne wykrycie, bo im szybciej wiadomo o problemie, tym mniejszy jego zasięg.

Największą wartość ma tu monitoring. Automatyczne sprawdzanie dostępności domeny i poprawności jej odpowiedzi pozwala zauważyć usterkę, zanim zgłoszą ją odwiedzający. Dobrze skonfigurowany monitoring strony internetowej potrafi kontrolować nie tylko to, czy strona się otwiera, ale też czy rekordy DNS domeny zwracają oczekiwane wartości. Dzięki temu automatyczne wykrywanie awarii DNS wyłapuje zarówno nagłą awarię serwerów DNS, jak i cichą zmianę rekordu, która inaczej pozostałaby niezauważona aż do momentu, gdy strona zniknie.

Poza monitoringiem warto zadbać o kilka nawyków ograniczających ryzyko:

• Pilnowanie terminu ważności domeny, najlepiej z automatycznym przedłużeniem, żeby uniknąć błędu NXDOMAIN po wygaśnięciu.
• Ostrożne wprowadzanie zmian w rekordach DNS domeny, z wcześniejszym obniżeniem TTL i weryfikacją po fakcie.
• Zachowanie kopii aktualnej konfiguracji przed każdą większą zmianą, co przyspiesza powrót do stanu sprawnego.
• Uważne obchodzenie się z DNSSEC, ponieważ niespójne podpisy dają trudny do zauważenia błąd SERVFAIL dla części użytkowników.

Najczęstsze pytania o awarię DNS

Poniżej zebraliśmy odpowiedzi na pytania, które najczęściej pojawiają się przy podejrzeniu, że za niedostępnością strony stoi awaria DNS. Część z nich pomaga odróżnić problem z DNS od awarii serwera, część dotyczy diagnozy i typowych komunikatów, takich jak błąd NXDOMAIN czy błąd SERVFAIL. Zwięzłe wyjaśnienia w jednym miejscu ułatwiają szybkie ustalenie, gdzie leży źródło problemu.

Problem z DNS i niedostępna domena: najważniejsze wnioski

Awaria DNS to jedna z częstszych, a zarazem najbardziej mylących przyczyn tego, że domena nie działa. Serwer bywa sprawny, treść na miejscu, a mimo to strona pozostaje niedostępna, ponieważ zawodzi tłumaczenie nazwy na adres. Dobra diagnoza zaczyna się od ustalenia, czy mamy problem z DNS związany z domeną, czy raczej lokalny kłopot z resolverem po stronie użytkownika.

Kluczowe punkty warto zebrać w jednym miejscu:

• Błąd NXDOMAIN kieruje uwagę na istnienie i delegację domeny, a błąd SERVFAIL na stan serwerów i na DNSSEC.
• Test z adresem IP szybko rozstrzyga, czy zawodzi DNS, czy hosting.
• Nieprawidłowa konfiguracja DNS, błędna delegacja domeny oraz wygasła domena to najczęstsze źródła niedostępności.
• Po każdej zmianie liczy się cierpliwa obserwacja propagacji DNS, a nie ocena stanu na jednym urządzeniu.
• Zaraz po przenosinach warto sprawdzić certyfikat, bo objaw łatwo pomylić z problemem konfiguracji domeny.

DNS jest tylko jedną z warstw, na których strona może zawieść. Pełniejszy obraz przyczyn niedostępności, wraz z kolejnością sprawdzania, opisuje wpis o tym, dlaczego strona internetowa nie działa. W połączeniu ze stałym monitoringiem strony internetowej daje to spójny sposób na to, by usterkę wychwycić wcześnie i sprawnie ustalić, gdzie dokładnie leży jej źródło.