dns_probe_finished_nxdomain - Jak zdiagnozować i usunąć problem?

Co naprawdę oznacza ten komunikat

W pomocy Google Chrome ten typ błędu jest opisywany jako sytuacja, w której nazwa hosta nie istnieje albo wskazuje już inny adres IP. To nie jest więc klasyczny problem z treścią strony, tylko z wcześniejszym etapem: systemem DNS, który tłumaczy nazwę domeny na adres serwera.

Ja patrzę na to tak: jeśli DNS nie zwróci poprawnej odpowiedzi, przeglądarka nie ma nawet szansy połączyć się z witryną. Dlatego ten komunikat bywa mylący. Strona może działać na serwerze bez zarzutu, a mimo to dla użytkownika wyglądać jak wyłączona. To ważne rozróżnienie, bo od razu zawęża pole poszukiwań i prowadzi do diagnozy sieci albo strefy DNS.

Od tego miejsca trzeba ustalić, czy problem jest lokalny, czy siedzi w samej domenie. To właśnie rozstrzyga, czy naprawa zajmie dwie minuty, czy wymaga wejścia do panelu rejestratora albo dostawcy hostingu.

Skąd bierze się problem po stronie przeglądarki i sieci

W dokumentacji Cloudflare ten komunikat jest łączony zarówno z błędną konfiguracją rekordów, jak i z problemem po stronie lokalnego DNS lub samej sieci. W praktyce dzielę przyczyny na dwie grupy: takie, które można wyłapać i poprawić od razu u użytkownika, oraz takie, które oznaczają błąd w konfiguracji domeny.

• Literówka w adresie - jeden brakujący znak, pomylona końcówka albo zły wariant domeny wystarczą, by zapytanie DNS zakończyło się niepowodzeniem.
• Stary cache DNS - urządzenie pamięta nieaktualną odpowiedź i nadal próbuje używać starej mapy domeny na IP.
• Problem z resolverem DNS - serwer pośredniczący, z którego korzysta system, może chwilowo nie odpowiadać albo zwracać niepełne dane.
• Niepełna konfiguracja subdomen - działa wersja główna, ale nie działa www, blog albo inny wariant nazwy, bo rekord nie został dodany.
• Nieprawidłowa delegacja - domena wskazuje na inne serwery nazw niż te, na których faktycznie znajdują się rekordy.

To jeszcze nie przesądza, że winna jest strefa DNS. Najszybciej rozstrzygam to prostym testem na różnych urządzeniach i z różnych sieci, bo tam zwykle wychodzi, czy problem jest lokalny, czy globalny.

Jak sprawdzić, czy winna jest domena czy lokalna konfiguracja

Jeśli chcę uniknąć błądzenia po omacku, zaczynam od krótkiej matrycy objawów. Ona nie naprawia problemu, ale bardzo szybko zawęża obszar szukania.

Jeśli po przełączeniu na inną sieć wszystko zaczyna działać, często winny jest lokalny DNS albo router. Gdy problem powtarza się w wielu miejscach, nie ma sensu tracić czasu na przeglądarkę - trzeba wejść w konfigurację domeny i sprawdzić, co faktycznie zwraca strefa.

W takim momencie przechodzę do rekordów, bo to tam najczęściej kryje się sedno problemu.

Jak naprawić rekordy DNS, gdy zarządzasz domeną

Najpierw sprawdzam, czy domena w ogóle deleguje ruch do właściwego dostawcy DNS. Jeśli serwery NS są ustawione gdzie indziej niż strefa, którą edytuję, zmiany w panelu nie mają żadnego wpływu na działanie witryny.

1. Zweryfikuj delegację NS - serwery nazw muszą wskazywać dokładnie ten system, w którym utrzymujesz rekordy.
2. Sprawdź rekord domeny głównej - dla example.pl zwykle chodzi o rekord A dla IPv4 albo AAAA dla IPv6.
3. Sprawdź www i inne subdomeny - jeśli użytkownicy wchodzą na www.example.pl, ta nazwa musi mieć własny rekord albo poprawny alias.
4. Porównaj adresy docelowe - rekord ma wskazywać działający serwer origin, a nie stary adres po migracji.
5. Ustaw rozsądny TTL - zbyt wysoki TTL wydłuża życie błędnej odpowiedzi; przy aktywnie zmienianych rekordach nie warto iść w skrajności.

Jeśli mam wątpliwości, odpalam dig albo nslookup, bo bezpośrednio pokazują odpowiedź różnych resolverów, bez zgadywania na podstawie samej przeglądarki. To prostsze niż przeklikiwanie wszystkiego w panelu i daje szybki obraz tego, czy problem siedzi w strefie, czy po drodze.

Jak podaje Cloudflare, przy nowo aktywowanej domenie trzeba sprawdzić zarówno domenę główną, jak i aktywne subdomeny, bo bardzo często właśnie jeden z tych wariantów nie ma jeszcze poprawnego wpisu. Z praktycznego punktu widzenia oznacza to, że sama obecność strefy DNS nie wystarcza - rekord musi być też zgodny z rzeczywistym adresem serwera.

Po zmianie rekordów daję im chwilę na propagację. W zależności od TTL i cache po drodze może to potrwać od kilku minut do kilku godzin, a przy wysokich wartościach TTL nawet do 24 godzin.

Żeby to dobrze zrozumieć, trzeba jeszcze wiedzieć, które pomyłki w rekordach najczęściej wywołują taki stan.

Najczęstsze błędy, które wywołują ten stan

Gdy diagnozuję domenę, najczęściej trafiam na kilka powtarzalnych konfiguracji. One wyglądają niewinnie, ale w DNS liczy się dokładność co do znaku.

W mojej praktyce największą różnicę robi sprawdzenie pary example.pl i www.example.pl. To właśnie te dwa warianty są najczęściej mylone, a użytkownicy zwykle wpisują tylko jeden z nich. Jeśli jeden adres działa, a drugi nie, problem nie jest tajemniczy - po prostu któryś rekord nie został ustawiony albo został ustawiony nie tam, gdzie trzeba.

Gdy rekordy są już poprawne, zostaje ostatni etap: tak uporządkować konfigurację, żeby problem nie wracał po każdej migracji albo zmianie hostingu.

Co sprawdzić przed kolejną zmianą rekordów DNS

Najwięcej czasu oszczędza mi zawsze dobra rutyna przed wdrożeniem zmian. Kilka prostych nawyków potrafi uchronić przed ponownym pojawieniem się błędu i niepotrzebnym szukaniem przyczyny po fakcie.

• Trzymaj jedną, aktualną listę rekordów domeny, zamiast rozproszonej dokumentacji w mailach i notatkach.
• Przed migracją sprawdź, które subdomeny mają działać od razu, a które mogą poczekać.
• Po zmianie przetestuj domenę główną, www i najważniejsze subdomeny z co najmniej dwóch sieci.
• Nie ustawiaj wysokiego TTL dla rekordów, które jeszcze mogą się zmienić w najbliższych dniach.
• Jeśli korzystasz z CDN, proxy albo zewnętrznego DNS, upewnij się, że wszystkie warstwy mówią to samo.

To właśnie takie detale decydują, czy domena zachowuje się przewidywalnie, czy co kilka miesięcy wraca ten sam problem pod inną postacią. Jeśli mam zostawić jedną praktyczną radę, to jest nią prosta zasada: najpierw sprawdź, czy problem dotyczy jednej nazwy i jednej sieci, a dopiero potem grzeb głębiej w DNS.