DNS_PROBE_FINISHED_NXDOMAIN znaczy, że przeglądarka zapytała o adres domeny i usłyszała: taka nazwa nie istnieje. Zanim zrestartujesz router albo zmienisz serwer DNS, zapytaj o tę samą nazwę dwa różne resolwery - dwa polecenia dig pokażą, czy problem siedzi u ciebie, u twojego dostawcy, czy w samej domenie.

Nie znajdziesz tu listy dziesięciu przypadkowych napraw. Dostaniesz trzy odczyty, tabelę wniosków i komplet danych do zgłoszenia - w tej kolejności, bo naprawianie przed diagnozą potrafi zamaskować prawdziwą przyczynę.

Co znaczy DNS_PROBE_FINISHED_NXDOMAIN?

DNS_PROBE_FINISHED_NXDOMAIN to komunikat przeglądarek z rodziny Chromium: sonda DNS zakończyła pracę, serwery DNS odpowiadały, a odpowiedź brzmiała NXDOMAIN, czyli „taka nazwa domenowa nie istnieje". To nie jest awaria połączenia ani serwera WWW - do żądania HTTP w ogóle nie doszło, bo przeglądarka nie dostała adresu, pod który mogłaby zapukać.

W protokole DNS ta odpowiedź ma numer: RCODE 3, w specyfikacji nazwany Name Error. Komunikat mówi jednak tylko, jaki wynik dotarł do przeglądarki. Nie mówi, skąd ten wynik pochodzi - z pamięci podręcznej twojego systemu, z resolwera twojej sieci czy z serwera, który faktycznie odpowiada za domenę. Ustalenie tego źródła to cała diagnoza.

Dwie odpowiedzi mylone z NXDOMAIN prowadzą w zupełnie inne miejsca. NODATA znaczy, że nazwa istnieje, ale nie ma rekordu żądanego typu. SERVFAIL znaczy, że resolver nie zdołał obsłużyć zapytania - to informacja o jego awarii, nie o braku domeny.

Strona firmowego sklepu przestaje się otwierać na komputerze w biurze - Chrome pokazuje DNS_PROBE_FINISHED_NXDOMAIN. Na telefonie, przez LTE, ta sama strona działa. Ktoś proponuje restart routera, ktoś inny przestawienie DNS na publiczny resolver, a ktoś trzeci już pisze reklamację do hostingu. Każda z tych osób może mieć rację. Bez dwóch zapytań dig nikt nie wie która - a jeśli pierwsza naprawa „pomoże" przypadkiem, prawdziwa przyczyna wróci za tydzień.

Zapytaj dwa resolwery, zanim cokolwiek naprawisz

Najpierw przepisz z paska adresu dokładną nazwę hosta. Nazwa główna i subdomena to dwie różne nazwy w DNS - wynik jednej nie mówi nic o drugiej. Potem wykonaj trzy odczyty, zmieniając za każdym razem tylko jedną rzecz:

  1. Na urządzeniu z błędem zapytaj resolver, którego system używa domyślnie: dig NAZWA_DOMENY A. W wyniku odczytaj pole status i sekcję ANSWER.
  2. Na tym samym urządzeniu zapytaj resolver wskazany jawnie: dig @ADRES_RESOLWERA NAZWA_DOMENY A. Nazwa i typ rekordu muszą być identyczne jak w pierwszym odczycie - zmienia się wyłącznie resolver.
  3. Dopiero teraz powtórz oba polecenia na urządzeniu w innej sieci, na przykład na telefonie z LTE po udostępnieniu internetu. Nazwa i typ rekordu pozostają identyczne także tutaj.

dig wysyła zapytanie prosto do serwera DNS i pomija plik hosts oraz systemową pamięć podręczną - dlatego jego wynik bywa inny niż to, co widzi przeglądarka, i właśnie ta różnica jest informacją. W Windows bez zainstalowanego dig te same dwa odczyty zrobisz poleceniem nslookup NAZWA_DOMENY oraz nslookup NAZWA_DOMENY ADRES_RESOLWERA - składnię i sposób czytania wyniku rozpisaliśmy w tekście o odpytywaniu DNS przez nslookup.

