ERR_NAME_NOT_RESOLVED: co oznacza i jak naprawić
ERR_NAME_NOT_RESOLVED oznacza, że przeglądarka zapytała resolver DNS o adres IP witryny i nie dostała żadnej użytecznej odpowiedzi. To może oznaczać, że resolver zwrócił nic, przekroczył limit czasu albo zwrócił odpowiedź, którą przeglądarka odrzuciła, co jest szerszym warunkiem niż "ta domena nie istnieje".
Co oznacza ERR_NAME_NOT_RESOLVED
Zanim przeglądarka może się z czymkolwiek połączyć, zamienia nazwę hosta na adres IP przez DNS. ERR_NAME_NOT_RESOLVED to zbiorczy kod Chrome dla sytuacji, gdy to wyszukiwanie zawodzi w jakikolwiek sposób inny niż potwierdzona nieistniejąca nazwa: resolver nie odpowiedział na czas, zwrócił pustą albo wadliwą odpowiedź, albo własny stos sieciowy przeglądarki w ogóle nie mógł dotrzeć do resolvera.
Łatwo to pomylić z DNS_PROBE_FINISHED_NXDOMAIN, który jest węższym, bardziej konkretnym przypadkiem. NXDOMAIN oznacza, że resolver odpowiedział jasno: ta nazwa nie istnieje w strefie. ERR_NAME_NOT_RESOLVED jest szersze i obejmuje wyszukiwanie, które zawiodło, przekroczyło limit czasu albo wróciło z niczym użytecznym, co obejmuje zepsuty resolver, timeout, sieć bez dostępu do DNS w ogóle albo lokalne nadpisanie DNS, które poszło źle. Jeśli już wiesz, że domena kiedyś działała i nic w niej samej się nie zmieniło, ERR_NAME_NOT_RESOLVED wskazuje bardziej na ścieżkę rozwiązywania niż na własne rekordy domeny.
Jak pojawia się błąd
Chrome i Edge pokazują "This site can't be reached - example.com's server IP address could not be found. Try running Windows Network Diagnostics." z kodem ERR_NAME_NOT_RESOLVED. Firefox pokazuje "Hmm. We're having trouble finding that site" z komunikatem "we can't connect to the server at example.com."
dig pokazuje, co zwraca konkretny resolver, a +trace przechodzi cały łańcuch od roota w dół:
dig example.com A
;; ANSWER SECTION:
example.com. 300 IN A 203.0.113.10
dig +trace example.com
; <<>> DiG 9.18 <<>> +trace example.com
. 518400 IN NS a.root-servers.net.
...
com. 172800 IN NS a.gtld-servers.net.
...
example.com. 300 IN A 203.0.113.10
nslookup to szybsza kontrola zdrowego rozsądku, gdy potrzebujesz tylko odpowiedzi tak/nie:
nslookup example.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Name: example.com
Address: 203.0.113.10
Jeśli którekolwiek polecenie przekroczy limit czasu, zwróci SERVFAIL albo nic w sekcji ANSWER SECTION, wyszukiwanie naprawdę zawiodło, w odróżnieniu od odpowiedzi NXDOMAIN, która wprost powiedziałaby "no such name".
Co powoduje ERR_NAME_NOT_RESOLVED
- Brakujący rekord A albo AAAA. Domena rozwiązuje się dla innych typów rekordów, albo strefa istnieje, ale żaden rekord adresowy nie jest opublikowany dla żądanej nazwy hosta (w tym brakujący rekord dla konkretnej subdomeny, mimo że domena główna działa).
- Wygasła rejestracja domeny. Gdy domena wygasa, jej serwery nazw zwykle całkowicie przestają na nią odpowiadać, co produkuje dokładnie tę awarię, a nie czysty NXDOMAIN.
- Awaria albo zła konfiguracja serwera nazw. Jeśli autorytatywne serwery nazw domeny są nieosiągalne albo zwracają wadliwe odpowiedzi, każdy resolver próbujący odpowiedzieć za tę domenę zawodzi tak samo.
- Awaria walidacji DNSSEC. Walidujący resolver, który nie może zweryfikować podpisu DNSSEC (wygasły podpis, złamany łańcuch zaufania), odmawia zwrócenia jakiejkolwiek odpowiedzi, zamiast zwrócić taką, której nie może zaufać.
- Własny resolver odwiedzającego jest niedostępny albo nieosiągalny, zwykle przy zepsutym VPN, captive portalu Wi-Fi albo źle skonfigurowanym routerze wskazującym na serwer DNS, który już nie istnieje.
- Uszkodzony lokalny cache DNS na maszynie odwiedzającego, przechowujący nieaktualny albo zepsuty wpis sprzed poprawnej konfiguracji domeny.
Jak rozpoznać, kto zawinił
Zapytaj bezpośrednio publiczny resolver, taki jak dig example.com @8.8.8.8, omijając to, czego domyślnie używa lokalna sieć. Jeśli to też zawiedzie, problem leży we własnej konfiguracji DNS domeny, nie w sieci odwiedzającego. Zapytanie DNS uruchomione z wielu lokalizacji sprawia, że to jest natychmiast widoczne: spójna awaria wszędzie wskazuje na serwery nazw albo rejestrację domeny, podczas gdy awaria tylko z jednej lokalizacji albo resolvera wskazuje na coś lokalnego dla tego punktu obserwacji.
Jak naprawić ERR_NAME_NOT_RESOLVED
Jeśli jesteś odwiedzającym
- Wyczyść lokalny cache DNS. Na Windows:
ipconfig /flushdns. Na macOS:sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Na Linuksie z systemd-resolved:sudo resolvectl flush-caches. - Przełącz się na publiczny resolver DNS, taki jak 8.8.8.8 albo 1.1.1.1, w ustawieniach sieciowych, tymczasowo zastępując to, co domyślnie zapewnia Twój dostawca internetu albo router.
- Sprawdź plik hosts (
/etc/hostsna macOS/Linux,C:\Windows\System32\drivers\etc\hostsna Windows) pod kątem nieaktualnego ręcznego wpisu nadpisującego domenę. - Rozłącz się z VPN i spróbuj ponownie; niektórzy klienci VPN trasują DNS przez resolver, który sam jest nieosiągalny albo źle skonfigurowany.
- Zrestartuj router, jeśli każda witryna w sieci nie rozwiązuje się, nie tylko jedna.
Jeśli prowadzisz witrynę
- Potwierdź, że rekord A/AAAA istnieje dla dokładnej nazwy hosta, której używają odwiedzający, w tym dla dowolnej subdomeny:
dig www.example.com Aidig example.com Ato dwa osobne wyszukiwania. - Sprawdź status rejestracji i wygaśnięcia domeny u swojego rejestratora; niespodziewanie wygasła domena to częsta i łatwa do przeoczenia przyczyna.
- Zweryfikuj, że serwery nazw wpisane u rejestratora zgadzają się z tymi, które faktycznie obsługują strefę, i że odpowiadają:
dig NS example.com, a potem zapytanie bezpośrednio do każdego zwróconego serwera nazw. - Jeśli używasz DNSSEC, zwaliduj łańcuch poleceniem
dig +dnssec example.comi sprawdź, czy nie ma wygasłego rekordu RRSIG, częstej i samozadanej przyczyny awarii rozwiązywania. - Uruchom
dig +trace, żeby zobaczyć dokładnie, gdzie w łańcuchu od roota do serwera autorytatywnego rozwiązywanie się załamuje, zamiast zgadywać.
Powiązane błędy
- DNS_PROBE_FINISHED_NXDOMAIN to bliźniaczy błąd dla potwierdzonej odpowiedzi "ta nazwa nie istnieje", a nie zawiedzionego albo pustego wyszukiwania.
- Propagacja DNS tłumaczy, dlaczego świeżo zmieniony rekord może rozwiązywać się poprawnie z niektórych resolverów, a z innych nie przez pewien czas.
Jak zapobiec ERR_NAME_NOT_RESOLVED
Awarie DNS łatwo przeoczyć wewnętrznie, bo stabilna sieć biurowa i jej zbuforowane rekordy mogą działać długo po tym, jak odwiedzający gdzie indziej zaczną zawodzić. Kontrola DNS uruchamiana z ponad 300 punktów kontrolnych w 158 miastach wyłapuje awarię serwera nazw, wygasającą rejestrację albo zepsuty rekord w chwili, gdy zaczyna wpływać na rozwiązywanie, zamiast dopiero po tym, jak skrzynka wsparcia się zapełni. HostTracker monitoruje witryny od 2004 roku i alarmuje e-mailem, SMS-em, połączeniem głosowym, przez Slack, Telegram i inne kanały.
Najczęściej zadawane pytania
Jaka jest różnica między ERR_NAME_NOT_RESOLVED a DNS_PROBE_FINISHED_NXDOMAIN?
NXDOMAIN to jednoznaczna odpowiedź: resolver sprawdził, a nazwa nie istnieje w strefie. ERR_NAME_NOT_RESOLVED jest szersze i obejmuje wyszukiwanie, które zawiodło, przekroczyło limit czasu albo zwróciło nic użytecznego, co obejmuje przypadki, gdy domena faktycznie istnieje, ale jej serwery nazw są nieosiągalne.
Czy wygasła domena może spowodować ten błąd?
Tak, i to jedna z częstszych przyczyn. Gdy domena wygasa, jej serwery nazw zwykle gasną, więc każde wyszukiwanie dla niej zawodzi zamiast zwrócić czystą odpowiedź "nie istnieje".
Dlaczego witryna działa na moich danych mobilnych, ale nie na domowym Wi-Fi?
To wskazuje na resolver, którego używa Twoja domowa sieć, albo skonfigurowany serwer DNS routera, albo resolver dostawcy internetu. Przełączenie na publiczny resolver, taki jak 1.1.1.1, w dotkniętej sieci zwykle to potwierdza i naprawia.
Właśnie dodałem nową subdomenę i się nie rozwiązuje. Dlaczego?
Nowy rekord musi rozprzestrzenić się przez cache DNS po utworzeniu, a musi też faktycznie istnieć: potwierdź poleceniem dig subdomain.example.com A bezpośrednio wobec autorytatywnego serwera nazw, zanim uznasz, że to tylko opóźnienie propagacji.
Czy DNSSEC kiedykolwiek powoduje ten błąd na domenie, która jest poza tym w porządku?
Tak. Jeśli podpisy DNSSEC wygasną albo łańcuch zaufania się złamie, walidujący resolver odmawia odpowiedzi zamiast zwrócić dane, którym nie może zaufać, co wygląda identycznie jak awaria rozwiązywania po stronie odwiedzającego.