DNS Server не відповідає: Повний посібник з усунення несправностей

Помилка "DNS server not responding" означає, що ваша операційна система надіслала запит на розпізнавання до DNS-резолвера і не отримала відповіді протягом часу очікування — тому браузер так і не отримав IP-адресу, необхідну для відкриття TCP-з’єднання. Результатом є збій завантаження сторінки навіть тоді, коли ваше фізичне мережеве з’єднання повністю працює. Першопричина може знаходитися будь-де в ланцюжку розпізнавання: у вашому локальному stub-резолвері, рекурсивному резолвері вашого ISP, авторитетному сервері вище за ієрархією або неправильно налаштованому мережевому пристрої між вами та будь-яким із них.

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

Що насправді відбувається під час DNS-розпізнавання

Перш ніж усувати помилку, розуміння шляху розпізнавання допоможе уникнути зайвих зусиль. Коли ви вводите example.com у браузері:

1. ОС перевіряє свій локальний DNS-кеш (і файл hosts).
2. Якщо кешованого запису немає, stub-резолвер пересилає запит до рекурсивного резолвера, налаштованого на мережевому інтерфейсі (зазвичай це ваш роутер або сервер, призначений ISP).
3. Рекурсивний резолвер проходить ієрархію DNS — кореневі сервери, TLD-сервери імен, авторитетні сервери імен — і повертає кінцевий запис A або AAAA.
4. ОС кешує результат на час дії TTL запису та передає IP браузеру.

Помилка "not responding" зазвичай виникає на кроці 2 або 3. Stub-резолвер надіслав UDP-пакет на порт 53 і отримав тишу. Ця тиша має напрочуд велику кількість причин.

Першопричини помилки DNS Server Not Responding

Збої на стороні DNS-резолвера

• Налаштований рекурсивний резолвер тимчасово перевантажений або недоступний.
• DNS-інфраструктура вашого ISP зазнає DDoS-атаки або проходить технічне обслуговування.
• IP-адреса резолвера змінилася, але ваш пристрій досі зберігає старе значення.

Проблеми з локальною мережею та обладнанням

• Помилки прошивки роутера, що спотворюють DNS-ретрансляцію (поширено на споживчих пристроях після тривалої роботи без перезавантаження).
• DHCP-оренда, що передала застарілу або недійсну адресу DNS-сервера.
• Несправний кабель Ethernet або деградований сигнал Wi-Fi, що спричиняє втрату пакетів саме на UDP-порту 53.

Неправильні налаштування на рівні хоста

• Пошкоджений або отруєний локальний DNS-кеш, що містить застарілі негативні відповіді.
• Вручну введена DNS-адреса, яка є хибною або більше недоступна.
• Запис у файлі hosts, що конфліктує з очікуваною відповіддю DNS.

Втручання програм безпеки

• Брандмауери або засоби захисту кінцевих точок, що блокують вихідний UDP/TCP-порт 53 або перехоплюють DNS-запити для перевірки, а потім відкидають їх.
• VPN-клієнти, що перенаправляють DNS-трафік через тунельний кінцевий вузол, який наразі недоступний.
• Програмне забезпечення батьківського контролю, що діє як локальний DNS-проксі та аварійно завершує роботу без повідомлень.

Проблеми з драйверами та на рівні ОС

• Застарілий або пошкоджений драйвер NIC, що некоректно обробляє UDP-датаграми.
• Служба DNS Client Windows (Dnscache) у зависшому стані.
• Процес mDNSResponder у macOS, що споживає надмірний обсяг пам’яті та перестав відповідати.

Покрокові виправлення: впорядковані за зусиллями та ймовірністю

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

Крок 1: Спочатку визначте масштаб проблеми

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

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Якщо ping 8.8.8.8 успішний, але nslookup example.com завершується невдачею, DNS-розпізнавання є однозначно проблемою. Якщо ping 8.8.8.8 також завершується невдачею, проблема глибша — ймовірно, маршрутизація або фізична підключеність — а DNS є симптомом, а не причиною.

Крок 2: Перезапустіть роутер і модем

