DNS_PROBE_FINISHED_NXDOMAIN: co oznacza i jak naprawić

Co oznacza ten błąd

NXDOMAIN to kod odpowiedzi DNS, skrót od non-existent domain. Resolver zwraca go po przejściu łańcucha od strefy głównej w dół do strefy, która powinna zawierać Twoją nazwę hosta, i nieznalezieniu tam niczego. Chrome wyświetla DNS_PROBE_FINISHED_NXDOMAIN. Firefox mówi, że nie może połączyć się z serwerem. Safari mówi, że nie może znaleźć serwera. Wszystkie trzy zgłaszają tę samą odpowiedź.

NXDOMAIN to nie to samo co awaria resolvera, a ta różnica decyduje, gdzie szukać. Jeśli Twój resolver jest nieosiągalny lub odpowiada z przekroczeniem czasu, zamiast tego dostajesz komunikat "DNS server not responding". Jeśli strefa odpowiada, ale jest uszkodzona, na przykład łańcuch DNSSEC się nie waliduje, zwykle dostajesz SERVFAIL. NXDOMAIN to odpowiedź jednoznaczna: nazwa nie jest opublikowana.

Jedna cecha NXDOMAIN liczy się podczas rozwiązywania problemów bardziej niż wszystkie inne. Odpowiedzi negatywne są cache'owane. Zgodnie z RFC 2308 resolver przechowuje wynik "no such name" przez okres zapisany w rekordzie SOA strefy, zwykle od 5 do 60 minut. Domena, która zaczęła działać dwie minuty temu, wciąż może nie działać na Twojej maszynie, i żadna liczba odświeżeń tego nie zmieni, dopóki wpis w pamięci podręcznej nie wygaśnie albo go nie wyczyścisz.

Dlaczego tak się dzieje

• Literówka w nazwie hosta. Zdecydowanie najczęstsza przyczyna i ta, którą wszyscy sprawdzają na końcu.
• Domena nie jest zarejestrowana albo wygasła. Wygasła domena jest zwykle usuwana ze strefy w ciągu kilku godzin od zakończenia okresu karencji.
• Brak delegacji serwerów nazw. Domena istnieje u rejestratora, ale nie ma rekordów NS wskazujących na dostawcę DNS, więc strefa nadrzędna nie ma dokąd odesłać resolvera.
• Rekord został usunięty lub zmieniony. Brakujący rekord A lub CNAME dla www daje NXDOMAIN dla www.example.com, podczas gdy sama domena wciąż działa.
• Zmiana jeszcze nie dotarła do Twojego resolvera. Nowe rekordy pojawiają się wszędzie dopiero po upływie TTL poprzedniego rekordu.
• Zapisana w pamięci podręcznej odpowiedź negatywna na Twoim urządzeniu, w przeglądarce albo na resolverze Twojego dostawcy internetu.
• Wpis w pliku hosts wskazujący nazwę na coś, co już nie istnieje, albo pozostałość po starym teście.
• VPN, proxy lub oprogramowanie filtrujące samodzielnie odpowiadające na zapytania DNS i blokujące lub nierozwiązujące nazwy.
• Nazwa hosta istniejąca tylko w sieci prywatnej, z którą aktualnie nie jesteś połączony, na przykład wewnętrzna domena .local lub firmowa.

Jak to naprawić

Najpierw wpisz adres jeszcze raz, potem idź od przeglądarki w stronę sieci. Testuj po każdym kroku zamiast wykonywać je wszystkie naraz.

Przeglądarka

1. Otwórz ten sam adres URL w oknie prywatnym. Jeśli tam się wczytuje, chodzi o rozszerzenie lub ciasteczko, nie o DNS.
2. Wyczyść własną pamięć podręczną resolvera Chrome pod chrome://net-internals/#dns, a potem opróżnij pule gniazd pod chrome://net-internals/#sockets. Chrome utrzymuje pamięć podręczną osobno od systemu operacyjnego, więc samo wyczyszczenie na poziomie systemu często niczego nie zmienia.

Windows

1. Wyczyść pamięć podręczną resolvera: ipconfig /flushdns
2. Odnów dzierżawę sieciową, co odbiera też serwery DNS przydzielane przez DHCP:

   ipconfig /release
   ipconfig /renew

3. Zrestartuj usługę cache'owania, jeśli samo wyczyszczenie nie pomaga:

   net stop dnscache
   net start dnscache

4. Sprawdź C:\Windows\System32\drivers\etc\hosts pod kątem linii z nazwą domeny i usuń ją, jeśli jest nieaktualna.
5. Ustaw publiczny resolver: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
6. Ostatecznością jest zresetowanie stosu sieciowego, a potem restart: netsh winsock reset

macOS

1. Wyczyść pamięć podręczną: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Sprawdź, które serwery są używane: scutil --dns | grep nameserver
3. Skieruj interfejs na publiczny resolver: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Sprawdź /etc/hosts i usuń każdą linię dotyczącą domeny.

