ERR_NAME_NOT_RESOLVED: що означає ця помилка і як її усунути

ERR_NAME_NOT_RESOLVED - це одна з найбільш дратівливих помилок браузера, тому що вона виглядає так, ніби сайт помер, хоча насправді сервер може бути живішим за всіх живих. Ви запускаєте проект, переносите домен на новий VPS, викатуєте Ingress в Kubernetes, підключаєте CDN або просто хочете зайти на адмінку, як раптом замість сторінки отримуєте відповідь, що це доменне ім'я не визначено.

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

У цій статті ми спробуємо розібратися, що саме призводить до появи даної помилки, як швидко зрозуміти, де саме проблема, у вас або в зоні домену, як діагностувати NXDOMAIN/SERVFAIL і що робити в різних сценаріях - від банального очищення кешу до перевірки делегування вашого домену.

 

 

 

 

Суть помилки ERR_NAME_NOT_RESOLVED

Для того, щоб розуміти, про що ми будемо говорити, потрібно спочатку розібратися в тому, що таке DNS і як працює ця служба.

DNS (Domain Name System) - це сервіс, який перекладає зрозумілі людині доменні імена в IP-адреси, зрозумілі мережі. Браузер не вміє переходити на домен сам по собі, він завжди підключається до конкретної IP-адреси. Тому, коли ви вводите в адресному рядку браузера example.com, спочатку відбувається DNS-запит - тобто пошук відповіді на питання, якій IP-адресі відповідає це доменне ім'я. Зазвичай ця відповідь береться з кешу (браузера/операційної системи/провайдера) або запитується у рекурсивного DNS-сервера, який при необхідності пересилає запит до авторитетних DNS-серверів домену і отримує A/AAAA/CNAME-записи. Спрощено, ланцюжок резолва можна представити такими кроками:

1. Ви вводите в браузері example.com;
2. Браузер перевіряє свій кеш - чи немає вже збереженого IP;
3. Якщо запису немає, запит передається операційній системі і її локальному резолверу;
4. За відсутності відповіді локально запит надходить на рекурсивний DNS-сервер (провайдера, корпоративний або публічний - 8.8.8.8 / 1.1.1.1);
5. Рекурсивний сервер при необхідності проходить ієрархію DNS: кореневі сервери → сервер зони (.com) → авторитетні NS домену;
6. Авторитетний сервер повертає A/AAAA або CNAME-запис з IP-адресою.
7. Браузер отримує IP і тільки після цього встановлює HTTP/HTTPS-з'єднання з сервером, саме за IP-адресою.

І ось якщо на будь-якому з цих етапів IP отримати не вдалося, то браузер показує ERR_NAME_NOT_RESOLVED, тобто ваш браузер просто не знає, до якого сервера звертатися.

 

У практичному сенсі проблема майже завжди зводиться до одного з трьох варіантів:

• Локальна проблема (кеш, DNS провайдера, VPN, файл hosts);
• Проблема DNS-зони (немає A/CNAME, неправильні NS, домен не делегований);
• Проблема інфраструктури DNS (авторитетні NS не відповідають, зона не завантажується, SERVFAIL тощо).

 

Тепер, коли ми розібралися в самій суті проблеми - давайте детальніше розглянемо основні причини.

 

 

 

 

 

Основні причини ERR_NAME_NOT_RESOLVED

Нижче ми розділимо причини на дві групи і пояснимо, чому цей поділ буде нам корисним.

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

 

Проблеми на стороні користувача (локальні)

Найбільш яскравими ознаками, що свідчать на користь того, що проблема виникла на стороні користувача, можуть бути:

• Сайт не відкривається тільки у однієї людини на її комп'ютері, а на інших - відкривається;
• Сайт прекрасно відкривається на телефоні, але не працює на ноутбуці;
• Сайт не працює тільки через VPN, а в нормальному режимі працює;
• Проблема з'явилася раптово, хоча зміни в домен не вносилися.

 

Типовими причинами в таких випадках можуть бути такі:

• DNS-кеш, коли браузер, ОС або домашній роутер запам'ятали старі відповіді, але домен з тих пір був змінений;
• DNS провайдера впав або з якоїсь причини ріже деякі домени (можливо блокування);
• Увімкнений VPN підміняє резолвер на свій і тим самим ламає ланцюжок резолва;
• Для користувачів Linux - коли у файлі /etc/hosts присутні якісь застарілі або блокуючі записи;
• Корпоративна мережа використовує внутрішні DNS і не резолвить зовнішні (або навпаки).

 

 