Відключення від живлення очищає внутрішній кеш DNS-ретрансляції роутера, скидає DHCP-оренди та відновлює WAN-з’єднання зі свіжими призначеннями DNS-серверів від вашого ISP.

1. Від’єднайте кабель живлення від модема та роутера.
2. Зачекайте повні 30 секунд (конденсаторам потрібен час для розрядки).
3. Спочатку увімкніть модем; зачекайте, поки він повністю синхронізується (стале світло WAN).
4. Потім увімкніть роутер; зачекайте, поки він завершить послідовність завантаження.
5. Підключіть пристрій знову та повторіть тест nslookup з кроку 1.

Граничний випадок: Якщо ваш роутер працює тижнями без перезавантаження, його DNS-ретранслятор (dnsmasq або подібний) може мати повний кеш або витік пам’яті. Деякі роутери, надані ISP, мають відомі помилки, коли DNS-ретранслятор припиняє пересилати запити після певного порогу часу роботи. Перезавантаження — найшвидше виправлення.

Крок 3: Очистіть локальний DNS-кеш

Застарілі або пошкоджені записи кешу змушують ОС повертати хибні результати або генерувати збої пошуку ще до того, як запит покине машину.

Windows:

ipconfig /flushdns

Ви маєте побачити: Successfully flushed the DNS Resolver Cache.

macOS (залежно від версії — використовуйте правильну команду для вашої ОС):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Крок 4: Перейдіть на надійний публічний DNS-резолвер

Якщо DNS-резолвер вашого ISP є проблемою, перехід на добре підтримуваний публічний резолвер — найшвидший обхідний шлях. Таблиця нижче порівнює найпоширеніші варіанти:

Cloudflare 1.1.1.1 стабільно показує найнижчу середню глобальну затримку запитів у незалежних тестах. Quad9 є кращим вибором, якщо ви хочете пасивне блокування доменів шкідливого ПЗ без управління окремим DNS-фільтром.

Зміна DNS у Windows 10/11:

1. Відкрийте Параметри > Мережа та Інтернет > Змінити параметри адаптера.
2. Клацніть правою кнопкою миші на активному адаптері та виберіть Властивості.
3. Виберіть Протокол Інтернету версії 4 (TCP/IPv4) і натисніть Властивості.
4. Виберіть Використовувати такі адреси DNS-серверів.
5. Введіть вибрані вами основний та вторинний IP-адреси резолвера.
6. Натисніть ОК, потім виконайте ipconfig /flushdns для очищення застарілих записів кешу.

Для мереж IPv6 повторіть процес для Протоколу Інтернету версії 6 (TCP/IPv6), використовуючи IPv6-адреси резолвера (наприклад, Cloudflare: 2606:4700:4700::1111 та 2606:4700:4700::1001).

Зміна DNS у macOS:

1. Відкрийте Системні налаштування > Мережа.
2. Виберіть активне з’єднання та натисніть Деталі.
3. Перейдіть на вкладку DNS.
4. Видаліть наявні записи кнопкою –, потім додайте вибрані вами IP-адреси резолвера кнопкою +.
5. Натисніть ОК та Застосувати.

