ERR_NAME_NOT_RESOLVED: що означає і як виправити

Що означає ERR_NAME_NOT_RESOLVED

Перш ніж браузер зможе з'єднатися з чимось, він перетворює ім'я хоста на IP-адресу через DNS. ERR_NAME_NOT_RESOLVED - це загальний контейнер Chrome для випадку, коли цей пошук провалюється якимось способом, відмінним від підтвердженого неіснуючого імені: резолвер не відповів вчасно, повернув порожню чи неправильно сформовану відповідь, чи власний мережевий стек браузера взагалі не зміг дістатися жодного резолвера.

Це легко сплутати з DNS_PROBE_FINISHED_NXDOMAIN, вужчим, конкретнішим випадком. NXDOMAIN означає, що резолвер відповів чітко: цього імені не існує в зоні. ERR_NAME_NOT_RESOLVED означає, що сам пошук провалився чи повернувся без нічого придатного, що включає зламаний резолвер, тайм-аут, мережу взагалі без доступу до DNS чи локальне перевизначення DNS, що пішло не так. Якщо ви вже знаєте, що домен раніше працював і нічого в самому домені не змінювалося, ERR_NAME_NOT_RESOLVED більше вказує на шлях розв'язання, ніж на власні записи домену.

Як з'являється помилка

Chrome й Edge показують "This site can't be reached - example.com's server IP address could not be found. Try running Windows Network Diagnostics." з кодом ERR_NAME_NOT_RESOLVED. Firefox показує "Hmm. We're having trouble finding that site" з повідомленням "we can't connect to the server at example.com."

dig показує, що повертає конкретний резолвер, а +trace проходить весь ланцюжок від кореня вниз:

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 - швидша перевірка на здоровий глузд, коли потрібна лише відповідь так чи ні:

nslookup example.com
Server:   8.8.8.8
Address:  8.8.8.8#53

Name:     example.com
Address:  203.0.113.10

Якщо будь-яка з команд завершується тайм-аутом, повертає SERVFAIL чи взагалі нічого не повертає під ANSWER SECTION, пошук справді провалився, на відміну від відповіді NXDOMAIN, яка прямо сказала б "такого імені немає."

Що спричиняє ERR_NAME_NOT_RESOLVED

• Відсутній запис A чи AAAA. Домен розв'язується для інших типів записів, чи зона існує, але жодного адресного запису не опубліковано для запитуваного імені хоста (включно з відсутнім записом для конкретного субдомену, навіть коли кореневий домен працює).
• Прострочена реєстрація домену. Щойно термін дії домену закінчується, його nameserver-и зазвичай узагалі перестають на нього відповідати, що дає саме цей збій, а не чистий NXDOMAIN.
• Збій чи неправильна конфігурація nameserver-а. Якщо авторитетні nameserver-и домену недосяжні чи повертають неправильно сформовані відповіді, кожен резолвер, що намагається відповісти за цей домен, провалюється однаково.
• Збій валідації DNSSEC. Резолвер, що перевіряє підписи й не може підтвердити підпис DNSSEC (прострочений підпис, зламаний ланцюжок довіри), взагалі відмовляється повертати відповідь, замість повернення тієї, якій не можна довіряти.
• Власний резолвер відвідувача не працює чи недосяжний, зазвичай через зламаний VPN, captive-портал Wi-Fi чи неправильно налаштований роутер, що вказує на DNS-сервер, якого вже не існує.
• Пошкоджений локальний DNS-кеш на машині відвідувача, що тримає застарілий чи зламаний запис від часу до того, як домен налаштували правильно.

Як зрозуміти, хто винен

Запитайте публічний резолвер напряму, наприклад dig example.com @8.8.8.8, оминаючи те, що налаштоване для використання в локальній мережі. Якщо це теж провалюється, проблема у власному DNS-налаштуванні домену, а не в мережі відвідувача. DNS-пошук, запущений із кількох локацій, робить це очевидним негайно: стабільний збій скрізь вказує на nameserver-и домену чи реєстрацію, тоді як збій лише з однієї локації чи резолвера вказує на щось локальне для тієї точки спостереження.

Як виправити ERR_NAME_NOT_RESOLVED

Якщо ви відвідувач