Przy odczytach pilnuj dwóch pułapek:

  1. Pusta sekcja ANSWER to jeszcze nie NXDOMAIN. Jeśli pole status brzmi NOERROR przy pustej odpowiedzi, nazwa istnieje, tylko nie ma rekordu tego typu.
  2. Flaga aa w nagłówku odpowiedzi znaczy, że odpowiada serwer autorytatywny dla strefy. Bez niej odpowiedź przeszła przez resolver i mogła przyjść z jego pamięci podręcznej - zanotuj to, bo operator zapyta o źródło odczytu.

Nie porównuj odpowiedzi dla różnych nazw ani typów rekordów. Taka para wyników niczego nie rozstrzyga i cała praca idzie do kosza.

Jak czytać wyniki trzech odczytów?

Zestaw wyniki w jednym miejscu i znajdź swój wiersz. Wniosek wskazuje, kto może naprawić problem - i komu nie ma sensu go zgłaszać.

Co widzisz Co to znaczy Kto naprawia Twój następny ruch
NXDOMAIN z obu resolwerów, w obu sieciach Publiczny DNS naprawdę nie zna tej nazwy Właściciel domeny albo operator strefy DNS Zbierz odczyty i wyślij zgłoszenie - wzór niżej
Domyślny resolver: NXDOMAIN, jawnie wskazany: poprawny adres Twój resolver trzyma nieaktualną odpowiedź albo filtruje nazwę Administrator tego resolwera - w małej sieci bywa nim router, poza nią dostawca internetu Wyczyść jego cache, jeśli masz dostęp; jeśli nie, zgłoś różnicę odczytów
Oba resolwery zwracają adres, Chrome dalej pokazuje błąd Problem został na urządzeniu: cache klienta albo plik hosts Ty Wyczyść cache klienta DNS i sprawdź plik hosts, potem odśwież stronę
SERVFAIL z któregoś resolwera Resolver nie potwierdził braku nazwy, tylko własne niepowodzenie Administrator resolwera zwracającego SERVFAIL Zachowaj pełną odpowiedź i eskaluj - nie traktuj tego jak NXDOMAIN
Nazwa główna działa, subdomena zwraca NXDOMAIN W strefie brakuje rekordu tej konkretnej nazwy Właściciel strefy DNS Zgłoś dokładną subdomenę, bez uogólniania na całą domenę

Wyniki różne między sieciami przy zgodnych odczytach na każdym urządzeniu z osobna oznaczają, że granica problemu biegnie między sieciami - porównaj wtedy, jakich resolwerów faktycznie używają, zamiast obwiniać komputer. Gdy ping odpowiada komunikatem o nierozwiązanej nazwie, potwierdza tylko ten sam wynik DNS - co dokładnie mierzy ta komenda, opisujemy w tekście o poleceniu ping.

Kiedy czyszczenie cache DNS ma sens?

Odpowiedź „nazwa nie istnieje" też jest zapamiętywana - to negatywne cache, a czas jego życia wyznacza pole SOA strefy. Dlatego domena naprawiona po stronie operatora potrafi jeszcze przez jakiś czas „nie istnieć" na twoim urządzeniu. Czyszczenie ma sens w jednej sytuacji: jawnie wskazany resolver zwraca już poprawny adres, a twoje urządzenie wciąż pokazuje błąd.

W Windows najpierw podejrzyj, co klient DNS trzyma w pamięci:

ipconfig /displaydns

Jeśli widzisz tam nieaktualny negatywny wpis dla badanej nazwy, wyczyść cache:

ipconfig /flushdns

Na Linuksie z systemd-resolved ten sam efekt daje:

resolvectl flush-caches

Po wyczyszczeniu powtórz pierwszy odczyt dig i odśwież stronę. Jeżeli oba resolwery nadal zwracają NXDOMAIN, czyszczenie nic nie da - lokalna pamięć nie jest źródłem tej odpowiedzi i wracasz do tabeli wyżej.

Co wysłać w zgłoszeniu do operatora?