Проблеми на стороні домену/хостингу (DNS-зона, делегування)

Ця група майже завжди проявляється наступним чином:

• Домен не резолвується у всіх або у більшості користувачів;
• Команда dig повертає NXDOMAIN, SERVFAIL або порожній ANSWER;
• Зміни в доменній зоні були зроблені недавно.

 

Типовими причинами в цьому випадку можуть бути такі:

• Домен не делегований на правильні NS;
• Для домену зовсім немає A/CNAME запису;
• TTL тримає старі відповіді і заважає швидкому перемиканню;
• Закінчився термін дії домену або він потрапив в блокування у реєстратора;
• Авторитетні NS не відповідають або зона на них не завантажена;
• Помилки синтаксису або зони на вашому BIND/PowerDNS.

 

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

 

Таблиця швидкої діагностики

Симптом	Що це найчастіше означає	Що зробити насамперед
Не відкривається лише у вас	Локальний DNS, кеш, VPN або файл hosts	Перевірити через мобільний інтернет, змінити DNS на 1.1.1.1 / 8.8.8.8
Не відкривається ні в кого	Проблема із DNS-зоною або делегуванням	Виконати dig example.com і dig NS example.com
Відкривається за IP, але не за доменом	Відсутній або некоректний A-запис	Перевірити A/CNAME у панелі DNS
Працює example.com, але не www	Немає запису для www	Додати A/CNAME для www
Після зміни записів то працює, то ні	Триває DNS-пропагація / кешування	Перевірити TTL і дочекатися оновлення кешу
В офісі не працює, а вдома працює	Корпоративний DNS або фільтрація	Перевірити резолвери, split DNS, conditional forwarding

Ця таблиця допоможе вам швидко визначитися, в якому напрямку копати, що в підсумку заощадить купу часу.

 

 

 

 

Діагностика ERR_NAME_NOT_RESOLVED

Тепер час переходити до практики. По суті, для локалізації проблеми вам потрібно відповісти лише на три питання:

• Домен взагалі існує в DNS?
• На які NS він делегований?
• Чи повертається A/CNAME?

 

Давайте розберемо пару команд і з'ясуємо, на що саме дивитися у відповіді.

 

Команда dig - перевіряємо, чи віддається IP, чи існує A/AAAA запис

Синтаксис даної команди гранично простий:

dig example.com

 

На що звертати увагу:

• status: NOERROR- означає, що домен існує, відповідь коректна, але A-запис може бути порожнім, якщо не прописаний;
• status: NXDOMAIN- домен взагалі не існує в DNS, він або не делегований, або існує помилка імені або зони;
• status: SERVFAIL - сервер не зміг обробити запит. Часто це означає, що проблеми на авторитетних NS, DNSSEC, недоступність.
• Розділ ANSWER SECTION: чи є A/AAAA-записи.

Якщо розділ ANSWER порожній - це і є причина, що означає, що IP не знайдено.

 

 

2) Команда dig NS - перевіряємо делегування

За синтаксисом знову ніяких сюрпризів:

dig NS example.com

 

У відповіді повинні бути NS-сервери. Якщо NS немає або вони явно не ті, які ви очікуєте, проблема може бути в делегуванні у реєстратора цього домену.

Далі логіка проста:

• домен делегований на NS;
• ці NS повинні відповідати;
• на них повинна бути зона;
• в зоні повинні бути записи.

 

 

Перевіряємо авторитетну відповідь безпосередньо

Якщо ви знаєте, що NS домену - ns1.example.net, можна запитати його безпосередньо:

dig @ns1.example.net example.com A

 

 

Якщо публічний dig example.com дає дивні результати, а прямий запит до NS показує іншу інформацію - це з великою ймовірністю означає, що десь по шляху інформація або закешувалася, або по шляху є зайвий резолвер.

 

 

Команда dig +trace - де саме зламалося

Набираємо в командному рядку:

dig +trace example.com

 

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

 

 

 

 

DNS-пропагація і TTL: чому у когось працює, у когось ні