1. Очистіть локальний DNS-кеш. У Windows: ipconfig /flushdns. У macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. У Linux із systemd-resolved: sudo resolvectl flush-caches.
2. Перемкніться на публічний DNS-резолвер, наприклад 8.8.8.8 чи 1.1.1.1, у налаштуваннях мережі, тимчасово замінивши те, що за замовчуванням надає ваш провайдер чи роутер.
3. Перевірте файл hosts (/etc/hosts у macOS/Linux, C:\Windows\System32\drivers\etc\hosts у Windows) на застарілий ручний запис, що перевизначає домен.
4. Відключіться від VPN і повторіть спробу; деякі VPN-клієнти маршрутизують DNS через резолвер, що сам недосяжний чи неправильно налаштований.
5. Перезавантажте роутер, якщо кожен сайт у мережі не розв'язується, а не лише один.

Якщо ви керуєте сайтом

1. Підтвердьте, що запис A/AAAA існує для точного імені хоста, яке використовують відвідувачі, включно з будь-яким субдоменом: dig www.example.com A і dig example.com A - два окремі пошуки.
2. Перевірте статус реєстрації й терміну дії домену через свого реєстратора; несподівано прострочений домен - поширена й легко пропущена причина.
3. Переконайтеся, що nameserver-и, вказані в реєстратора, збігаються з тими, що справді обслуговують зону, і що вони відповідають: dig NS example.com, а тоді запит кожного повернутого nameserver-а напряму.
4. Якщо використовуєте DNSSEC, перевірте ланцюжок командою dig +dnssec example.com і перевірте на прострочений запис RRSIG, часту й самоспричинену причину збоїв розв'язання.
5. Запустіть dig +trace, щоб побачити точно, де саме в ланцюжку від кореня до авторитетного сервера розв'язання зривається, а не гадати.

Пов'язані помилки

• DNS_PROBE_FINISHED_NXDOMAIN - суміжна помилка для підтвердженої відповіді "цього імені не існує", а не провалений чи порожній пошук.
• Поширення DNS пояснює, чому щойно змінений запис може деякий час коректно розв'язуватися в одних резолверів і не розв'язуватися в інших.

Як запобігти ERR_NAME_NOT_RESOLVED

Збої DNS легко пропустити зсередини, оскільки стабільна офісна мережа з власним кешем записів може продовжувати працювати ще довго після того, як відвідувачі деінде почнуть отримувати збої. DNS-перевірка, що виконується з понад 300 контрольних точок у 158 містах, ловить збій nameserver-а, прострочену реєстрацію чи зламаний запис тієї миті, коли це починає впливати на розв'язання, а не після того, як переповниться скринька підтримки. HostTracker моніторить вебсайти з 2004 року й сповіщає електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами.

Часті запитання

Яка різниця між ERR_NAME_NOT_RESOLVED і DNS_PROBE_FINISHED_NXDOMAIN?

NXDOMAIN - однозначна відповідь: резолвер перевірив, і імені немає в зоні. ERR_NAME_NOT_RESOLVED ширша й охоплює пошук, що провалився, дав тайм-аут чи повернув нічого придатного, включно з випадками, коли домен таки існує, а от його nameserver-и недосяжні.

Чи може прострочений домен спричинити цю помилку?

Так, і це одна з найпоширеніших причин. Щойно термін дії домену закінчується, його nameserver-и зазвичай замовкають, тож кожен пошук для нього провалюється, а не повертає чисту відповідь "не існує".

Чому сайт працює на мобільному інтернеті мого телефону, але не на домашньому Wi-Fi?

Це вказує на резолвер, який використовує ваша домашня мережа, - або налаштований DNS-сервер вашого роутера, або резолвер провайдера. Перемикання на публічний резолвер на кшталт 1.1.1.1 у постраждалій мережі зазвичай підтверджує це й виправляє.

Я щойно додав новий субдомен, і він не розв'язується. Чому?

Новому запису потрібно поширитися через DNS-кеші після створення, і він також справді має існувати: підтвердьте це командою dig subdomain.example.com A напряму до авторитетного nameserver-а, перш ніж припускати, що це лише затримка поширення.

Чи може DNSSEC коли-небудь спричинити цю помилку на домені, з яким усе інакше гаразд?

Так. Якщо підписи DNSSEC прострочуються чи ланцюжок довіри ламається, резолвер, що перевіряє підписи, відмовляється відповідати, замість повернення даних, яким не може довіряти, а це виглядає ідентично до збою розв'язання з боку відвідувача.