Zgłoszenie „domena nie działa" wraca z pytaniem o szczegóły i traci dobę. Wyślij od razu komplet:

  1. dokładną nazwę hosta i typ rekordu, o które pytasz,
  2. datę i godzinę każdego odczytu razem ze strefą czasową,
  3. adres resolwera użytego w każdym teście,
  4. pole status oraz sekcje ANSWER i AUTHORITY z każdej odpowiedzi - przy wyniku negatywnym sekcja AUTHORITY jest dla operatora najcenniejsza,
  5. informację, czy wynik powtarza się z innej sieci i przez inny resolver.

Jeśli odczyty się różnią, nie wybieraj za operatora, który jest „prawidłowy" - opisz oba i wskaż, skąd pochodzą. To rozróżnienie oszczędza jedną pełną rundę korespondencji.

Po czym poznasz, że problem zniknął?

Powtórz oba zapytania na tym samym urządzeniu, dla tej samej nazwy i typu, a potem jeszcze raz w drugiej sieci. Diagnoza jest zamknięta, gdy wszystkie odczyty zwracają poprawny adres, a przeglądarka otwiera stronę bez komunikatu.

Poprawny wynik dla jednej nazwy potwierdza tylko tę nazwę - nie dowodzi, że reszta rekordów strefy jest w porządku. Jeśli po odzyskaniu adresu strona pokazuje inny błąd, to już inna warstwa: właściwy tekst znajdziesz w przeglądzie błędów serwera i przeglądarki. Konfiguracją rekordów DNS i delegacją domeny zajmujemy się w osobnych tekstach - tutaj kończysz z ustalonym źródłem problemu i kompletem danych do zgłoszenia.

Procedura opiera się na RFC 1035 (format odpowiedzi DNS, sekcje 4.1.1-4.1.2), RFC 2308 (negatywne cache), kodzie źródłowym Chromium (dns_probe_service_factory.cc) oraz dokumentacji BIND, Microsoft Learn i systemd.

Pytania o DNS_PROBE_FINISHED_NXDOMAIN

Czy zmiana DNS na publiczny resolver naprawia ten błąd?

Bywa, że objaw znika, bo inny resolver nie trzyma jeszcze negatywnej odpowiedzi albo nie filtruje nazwy. Przyczyna zostaje jednak nietknięta - jeśli leżała w twoim resolwerze, wróci przy każdym urządzeniu, które z niego korzysta. Zmianę resolwera traktuj jak test z tabeli wyników, nie jak naprawę.

Dlaczego strona działa na telefonie, a na komputerze nie?

Telefon w sieci komórkowej pyta innego resolwera niż komputer w biurze czy w domu. Jeśli jeden z nich trzyma nieaktualny negatywny wpis albo filtruje nazwę, wyniki się rozjadą. Dwa odczyty dig na komputerze - z domyślnym i jawnie wskazanym resolwerem - pokażą, czy to właśnie ten przypadek.

Czy wyczyszczenie cache DNS naprawia NXDOMAIN?

Tylko wtedy, gdy niezależny resolver zwraca już poprawny adres, a twoje urządzenie wciąż trzyma stary negatywny wpis. Czyszczenie usuwa lokalną pamięć i niczego nie zmienia w publicznym DNS. Jeśli oba resolwery nadal odpowiadają NXDOMAIN, źródło leży poza twoim urządzeniem i pomoże dopiero zgłoszenie do właściciela strefy.

Czym różni się NXDOMAIN od SERVFAIL?

NXDOMAIN to potwierdzenie, że badana nazwa nie istnieje. SERVFAIL mówi tylko, że resolver nie zdołał obsłużyć zapytania - o istnieniu nazwy nie przesądza nic. NXDOMAIN widoczny przez niezależne resolwery kierujesz do właściciela domeny, SERVFAIL do administratora resolwera, który go zwrócił.

Czy błąd może dotyczyć tylko jednej subdomeny?

Może, bo każda subdomena to osobna nazwa w DNS z własnymi rekordami. Sklep pod www potrafi działać, gdy sklep w tej samej domenie zwraca NXDOMAIN, bo rekordu po prostu nie ma w strefie. Dlatego w testach i w zgłoszeniu podawaj dokładną nazwę hosta, nie „całą domenę".