Один з найнервовіших моментів при роботі з DNS - це ситуація, коли після зміни записів сайт починає поводитися неоднаково. У одного користувача відкривається нова версія, у іншого - стара, а у третього взагалі відображається помилка. З боку це виглядає як хаос або нестабільність сервера, хоча найчастіше причиною служить звичайне кешування DNS запитів.

Нам з вами важливо розуміти, що DNS не оновлюється миттєво по всьому світу. Це розподілена система, і зміни, внесені в дані про домен, поширюються поступово від одного сервера до вищого в ієрархії, а від них вниз до інших.

Існує ще такий параметр, як TTL (Time To Live) - це час життя DNS-запису в кеші. По суті, це інструкція резолверу про те, скільки секунд можна зберігати той чи інший запит, не перевіряючи його знову.

Якщо у запису встановлено TTL 3600, це означає, що резолвер має право зберігати отриману IP-адресу протягом однієї години і не запитувати її заново у авторитетного сервера. Поки TTL не закінчився, резолвер буде продовжувати віддавати стару відповідь, навіть у випадку, якщо ви вже змінили запис.

Так чому ж виникає ефект нестабільної роботи? Все просто.

Проблема в тому, що кешування відбувається не в одному місці. У ланцюжку кешування беруть участь і рекурсивні DNS-сервери провайдерів, і корпоративні DNS всередині компаній тощо, аж до кешу самого браузера. Кожен з них може зберігати стару відповідь до закінчення TTL і в результаті виходить, що частина користувачів вже отримує новий IP, а частина все ще бачить старий. А якщо при зміні запису була допущена помилка, деякі резолвери і зовсім можуть тимчасово кешувати навіть негативну відповідь (наприклад, NXDOMAIN).

З боку це виглядає як нестабільність сайту, але насправді це нормальна робота механізму кешування, до розуміння якого ми щойно наблизилися.

 

Практичне правило для продакшн-проектів

Якщо ви плануєте перенесення вашого сайту або зміну IP, то не варто змінювати запис в останній момент. Набагато правильніше і безпечніше буде заздалегідь, за 24-48 годин, знизити TTL (наприклад, до 300 секунд). Тоді кеш буде оновлюватися швидше, і перемикання відбудеться м'якше і передбачуваніше.

Після завершення міграції TTL можна повернути до більш високого значення, щоб знизити навантаження на DNS-сервери.

 

 

 

 

Усунення помилки ERR_NAME_NOT_RESOLVED

Тепер переходимо до конкретики - що робити, якщо помилка вже виникла. Нагадаємо, що в цьому випадку важливо діяти не хаотично, а виходячи з того, що ми вже вивчили: спочатку зрозуміти, де проблема, а потім усувати її на відповідному рівні.

Як ми вже визначилися, всі ситуації умовно діляться на дві групи: проблема локальна (у конкретного користувача) і проблема на стороні домену або DNS-зони. Підхід в цих випадках буде різним.

 

Якщо проблема локальна

Локальна проблема означає, що домен в цілому існує і у більшості користувачів відкривається, але на конкретному комп'ютері або в конкретній мережі виникають проблеми. Це найчастіший сценарій після недавніх змін DNS. Що робити в такому випадку?

 

Очищення DNS-кешу

Операційна система і браузер можуть зберігати старі відповіді DNS. Навіть якщо запис вже оновлено на сервері, локальний резолвер може продовжувати використовувати старий IP. Очищаємо кеш на Windows:

ipconfig /flushdns

 

На Linux (systemd-resolved):

sudo resolvectl flush-caches sudo systemctl restart systemd-resolved 

 

Якщо використовується nscd:

sudo systemctl restart nscd 

 

Після очищення кешу система перестане використовувати застарілий IP і запросить свіжі дані у DNS-сервера.

 

 

Перевірка файлу hosts

Файл hosts має пріоритет над DNS, тому якщо в ньому є запис для вашого домену, то система взагалі не буде звертатися до зовнішніх DNS-серверів.

На Linux/macOS файл знаходиться за адресою:

/etc/hosts 

 

На Windows:

C:\Windows\System32\drivers\etc\hosts

 

 

Шукайте рядки з вашим доменом і перевіряйте, що там написано. Особливо зверніть увагу, якщо поруч з вашим доменом стоїть або стара IP-адреса, або локальна 127.0.0.1, або навіть 0.0.0.0.Виправте цей запис на дійсну IP-адресу і перезапустіть систему.

 

 