Linux

1. Na systemd-resolved: sudo resolvectl flush-caches, a potem potwierdź używane serwery poleceniem resolvectl status.
2. Na dnsmasq: sudo systemctl restart dnsmasq. Na nscd: sudo systemctl restart nscd.
3. Odczytaj /etc/resolv.conf, żeby zobaczyć, który resolver odpytujesz, oraz /etc/hosts pod kątem nieaktualnego wpisu.
4. Przy NetworkManager zmień resolver bezpośrednio na połączeniu:

   nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
   nmcli con up "Wired connection 1"

Router

1. Zrestartuj router przez wyłączenie zasilania. Większość domowych routerów prowadzi mały resolver przekazujący z własną pamięcią podręczną, a restart ją czyści.
2. W panelu administracyjnym routera sprawdź serwery DNS WAN lub DHCP. Jeśli wskazują na stary serwer wewnętrzny lub usługę filtrującą, zamień je.
3. Przetestuj na telefonie w danych mobilnych zamiast Wi-Fi. Jeśli tam nazwa się rozwiązuje, usterka jest wewnątrz Twojej sieci.

Jeśli jesteś właścicielem domeny

NXDOMAIN na własnej stronie to problem publikacji, i jest tylko kilka miejsc, skąd może się wziąć. Najpierw sprawdź status rejestracji i datę wygaśnięcia. Potem potwierdź delegację, czyli krok, który ludzie pomijają:

dig NS example.com +short
dig example.com +trace

Pusta odpowiedź NS oznacza, że strefa nadrzędna nie ma delegacji, więc żaden resolver nie dotrze do Twojego dostawcy DNS, niezależnie od tego, jakie rekordy tam utworzyłeś. Wynik +trace pokazuje łańcuch przekierowań i dokładny krok, w którym się zatrzymuje. Jeśli delegacja jest w porządku, odpytaj bezpośrednio serwer nazw swojego dostawcy, żeby potwierdzić, że rekord istnieje w strefie, którą edytujesz:

dig @ns1.example-dns.net www.example.com A

Gdy dodajesz brakujący rekord, stara odpowiedź negatywna pozostaje gdzie indziej w pamięci podręcznej tak długo, jak pozwala minimum z SOA, więc daj temu tyle czasu, zanim uznasz, że naprawa nie zadziałała.

Sprawdź to z zewnątrz

Każda z powyższych napraw zmienia tylko Twoją własną maszynę. Żadna nie mówi Ci, czy nazwa rozwiązuje się dla kogokolwiek innego, a to właśnie chcesz wiedzieć najpierw. Uruchom zapytanie do dwóch publicznych resolverów i porównaj:

dig example.com +short
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +short

nslookup example.com 8.8.8.8

Jeśli Twój domyślny resolver nie zwraca niczego, a 1.1.1.1 zwraca adres, rekord istnieje, a Twój resolver trzyma nieaktualną odpowiedź negatywną albo filtruje tę nazwę. Jeśli każdy resolver nie zwraca niczego, rekord rzeczywiście nie istnieje.

Dwa resolvery to wciąż tylko dwa punkty widzenia, a odpowiedzi DNS różnią się według regionu częściej, niż ludziom się wydaje. Uruchom sprawdzenie zapytania DNS, żeby rozwiązać nazwę z punktów kontrolnych w kilku krajach naraz i odczytać, co zwrócił każdy z nich. Wynik podzielony, część lokalizacji odpowiada, część nie, wskazuje na zmianę wciąż się rozprzestrzeniającą albo na serwer nazw jednego dostawcy, nieosiągalny z części internetu. Ta obserwacja w czasie to propagacja DNS, która ma własny poradnik jak sprawdzić propagację DNS.

Wykrywanie nazwy, która przestaje się rozwiązywać

Rekord, który znika, nie zostawia po Twojej stronie żadnego śladu. Nic tego nie loguje, bo żadne żądanie nigdy nie dociera, a jedynym znakiem jest wykres ruchu, który spada. Naprawą w każdym przypadku jest zapytanie uruchamiane według harmonogramu skądinąd niż z Twojego biura. HostTracker monitoruje strony internetowe od 2004 roku i uruchamia obecnie sprawdzenia z ponad 300 punktów kontrolnych w 158 miastach, powiadamiając e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i inne kanały, gdy nazwa przestaje się rozwiązywać albo zaczyna odpowiadać złym adresem. Pozostałe poradniki w tej sekcji znajdziesz w klastrze napraw, a dwa najbliższe temu to serwer DNS nie odpowiada, dla sytuacji, gdy resolver w ogóle nie odpowiada, oraz jak naprawić wolne zapytanie DNS, dla sytuacji, gdy odpowiada, ale zajmuje mu to za dużo czasu.