Зміна DNS у Linux (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Крок 5: Перезапустіть службу DNS Client (Windows)

Служба DNS Client Windows (Dnscache) кешує розпізнані імена та керує stub-резолвером. Якщо вона переходить у зависший стан, усі DNS-запити мовчки завершуються невдачею.

net stop dnscache
net start dnscache

Альтернативно, через консоль служб: натисніть Win + R, введіть services.msc, знайдіть DNS Client, клацніть правою кнопкою миші та виберіть Перезапустити. Зверніть увагу, що в деяких збірках Windows 11 опція перезапуску в GUI недоступна — натомість використовуйте метод командного рядка.

Крок 6: Тимчасово вимкніть брандмауер або програмне забезпечення безпеки

Сторонні брандмауери та пакети захисту кінцевих точок іноді перехоплюють DNS-трафік для перевірки і, через конфлікт правил або помилку рушія, повністю відкидають пакети.

Брандмауер Windows Defender (лише для тимчасового тестування):

netsh advfirewall set allprofiles state off

Негайно увімкніть знову після тестування:

netsh advfirewall set allprofiles state on

macOS:

Перейдіть до Системні налаштування > Конфіденційність та безпека > Брандмауер і вимкніть його для тестування.

Якщо вимкнення брандмауера вирішує проблему, не залишайте його вимкненим. Натомість відкрийте редактор правил брандмауера та знайдіть правила, що блокують вихідний трафік на UDP-порту 53 та TCP-порту 53. Додайте явні дозвільні правила для вибраних вами IP-адрес DNS-резолвера.

VPN-клієнти заслуговують особливої уваги тут. Багато VPN-застосунків встановлюють локальний DNS-проксі на 127.0.0.1:53 та перенаправляють усі запити через тунель. Якщо VPN-сервер недоступний, кожен DNS-запит завершується невдачею. Відключіть VPN, перевірте DNS, потім підключіться знову та перевірте налаштування витоку DNS у VPN-клієнті.

Крок 7: Спробуйте інший браузер

Певні розширення браузера — зокрема блокувальники реклами, інструменти конфіденційності та плагіни безпеки — перехоплюють запити DNS-over-HTTPS (DoH) або змінюють поведінку системного резолвера. Якщо DNS працює в одному браузері, але не в іншому, проблема на рівні розширень, а не ОС.

Спочатку перевірте в приватному/інкогніто вікні (розширення зазвичай вимкнені). Якщо це вирішує проблему, вимикайте розширення по одному, щоб визначити винуватця. Якщо проблема зберігається в усіх браузерах, несправність знаходиться на рівні ОС або мережі.

Крок 8: Оновіть або відкотіть мережеві драйвери

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

Windows — оновлення через Диспетчер пристроїв:

1. Натисніть Win + X та виберіть Диспетчер пристроїв.
2. Розгорніть Мережеві адаптери.
3. Клацніть правою кнопкою миші на вашому адаптері та виберіть Оновити драйвер > Автоматичний пошук драйверів.
4. Перезапустіть після встановлення.

Windows — відкат нещодавно оновленого драйвера:

Якщо помилка DNS з’явилася одразу після оновлення Windows, новий драйвер може бути причиною регресії. У Диспетчері пристроїв клацніть правою кнопкою миші на адаптері, виберіть Властивості > Драйвер > Відкотити драйвер.

macOS: Драйвери NIC входять до складу macOS. Застосуйте всі очікувані системні оновлення через Системні налаштування > Основні > Оновлення програмного забезпечення.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Крок 9: Перевірте фізичні мережеві з’єднання

Якщо ви використовуєте дротове з’єднання, деградований кабель Ethernet спричиняє переривчасту втрату пакетів, що непропорційно впливає на протоколи на основі UDP, як-от DNS (який не має вбудованої повторної передачі на прикладному рівні).

• Переустановіть обидва кінці кабелю Ethernet.
• Замініть кабель на заздалегідь справний.
• Перевірте інший порт на роутері або комутаторі.
• Перевірте індикатори LED з’єднання NIC — стале зелене або бурштинове світло підтверджує фізичне з’єднання; блимаюче або відсутнє світло вказує на проблему рівня 1.

Крок 10: Запустіть засіб усунення несправностей мережі Windows

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

Перейдіть до Параметри > Система > Усунення несправностей > Інші засоби усунення несправностей > Підключення до Інтернету та запустіть майстер. Він спробує автоматичне виправлення та повідомить про знайдене. Хоча він не охоплює кожен сценарій, це корисна перевірка, яка займає менше хвилини.

Крок 11: Перевірте та відредагуйте файл hosts

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

Windows — відкрийте з підвищеними привілеями:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Шукайте записи, що перенаправляють поширені домени на 0.0.0.0 або 127.0.0.1. Програмне забезпечення безпеки, блокувальники реклами та шкідливе ПЗ — усі вони змінюють цей файл. Видаліть підозрілі записи, збережіть і очистіть DNS-кеш.

Крок 12: Скидання стека TCP/IP та Winsock (Windows)

Якщо кілька мережевих компонентів налаштовані неправильно, повне скидання стека є швидшим, ніж пошук окремих налаштувань:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Перезапустіть машину після виконання всіх п’яти команд. Це скидає параметри реєстру TCP/IP та каталог Winsock до стандартного стану без впливу на драйвери мережевого адаптера.

Крок 13: Скидання роутера до заводських налаштувань

Використовуйте це як останній засіб перед зверненням до ISP. Заводське скидання видаляє всю користувацьку конфігурацію — SSID Wi-Fi, паролі, правила переадресації портів та будь-які користувацькі налаштування DNS — і відновлює роутер до стану з коробки.

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

Крок 14: Зверніться до вашого ISP

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

• Результати nslookup example.com з використанням як DNS вашого ISP, так і публічного резолвера, наприклад 8.8.8.8.
• Чи є проблема переривчастою або постійною.
• Чи вирішує проблему перехід на мобільну точку доступу (повністю обходячи ваш ISP).

Останній тест є остаточною перевіркою ізоляції ISP.

Конфігурація DNS для адміністраторів серверів

Якщо ви керуєте середовищем VPS Hosting або Виділеним сервером, помилки DNS набувають додаткових вимірів. Неправильно налаштований резолвер на сервері впливає на кожен застосунок, що на ньому працює — веб-сервери, доставка пошти, менеджери пакетів та агенти моніторингу — всі вони залежать від надійного розпізнавання імен.

Перевірте конфігурацію резолвера на Linux-серверах:

cat /etc/resolv.conf

Справний файл повинен містити принаймні два рядки nameserver, що вказують на надійні резолвери:

nameserver 1.1.1.1
nameserver 8.8.8.8

На системах, що використовують systemd-resolved, /etc/resolv.conf є символічним посиланням. Пряме редагування не матиме ефекту. Натомість використовуйте resolvectl:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Перевірте затримку розпізнавання з сервера:

dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

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

Для серверів, що працюють у середовищах cPanel VPS, конфігурація DNS також керується через сторінку Basic cPanel & WHM Setup у WHM. Переконайтеся, що резолвери, вказані там, збігаються з тим, що є в /etc/resolv.conf, щоб уникнути проблем розщепленого розпізнавання.

DNS та реєстрація доменів: зв’язок вище за ієрархією

Помилка "DNS server not responding" для вашого власного домену — а не чужого — часто простежується до конфігурації серверів імен на рівні реєстратора. Якщо ви нещодавно зареєстрували домен або змінили сервери імен через Реєстрацію доменів, поширення займає до 48 годин. Протягом цього часу деякі резолвери по всьому світу досі зберігають старі NS-записи.

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

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

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

Захист DNS: DNSSEC та DNS-over-HTTPS

Стандартні DNS-запити передаються у відкритому вигляді через UDP-порт 53, що робить їх вразливими до атак підробки DNS та отруєння кешу. Дві взаємодоповнювальні технології вирішують цю проблему:

DNSSEC додає криптографічні підписи до DNS-записів, дозволяючи резолверам перевірити, що відповідь є автентичною та не була підроблена. Він захищає цілісність даних, але не шифрує сам запит.

DNS-over-HTTPS (DoH) та DNS-over-TLS (DoT) шифрують весь DNS-запит, запобігаючи підслуховуванню та маніпуляціям на шляху передачі. Сучасні браузери підтримують DoH нативно. Щоб увімкнути його на рівні системи у Windows 11, перейдіть до Параметри > Мережа та Інтернет > [ваш адаптер] > Призначення DNS-сервера > Редагувати та встановіть шифрування на Лише зашифроване (DNS over HTTPS).

Для серверів налаштуйте systemd-resolved для використання DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Якщо ви використовуєте Хостинг електронної пошти або керуєте власним поштовим сервером, правильна конфігурація DNS — зокрема записи SPF, DKIM та DMARC — є критично важливою для доставки. Збої DNS на поштовому сервері не просто порушують вихідний перегляд; вони спричиняють відкладену або відхилену електронну пошту та невдалу перевірку TLS-сертифікатів.

SSL-сертифікати та залежність від DNS

Видача та поновлення TLS-сертифікатів повністю залежать від DNS. Центри сертифікації, що виконують перевірку домену (DV) через виклик DNS-01 ACME, повинні розпізнати TXT-запис _acme-challenge вашого домену. Якщо DNS не працює під час поновлення, автоматизовані інструменти, як-от Certbot, завершаться невдачею мовчки, і ваші SSL-сертифікати закінчать термін дії — разом із ними впаде і HTTPS.

Налаштуйте моніторинг як стану DNS-розпізнавання, так і терміну дії сертифікатів. Проста перевірка на основі cron:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Матриця рішень: локалізація рівня збою DNS

Використовуйте цю матрицю для визначення рівня несправності перед тим, як витрачати час на виправлення, що не стосуватимуться вашої ситуації.

Технічний контрольний список ключових висновків

• Спочатку виконайте ping 8.8.8.8. Якщо це не вдається, DNS не є вашою основною проблемою — спочатку виправте маршрутизацію або фізичну підключеність.
• Завжди очищайте локальний DNS-кеш після зміни налаштувань резолвера; застарілі записи маскуватимуть, чи спрацювало виправлення.
• Перейдіть на Cloudflare 1.1.1.1 або Quad9 9.9.9.9 як першу зміну резолвера — обидва швидші та надійніші за більшість резолверів ISP.
• У Windows, якщо GUI служб робить опцію перезапуску DNS Client недоступною, використовуйте net stop dnscache && net start dnscache з командного рядка з підвищеними привілеями.
• На Linux-серверах ніколи не редагуйте /etc/resolv.conf безпосередньо на системах systemd-resolved — зміни перезаписуються при перезапуску мережі. Використовуйте resolvectl або nmcli.
• VPN-клієнти є частим прихованим винуватцем. Завжди перевіряйте з відключеним VPN перед ескалацією.
• Для ваших власних доменів dig +trace обходить усі кеші та показує точно те, що повертають авторитетні сервери — використовуйте це перед тим, як припускати проблему резолвера.
• Увімкніть перевірку DNSSEC та DNS-over-TLS/HTTPS на виробничих серверах, щоб усунути цілий клас збоїв DNS на основі підробки.
• На серверах відстежуйте стан DNS-розпізнавання та термін дії SSL-сертифікатів разом — збій DNS мовчки спричинить невдачу поновлення сертифіката через кілька днів.

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

Чому DNS не працює, хоча у мене є робоче інтернет-з’єднання?

DNS-розпізнавання використовує UDP-пакети на порт 53, що є окремим від TCP-з’єднань, які ваш браузер використовує для завантаження сторінок. Правило брандмауера, збій DNS-ретранслятора на вашому роутері або недоступний резолвер можуть блокувати порт 53 конкретно, залишаючи весь інший трафік незачепленим. Виконайте ping 8.8.8.8 для підтвердження IP-підключеності, потім nslookup example.com для підтвердження, що DNS є ізольованим збоєм.

Чи безпечно постійно використовувати Google або Cloudflare DNS замість резолвера мого ISP?

Так, для більшості користувачів і випадків використання. Як Google Public DNS, так і Cloudflare 1.1.1.1 підтримують перевірку DNSSEC та пропонують вищі SLA часу безвідмовної роботи, ніж типові резолвери ISP. Компроміс полягає в тому, що ваші DNS-запити обробляються стороннім постачальником інфраструктури, а не вашим ISP. Cloudflare публікує суворі правила відсутності журналювання запитів; Google зберігає анонімізовані журнали до 48 годин.

У чому різниця між очищенням DNS-кешу та зміною DNS-сервера?

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

Чому nslookup успішний, але браузер досі показує помилку DNS?

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

Як діагностувати проблеми DNS на Linux VPS без GUI?

Використовуйте dig, nslookup та resolvectl з командного рядка. Виконайте dig @1.1.1.1 example.com для тестування конкретного резолвера безпосередньо, повністю обходячи локальну конфігурацію. Виконайте resolvectl status для перегляду, який резолвер система наразі використовує та чи активний DNSSEC. Перевірте /etc/resolv.conf для підтвердження налаштованих серверів імен та переконайтеся, що файл не є зламаним символічним посиланням за допомогою ls -la /etc/resolv.conf.