Тимчасова зміна DNS-сервера

Іноді проблема не в домені, а в DNS-сервері провайдера. Він може кешувати застарілі дані або тимчасово працювати нестабільно.

Для перевірки можна тимчасово вказати інші, публічні DNS-сервери в налаштуваннях мережі вашого комп'ютера. Найбільш популярними публічними DNS є сервери Cloudflare - 1.1.1.1 і 1.0.0.1, а також сервери Google - 8.8.8.8 і 8.8.4.4.

Це в жодному разі не означає, що публічні DNS чимось кращі. У деяких випадках, при падінні такого публічного сервера - проблеми спостерігаються в більшій частині інтернету, так як дуже багато хто їх використовує. Ні, це просто спосіб перевірки, так як якщо з новим DNS все працює, значить, проблема була саме на стороні вашого провайдера.

 

 

Відключення VPN або проксі

VPN часто підміняє DNS-запити і використовує власні резолвери. Це може призводити до таких проблем, як:

• неможливість розпізнати домен;
• використання застарілого кешу;
• проблеми з DNSSEC;
• фільтрація певних зон.

Вимкніть ваш VPN і якщо без нього сайт відкривається, тоді проблема саме в налаштуваннях VPN.

 

 

 

Якщо проблема на стороні домену

Цей сценарій є більш критичним для власників сайтів. Адже якщо ваш домен не резолвується глобально, то користувачі просто не можуть потрапити на проект. Тут вже потрібно перевіряти інфраструктуру DNS.

 

Перевірка статусу домену

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

У панелі реєстратора зазвичай відразу видно, чи активний домен, чи не заблокований він, а також чи не відключена делегація.

 

 

Перевірка делегування (NS-записів)

Якщо домен делегований на неправильні NS-сервери, то будь-які зміни в правильній панелі DNS не матимуть значення, адже Інтернет буде звертатися туди, куди вказав реєстратор. Тому наступним кроком потрібно перевірити:

• які NS вказані у реєстратора;
• чи збігаються вони з тими, на яких ви дійсно керуєте зоною.

 

Дуже часто зустрічається помилка, коли зона налаштована в одній панелі у одного реєстратора, а домен делегований на інші NS-сервери, наприклад, які зовсім не належать до цього реєстратора.

 

 

Перевірка доступності авторитетних NS

Навіть якщо NS вказані правильно, вони повинні реально відповідати на запити. Тоді слід виконати перевірку безпосередньо:

dig @ns1.example.net example.com A 

 

Якщо сервер не відповідає або повертає помилку, значить проблема в роботі DNS-сервера або в конфігурації зони.

 

 

Перевірка наявності та коректності A/CNAME-записів

Найбанальніша, але й найпоширеніша причина - це коли запис просто відсутній або вказаний невірно.

У панелі управління вашим доменом перевірте:

• чи є A-запис для кореневого домену (@);
• чи є запис для www, якщо використовується;
• чи не вказує запис на старий IP;
• чи не створено AAAA-запис (IPv6), якщо сервер не обслуговує IPv6;
• чи немає конфліктів між CNAME та іншими записами.

 

 

І ще раз нагадуємо, що при локалізації та усуненні проблеми ERR_NAME_NOT_RESOLVED потрібно діяти послідовно:

• спочатку локальний рівень;
• потім делегування;
• потім авторитетні NS;
• потім конкретні записи.

Коли ви рухаєтеся по цьому ланцюжку, то ймовірність швидкого пошуку і виправлення причин помилки збільшується.

 

 

 

 

Профілактика помилки ERR_NAME_NOT_RESOLVED

Про DNS зазвичай згадують тільки тоді, коли щось вже зламалося. Але на практиці саме DNS є вашою, навіть вхідною точкою у ваш проект. Можна мати ідеально налаштований сервер, відмовостійкий кластер і продуманий CI/CD, але якщо домен перестав резолвитися, то користувачі просто не потраплять на сайт.

А щоб уникнути таких ситуацій, достатньо впровадити всього кілька базових практик.

 

Мінімум два авторитетних DNS-сервери

Для публічного домену нормою вважається наявність як мінімум двох NS-серверів, бажано в різних мережах або локаціях. Це не надмірність заради галочки, а захист від ситуації, коли один сервер стає недоступним.

 

 

Моніторинг саме DNS, а не тільки сайту

Частою помилкою є моніторинг тільки HTTP/HTTPS. Але якщо DNS перестав працювати, до веб-сервера справа просто не дійде. Тому має сенс контролювати також:

• чи резолвується A-запис домену;
• чи резолвується www;
• чи відповідають авторитетні NS.

 

Це можна налаштувати в Zabbix, Prometheus (через blackbox_exporter) або в будь-якому зовнішньому сервісі моніторингу. Головне - це перевіряти резолвінг саме зовні, з інтернету, а не зі своєї інфраструктури.

 

 

Контроль термінів дії домену та автопродовження

Багато раптових падінь бувають пов'язані не з технічними проблемами, а з організаційними, коли термін дії домену закінчився, лист від реєстратора потрапив у спам або платіж за інвойсом не пройшов.

Мінімальний набір заходів для виключення цих варіантів - це:

• включити авто-продовження;
• вказати актуальний email для повідомлень;
• мати резервний спосіб оплати.

 

Це банально, але саме такі дрібниці часто стають причиною реальних простоїв.

 

 

Планування міграцій заздалегідь

Якщо ви плануєте зміну IP або перенесення проекту, не змінюйте запис в останній момент. Краще за 1-2 дні до міграції знизьте TTL (наприклад, до 300 секунд) і тоді кеші будуть оновлюватися швидше, а перемикання пройде набагато спокійніше.

Після стабілізації можна повернути TTL до більш високого значення.

 

 

Перевірка зони перед публікацією

Якщо ви керуєте зоною самостійно (наприклад, через BIND), корисно перевіряти її перед перезапуском DNS-сервера:

named-checkzone example.com /etc/bind/zones/db.example.com

 

Так можна виявити синтаксичні помилки до того, як вони стануть проблемою для користувачів.

 

У підсумку профілактика DNS - це не про побудову складної архітектури, а про акуратність і контроль. Коли зона коректна, сервери зарезервовані, домен продовжений, а резолвінг моніториться, то ERR_NAME_NOT_RESOLVED стає рідкісним винятком, а не регулярним головним болем.

 

 

 

 

FAQ

 

Чому сайт відкривається за IP, але не за доменом?

Тому що DNS не повертає IP. Сервер живий, але домен не вказує на нього (немає A-запису або він неправильний).

 

Чи може SSL/сертифікат викликати ERR_NAME_NOT_RESOLVED?

Ні. SSL починається після отримання IP і встановлення з'єднання. При ERR_NAME_NOT_RESOLVED до SSL не доходить.

 

Скільки триває DNS-пропагація?

Залежить від TTL і кешів. Зазвичай від хвилин до доби. 48 годин - це верхня планка для погано керованих кешів, але на практиці найчастіше це відбувається набагато швидше.

 

Чи може Cloudflare/CDN бути причиною?

Так. Особливо при неправильних NS у реєстратора, вимкненій зоні, конфлікті DNSSEC, помилках у записах всередині CDN.

 

Чи може firewall викликати ERR_NAME_NOT_RESOLVED?

Ні. Firewall може дати timeout, connection refused і подібне. ERR_NAME_NOT_RESOLVED виникає раніше - коли IP ще не отримано.

 

 

 

 

 

Висновки

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

У більшості випадків причина виявляється досить приземленою, наприклад відсутній A-запис, неправильно налаштовано делегування, домен закінчився або кеш ще тримає старі дані після міграції. Рідше бувають більш глибинні проблеми, коли не відповідають авторитетні NS, виникає SERVFAIL, конфліктує DNSSEC, некоректно налаштований split DNS в корпоративній мережі або є помилки в CoreDNS всередині Kubernetes.

Ключем до успішного і швидкого вирішення є не гадання про причини, а методичні дії за простим алгоритмом. Кілька простих команд, таких як dig з параметрами, дозволяють швидко зрозуміти, де саме стався збій, на рівні кешу, резолвера, делегування або самої зони. Коли точка відмови знайдена, помилка перестає бути великою проблемою і перетворюється вже на звичайне інфраструктурне завдання, яке потрібно вирішити.