Debian 13 — «Не вдалося розв’язати ім’я хоста»: DNS/проксі/IPv6 — найшвидший шлях тріажу

October 2, 2025 • February 3, 2026 • Читання: 9 хв • Views: 4

Було корисно?

02:17, вікно розгортання майже закривається, і apt раптом відмовляється щось завантажувати. Помилка приголомшливо проста: Could not resolve host. Ви бачите, що машина має лінк. Ви можете пропінгувати IP. Але кожне ім’я хоста ніби зникло з інтернету.

У цей момент важливі інстинкти роботи в проді. Не «пробуйте випадкові виправлення» і точно не перезавантажуйте як діагностичний інструмент. Проводьте тріаж розв’язування імен так само, як інцидент з дисковою підсистемою: знайдіть межу, доведіть, де рве, і змінюйте по одному параметру.

Швидкий план діагностики

Це шлях «зупинити кровотечу». Він орієнтований на швидкість, а не на елегантність. Ви намагаєтеся швидко відповісти на три питання:

Чи може ця машина взагалі дістатися до будь-якого резолвера?
Чи відповідає резолвер правильно?
Чи обходить застосунок ваш резолвер через проксі/IPv6/NSS-особливості?

По-перше: доведіть, чи DNS — це проблема, або просто перше, що відпало

Перевірте IP-зв’язність до чогось стабільного (шлюз, резолвер, відомий публічний IP якщо політика дозволяє). Якщо IP-зв’язність не працює, діагностика DNS — це театр.
Розв’яжіть через системний шлях (getent) і прямим інструментом (dig або resolvectl). Якщо вони не узгоджуються, ви знайшли лінію розлому.

По-друге: знайдіть, який резолвер використовується і його апстрім

Прочитайте /etc/resolv.conf і перевірте, чи це заглушка (127.0.0.53) або реальні сервери.
Використайте resolvectl, щоб побачити, які DNS-сервери налаштовані по посиланню і чи використовується DNSSEC/DoT.

По-третє: перевірте «невидиму» маршрутизацію застосунків: проксі та пріоритет IPv6

Проксі: перевірте змінні середовища та шматочки конфігурації APT. Проксі може зробити враження, що DNS зламаний, оскільки проксі виконує резолюцію (або не виконує).
IPv6: якщо хост отримує AAAA-записи, але не може маршрутизувати IPv6, ви побачите таймаути й помилки виду «could not resolve host» залежно від клієнта.

Якщо поспішайте: почніть із Завдань 1–6 нижче. Вони зазвичай скажуть, куди копати далі.

Що насправді означає «Could not resolve host»

Ця фраза з’являється в кількох клієнтах (curl, wget, git, іноді apt через свій HTTP-стек). Це не одинична помилка. Це сімейство збоїв, які закінчуються одним й тим самим знизанням плечима: «Я намагався перетворити ім’я на адресу, і нічого не отримав».

У Debian 13 звичні складові:

розв’язування імен glibc (NSS) через /etc/nsswitch.conf
/etc/resolv.conf (або реальний файл, або симлінк у простір systemd)
systemd-resolved (якщо увімкнено) і його локальний stub
NetworkManager або systemd-networkd, що передає DNS-сервери для resolved
клієнти VPN, що роблять split-DNS, іноді невірно
конфігурація проксі (змінні середовища, конфіг APT, корпоративні PAC-файли)
пріоритет і політика IPv6 (Happy Eyeballs допомагає, але не рятує від зламаного v6)

Одна надійна мантра: «Could not resolve host» — це симптом. Ваше завдання — визначити, який шар бреше.

Жарт #1: DNS — єдина розподілена система, де забута крапка може зіпсувати вам день і вихідні.

Цікаві факти та історичний контекст

Це не тривіал для тривіалу. Кожен пункт пояснює, чому сучасне розв’язування імен у Linux поводиться так, як воно поводиться, і чому «прості» виправлення можуть бути пастками.

/etc/hosts існує задовго до DNS. Ранні системи ARPANET використовували єдиний централізований файл HOSTS.TXT; DNS замінив цю проблему масштабування делегацією.
Бібліотека резолвера — це не саме «DNS». У Linux glibc NSS вирішує, чи звертатися до files, DNS, mDNS, LDAP, SSSD тощо. DNS — лише один модуль.
resolv.conf був спроектований для статичних мереж. Ноутбуки, DHCP, VPN split DNS і контейнери зробили його полем бою, де кілька демонів змагаються за контроль (часом не дуже чемно).
systemd-resolved ввів локальний stub за замовчуванням у багатьох дистрибутивах. Вхід 127.0.0.53 не є «помилкою»; це локальний форвардер і кеш — поки щось інше навколо нього не зламається.
Негативне кешування існує. Резолвери можуть кешувати «NXDOMAIN», тож транзитна відмова апстріму може лишитися як «цього хоста не існує» на деякий час.
Таймаути DNS можуть виглядати як невдачі розв’язання. Багато клієнтів відображають «таймаут при зверненні до DNS» як загальні помилки, бо їм важливо лише те, що вони не отримали адресу.
DNSSEC і DoT — це компроміс на надійність. Валідація і шифрування додають режими відмов: зсув годинника, заблокований порт 853 або проміжні пристрої, які неправильно обробляють EDNS0.
IPv6 зламало багато припущень. Двостек означає, що ви можете «успішно розв’язати» AAAA, але не зможете підключитися, якщо маршрут v6 частково налаштовано.
Корпоративні проксі іноді виконують резолюцію за вас. Ваш клієнт може зовсім не робити DNS; він передає ім’я проксі й чекає. Це змінює шлях налагодження.

Дерево рішень: DNS vs проксі vs IPv6 vs маршрутизація

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

1) Чи можете ви дістатися до чогось по IP?

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

2) Чи працює системний шлях резолвера?

Використайте getent ahosts, бо він проганяє той же шлях, який використовує більшість застосунків (NSS). Якщо getent відмовляє, у вас системна проблема резолвера. Якщо getent працює, а curl — ні, шукайте налаштування проксі, перевизначення DNS на рівні застосунка або поведінку при підключенні по IPv6.

3) Чи використовуєте ви systemd-resolved, і чи чесний /etc/resolv.conf?

У багатьох випадках /etc/resolv.conf вказує на stub, який не слухає (resolved вимкнено), або вказує на застарілі DHCP-резолвери, до яких ви не маєте доступу (VPN змінив мережу). Це нудно й часто трапляється.

4) Чи перебуваєте ви в проксі-режимі?

Корпоративні мережі люблять проксі. Декотрі використовують явні проксі через змінні середовища; інші примушують прозорий проксі або PAC. Якщо APT має налаштований проксі, але проксі недоступний, ви можете отримати оманливі помилки, що виглядають як DNS.

5) Чи створює IPv6 цикл «резолюція вдала, підключення невдале»?

Багато інструментів спочатку запитують AAAA й пробують IPv6. Якщо IPv6 DNS працює, але маршрутизація IPv6 зламана, ви побачите повільні помилки. Деякі клієнти узагальнюють це як помилку розв’язання. Ваше завдання — відокремити «я отримав адресу» від «я можу дістатися адреси».

Практичні завдання: команди, вивід, і рішення

Це реальні завдання, які можна виконати на Debian 13. Кожне містить (a) команду, (b) що типовий вивід означає, і (c) яке рішення ви робите далі. Виконуйте їх по порядку, поки не знайдете розходження.

Task 1: Confirm the error surface (which tool, which hostname)

cr0x@server:~$ apt-get update
Ign:1 http://deb.debian.org/debian trixie InRelease
Err:1 http://deb.debian.org/debian trixie InRelease
  Could not resolve 'deb.debian.org'
Reading package lists... Done
W: Failed to fetch http://deb.debian.org/debian/dists/trixie/InRelease  Could not resolve 'deb.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.

Що це означає: APT не може розв’язати ім’я репозиторію. Це може бути DNS, конфігурація проксі або невідповідність резолвера.

Рішення: Не редагуйте поки нічого. Перейдіть до перевірки IP-зв’язності і системного резолвера.

Task 2: Verify interface state and default route

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens3             UP             10.10.20.15/24 2001:db8:20::15/64

cr0x@server:~$ ip route
default via 10.10.20.1 dev ens3
10.10.20.0/24 dev ens3 proto kernel scope link src 10.10.20.15

Що це означає: У вас є IPv4-адреса і маршрут за замовчуванням. На папері вихід має працювати.

Рішення: Перевірте досяжність шлюзу і відомого IP.

Task 3: Test raw IP connectivity (gateway, then a known IP)

cr0x@server:~$ ping -c 2 10.10.20.1
PING 10.10.20.1 (10.10.20.1) 56(84) bytes of data.
64 bytes from 10.10.20.1: icmp_seq=1 ttl=64 time=0.358 ms
64 bytes from 10.10.20.1: icmp_seq=2 ttl=64 time=0.311 ms

--- 10.10.20.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1020ms
rtt min/avg/max/mdev = 0.311/0.334/0.358/0.023 ms

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=8.29 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=8.10 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 8.100/8.195/8.290/0.095 ms

Що це означає: Мережевий шлях до інтернету по IP працює. Це сильно вказує на проблему резолвера або проксі.

Рішення: Перевірте поведінку системного резолвера за допомогою getent.

Task 4: Test resolution through NSS (what most apps actually use)

cr0x@server:~$ getent ahosts deb.debian.org

Що це означає, якщо порожньо: NSS не зміг видавати жодних адресних записів. Це системна проблема резолвера, а не «APT дивний».

Рішення: Перевірте /etc/nsswitch.conf і конфігурацію резолвера (/etc/resolv.conf, resolvectl).

Task 5: Inspect NSS order (hosts resolution sources)

cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns

Що це означає: Система перевіряє /etc/hosts, потім mDNS, потім DNS. Це типовий десктопний дефолт; на серверах mDNS може бути підводним каменем, якщо він поводиться некоректно.

Рішення: Якщо розв’язування повільне або нестабільне, подумайте, чи не заважає mDNS. Але не змінюйте цього одразу — спочатку підтвердіть, чи DNS доступний.

Task 6: Check /etc/resolv.conf identity and contents

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 29 01:40 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example

Що це означає: Ви використовуєте локальний stub systemd на 127.0.0.53. Це нормально, якщо systemd-resolved працює і апстрім-сервери налаштовані коректно.

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

Task 7: Check systemd-resolved health and upstream DNS

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-29 01:39:12 UTC; 52min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
   Main PID: 512 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 4662)
     Memory: 6.2M
        CPU: 620ms
     CGroup: /system.slice/systemd-resolved.service
             └─512 /lib/systemd/systemd-resolved

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens3)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.example

Що це означає: resolved активний і пересилає на 10.10.0.53/54. Без DoT, DNSSEC не валідований. Виглядає нормальним.

Рішення: Тепер протестуйте запити безпосередньо до налаштованого DNS-сервера, щоб виявити проблеми з фаєрволом/VPN/split DNS.

Task 8: Query the upstream DNS directly (bypass stub)

cr0x@server:~$ dig @10.10.0.53 deb.debian.org A +time=2 +tries=1

; <<>> DiG 9.18.33-1-Debian <<>> @10.10.0.53 deb.debian.org A +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Що це означає: Ваш апстрім DNS-сервер недосяжний (таймаут). Це може бути маршрутизація, фаєрвол або ви в неправильній мережі для цього резолвера (класична помилка split DNS у VPN).

Рішення: Перевірте, чи можете дістатися 10.10.0.53 взагалі (ICMP може бути заблокований; спробуйте TCP/UDP 53). Перевірте VPN і маршрути.

Task 9: Test reachability to DNS server on port 53 (TCP and UDP)

cr0x@server:~$ nc -vz -w 2 10.10.0.53 53
nc: connect to 10.10.0.53 port 53 (tcp) timed out: Operation now in progress

cr0x@server:~$ sudo timeout 2 bash -c 'cat < /dev/null > /dev/udp/10.10.0.53/53' && echo ok || echo failed
failed

Що це означає: Намагаючись по TCP і UDP обидва не вдаються. Це не «DNS неправильно введено»; це недосяжність мережі до резолвера.

Рішення: Виправте маршрутизацію/VPN/фаєрвол до резолвера, або тимчасово переключіться на доступні резолвери (якщо політика дозволяє), щоб відновити сервіс.

Task 10: Identify who configured DNS (DHCP, NetworkManager, networkd, VPN)

cr0x@server:~$ systemctl is-active NetworkManager
inactive

cr0x@server:~$ systemctl is-active systemd-networkd
active

cr0x@server:~$ networkctl status ens3 --no-pager
● 2: ens3
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /etc/systemd/network/10-ens3.network
                          Type: ether
                         State: routable (configured)
                  Online state: online
                       Address: 10.10.20.15/24
                                2001:db8:20::15/64
                       Gateway: 10.10.20.1
                           DNS: 10.10.0.53
                                10.10.0.54
                    DNS Domain: corp.example

Що це означає: systemd-networkd надає DNS-сервери. Якщо ці сервери недосяжні з цього сегмента мережі, вам потрібно відкоригувати конфіг networkd або DHCP-скоп.

Рішення: Переконайтесь, що DNS-сервери правильні для цього VLAN/VPN-контексту. Якщо ви нещодавно змінили мережі, це імовірна причина.

Task 11: Verify proxy settings (environment variables)

cr0x@server:~$ env | grep -iE '^(http|https|no)_proxy='
http_proxy=http://proxy.corp.example:3128
https_proxy=http://proxy.corp.example:3128
no_proxy=localhost,127.0.0.1,.corp.example

Що це означає: Ваш shell налаштований на використання проксі. Інструменти на кшталт curl, wget і іноді git будуть це враховувати.

Рішення: Якщо проксі потрібний — перевірте досяжність до нього. Якщо на цій мережі проксі не потрібний — зніміть змінні і перевірте повторно резолюцію.

Task 12: Check APT’s proxy configuration (can override env)

cr0x@server:~$ grep -R --line-number -E 'Acquire::(http|https)::Proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null
/etc/apt/apt.conf.d/30proxy:1:Acquire::http::Proxy "http://proxy.corp.example:3128";
/etc/apt/apt.conf.d/30proxy:2:Acquire::https::Proxy "http://proxy.corp.example:3128";

Що це означає: APT прив’язаний до проксі незалежно від змінних середовища. Якщо цей проксі недосяжний, APT ламається навіть якщо DNS в порядку.

Рішення: Переконайтеся в досяжності проксі; якщо ви поза корпоративною мережею, вимкніть або зробіть умовною цю конфігурацію.

Task 13: Test proxy connectivity and name resolution path

cr0x@server:~$ nc -vz -w 2 proxy.corp.example 3128
nc: getaddrinfo for host "proxy.corp.example" port 3128: Temporary failure in name resolution

cr0x@server:~$ nc -vz -w 2 10.10.30.40 3128
Connection to 10.10.30.40 3128 port [tcp/*] succeeded!

Що це означає: DNS не працює для імені проксі, але IP проксі досяжний. Це типова ситуація, де «DNS впав» — істина, але найшвидша міра — використовувати IP проксі тимчасово (якщо політика дозволяє) або відновити DNS.

Рішення: Оберіть пом’якшення: відновіть DNS апстрім або тимчасово використайте IP-проксі, щоб відновити інсталяції пакунків під час інциденту.

Task 14: Detect IPv6 preference problems (AAAA resolves, connect fails)

cr0x@server:~$ getent ahosts deb.debian.org | head
2a04:4e42:600::644 deb.debian.org
2a04:4e42:400::644 deb.debian.org
146.75.106.132    deb.debian.org

cr0x@server:~$ curl -I https://deb.debian.org --max-time 5
curl: (6) Could not resolve host: deb.debian.org

Що це означає: Це приклад невідповідності: getent повертає адреси, але curl каже, що не може розв’язати. Часто це вказує на налаштування проксі (curl використовує проксі і там збій), або на специфічну конфігурацію DNS у curl (рідко), або на невідповідність плагінів NSS у контейнерах.

Рішення: Запустіть curl з вимкненим проксі і примусовим вибором сімейства адрес, щоб ізолювати проблему.

Task 15: Force curl to bypass proxy and pin address family

cr0x@server:~$ curl -I https://deb.debian.org --noproxy '*' --max-time 5
HTTP/2 200
server: envoy
content-type: text/html
date: Mon, 29 Dec 2025 02:32:11 GMT

cr0x@server:~$ curl -I https://deb.debian.org -4 --max-time 5
HTTP/2 200
server: envoy
content-type: text/html
date: Mon, 29 Dec 2025 02:32:14 GMT

cr0x@server:~$ curl -I https://deb.debian.org -6 --max-time 5
curl: (28) Failed to connect to deb.debian.org port 443 after 5000 ms: Connection timed out

Що це означає: DNS в порядку. IPv4 працює. Підключення по IPv6 таймаутиться. Це не «розв’язування», це проблема маршруту або фаєрволу для IPv6.

Рішення: Або виправте маршрутизацію IPv6 правильно, або тимчасово зменште пріоритет/відключіть IPv6 для ураженого клієнта/системи, доки не виправите мережу.

Task 16: Check IPv6 routes and RA status

cr0x@server:~$ ip -6 route
2001:db8:20::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium

Що це означає: У вас немає IPv6 маршруту за замовчуванням. Ви можете розв’язувати AAAA, але не дістатися до інтернету по IPv6. Це найгірший вид «майже налаштовано».

Рішення: Виправіть RA/маршрут за замовчуванням, або відключіть IPv6 на цьому інтерфейсі (або налаштуйте політику маршрутизації) залежно від намірів вашого оточення.

Task 17: Check whether resolved is listening on the stub

cr0x@server:~$ ss -lntu | grep -E '127\.0\.0\.53:53|:53'
udp   UNCONN 0      0          127.0.0.53:53        0.0.0.0:*
tcp   LISTEN 0      4096       127.0.0.53:53        0.0.0.0:*

Що це означає: Слухач заглушки присутній. Якщо ви не бачите нічого, що слухає на 127.0.0.53:53, а /etc/resolv.conf вказує туди, розв’язування впаде майже для всіх.

Рішення: Якщо не слухає, запустіть/увімкніть resolved або акуратно перемапуйте /etc/resolv.conf на реальні резолвери (тимчасово).

Task 18: Inspect resolved logs for upstream failures and DNSSEC/DoT issues

cr0x@server:~$ journalctl -u systemd-resolved --since "30 min ago" --no-pager | tail -n 30
Dec 29 02:10:21 server systemd-resolved[512]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.10.0.53.
Dec 29 02:10:23 server systemd-resolved[512]: DNS server 10.10.0.53:53 timed out.
Dec 29 02:10:23 server systemd-resolved[512]: Switching to DNS server 10.10.0.54:53.
Dec 29 02:10:25 server systemd-resolved[512]: DNS server 10.10.0.54:53 timed out.
Dec 29 02:10:25 server systemd-resolved[512]: All attempts to contact name servers or networks failed.

Що це означає: Апстрім-резолвери не відповідають. Тут ви перестаєте тикати клієнт і починаєте дивитися на мережеві ACL, стан VPN або здоров’я апстрім-DNS-сервісу.

Рішення: Ескалюйте до власників мережі/DNS з доказами: IP сервера, IP резолверів, часовий діапазон і чи падають UDP/TCP.

Task 19: Validate the resolver config from the application’s perspective

cr0x@server:~$ strace -f -e trace=network,connect,sendto,recvfrom -s 128 getent hosts deb.debian.org 2>&1 | tail -n 15
sendto(3, "\250\310\1\0\0\1\0\0\0\0\0\0\3deb\6debian\3org\0\0\1\0\1", 32, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 32
recvfrom(3, 0x7ffd8c3c6b10, 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [16]) = -1 EAGAIN (Resource temporarily unavailable)

Що це означає: Насправді він намагається 127.0.0.53 і не отримує відповідь вчасно. Це сильно підтверджує проблему зі stub/resolved.

Рішення: Виправте resolved/апстрімну досяжність. Не марнуйте час на правку /etc/hosts, якщо не потрібне хірургічне тимчасове рішення для одного хоста.

Task 20: Quick temporary mitigation (only if policy allows)

Якщо вам потрібні пакунки зараз і у вас є доступний IP резолвер, ви можете тимчасово замінити stub на прямі сервери імен. Це тактика, а не «остаточне рішення».

cr0x@server:~$ sudo cp -a /etc/resolv.conf /etc/resolv.conf.bak
cr0x@server:~$ sudo rm -f /etc/resolv.conf
cr0x@server:~$ printf "nameserver 1.1.1.1\nnameserver 8.8.8.8\n" | sudo tee /etc/resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8

cr0x@server:~$ getent ahosts deb.debian.org | head -n 3
2a04:4e42:600::644 deb.debian.org
2a04:4e42:400::644 deb.debian.org
146.75.106.132    deb.debian.org

Що це означає: Ви обійшли локальний stub і корпоративні резолвери. Це може порушувати політику компанії або зламати внутрішні імена. Використовуйте лише як міст під час інциденту.

Рішення: Після інциденту поверніть все назад і виправте реальну апстрім-причину. Постійні хакі призведуть до майбутніх відмов.

Поширені помилки (симптом → корінь → виправлення)

Цей розділ навмисно конкретний. Ці патерни повторюються, бо їх легко створити і важко помітити під тиском.

1) Симптом: `/etc/resolv.conf` показує 127.0.0.53, але нічого не розв’язується

Корінь: systemd-resolved вимкнено/зупинено, або слухач stub не прив’язаний через конфлікти.

Виправлення: Увімкніть/запустіть resolved і перевірте, що він слухає; або акуратно перемапуйте /etc/resolv.conf на реальний резолвер. Також перевірте наявність конкурента на 53 порту (dnsmasq, unbound).

2) Симптом: `dig` працює, але `apt` і `curl` падають з «could not resolve host»

Корінь: Конфігурація проксі. Ваш CLI-тест DNS виконаний напряму, але застосунок використовує проксі (APT proxy config або змінні середовища) і падає раніше або делегує резолюцію проксі.

Виправлення: Перевірте Acquire::http::Proxy і http_proxy/https_proxy. Тестуйте з вимкненим проксі (--noproxy), щоб підтвердити.

3) Симптом: Розв’язування повільне, періодичне, CPU idle; логи показують таймаути

Корінь: Апстрім-резолвер недосяжний через зміну маршруту VPN, фаєрвол або невірний DHCP DNS. systemd-resolved циклічно перемикає сервери і повторює спроби.

Виправлення: Переконайтесь у досяжності налаштованих резолверів тестами UDP/TCP 53. Відкоригуйте список DNS для мережі, в якій ви зараз.

4) Симптом: AAAA записи є; підключення зависають; іноді помилка каже «could not resolve host»

Корінь: IPv6 увімкнено достатньо, щоб його обирали, але не достатньо, щоб працювати (немає дефолтного v6 маршруту, зламаний фаєрвол, невірна RA).

Виправлення: Або виправте маршрутизацію IPv6 належним чином (переважно), або тимчасово зафіксуйте IPv4 для проблемного клієнта або відключіть IPv6 на інтерфейсі, якщо воно не підтримується.

5) Симптом: Внутрішні імена не працюють, зовнішні працюють (або навпаки)

Корінь: Split DNS і search-домени. VPN очікує корпоративні резолвери для corp.example, але ви використовуєте публічні резолвери; або ваш search domain робить короткі імена невірними.

Виправлення: Використовуйте per-link DNS і routing domain конфігурацію з systemd-resolved (~corp.example) або виправте налаштування DNS, які надає VPN.

6) Симптом: Лише один хост «неможливо розв’язати», і всі правлять /etc/hosts

Корінь: Стійке негативне кешування, невірно налаштований авторитетний DNS або нещодавнє переключення, яке не розійшлося. /etc/hosts «виправляє» одну машину і створює борг підтримки.

Виправлення: Перевірте TTL і авторитетні відповіді. Очистіть кеші там, де потрібно (resolvectl flush-caches) і виправте DNS-записи замість створення винятків у hosts.

7) Симптом: Контейнер не може розв’язати, хост може

Корінь: Runtime контейнера пише свій власний resolv.conf або використовує інший DNS-сервер, який часто блокується політикою мережі.

Виправлення: Перевірте /etc/resolv.conf у контейнері і налаштування DNS runtime. Узгодьте з хостом або використайте внутрішній резолвер, доступний з цієї мережі.

8) Симптом: DNS працює одразу після ребута, потім падає

Корінь: Гонка/перезапис між сервісами, що пишуть конфіг резолвера: DHCP-клієнт vs NetworkManager vs networkd vs VPN-скрипти підняття/опускання.

Виправлення: Виберіть одного власника мережевого стеку на хості. Приберіть конкурента, якщо можливо. Забезпечте, щоб конфіг резолвера керувався послідовно і був під моніторингом.

Жарт #2: Якщо ви «виправляєте» DNS шляхом прописування IP у /etc/hosts, вітаю — ви щойно винайшли конфігураційний дрейф з додатковими кроками.

Три корпоративні міні-історії з фронту

Міні-історія 1: Аутедж через неправильне припущення

У них був стандартний образ для серверів Debian: networkd, resolved і профіль безпеки. Команда підняла нове середовище в іншому сегменті дата-центру і клонувала той самий образ. Усе завантажилося. Моніторингові агенти чекінувалися. Потім розгортання почали падати з «Could not resolve host».

Он-калл припустив, що “DNS має бути падати”, бо помилка так казала. Вони ескалували до команди DNS, яка відповіла (правильно), що сервіс здоровий і відповідає на запити. Тим часом інцидент тривав, бо оновлення пакунків не проходили, контейнерні образи не могли завантажитись, а pipeline сам себе підвантажував у невелику самостворену DDoS.

Справжня причина була нудна: образ мав зашиті IP резолверів старого сегмента. Ті IP були доступні тільки в оригінальному VLAN; новий сегмент за дизайном не мав до них маршруту. Припущення, що «DNS глобальний», філософськи вірне і практично хибне. Корпоративний DNS часто є пер-сегментним для латентності, контролю і політик.

Вони виправили це, отримуючи DNS через DHCP у тому середовищі замість хардкоду, і додали валідацію при старті: якщо налаштовані DNS-сервери недосяжні по UDP/TCP 53, провізія припиняється рано. Наступного дня всі пам’ятали, що «resolve host» — це наполовину іменування, наполовину маршрутизація до резолвера.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Команда платформи хотіла швидші білди. Вони вмикнули DNS over TLS на флоті, бо зашифрований DNS звучав як безкоштовний виграш: приватність, цілісність і сучасність. Це також виглядало добре на рев’ю безпеки.

Через два тижні почалися спорадичні збої в пікові години. Не повні аутеджи — гірше. Деякі хости потребували 20–30 секунд на розв’язання певних імен. CI джоби ламалися. Розробники писали квитки типу «мережа привид». Сам DNS-сервіс був в порядку, але шлях до нього — ні.

Причина була у політиці фаєрвола апстріму, що лімітував або періодично скидала порт 853 при певних паттернах трафіку. UDP/53 був дозволений і стабільний; TCP/853 «дозволено», але ненадійно. Клієнти падали у нечіткі стани: деякі повторювали запити, деякі блокувалися, деякі кешували негативні відповіді. Оптимізація підвищила безпеку, але додала крихку залежність від проміжних пристроїв, що не підтримують її під навантаженням.

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

Міні-історія 3: Нудна практика, що врятувала день

Система у фінансовому підрозділі (коротко: ніхто не хоче даунтайму і ніхто не любить змін) працювала на Debian і мала суворі правила egress. Вони могли спілкуватись лише з невеликою групою внутрішніх сервісів: проксі, внутрішній DNS і кількома зеркалами репозиторіїв у компанії.

Команда зробила одну нудну річ надзвичайно добре: вони зберігали рукбук із відомими коректними виводами стану резолвера. Не теорія. Реальні знімки здорової системи: resolvectl status, ip route, getent hosts для ключових внутрішніх доменів, плюс хто володіє конфігурацією DNS на цьому хості.

Коли «Could not resolve host» вдарив під час вікна змін, вони не вагалися. Порівняли поточні виводи з відомими хорошими. Різниця була миттєвою: DNS-сервери змінилися на загальний список DHCP після рестарту мережевого сервісу. Той список був правильним для десктопів і неправильним для заблокованих серверів. «Нудний» рукбук зекономив 45 хвилин на суперечках про проксі і IPv6.

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

Контрольні списки / покроковий план

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

Checklist A: Fast triage (5–10 minutes)

Захопіть невдалу команду і хостнейм. Репо APT? Git remote? Ім’я проксі? Запишіть.
Перевірте IP-адресу та маршрут за замовчуванням. ip -br addr, ip route.
Пропінгуйте шлюз і відомий IP. Якщо IP не працює — зупиніться і виправляйте маршрути.
Перевірте системний шлях розв’язування. getent ahosts <host>.
Перегляньте /etc/resolv.conf. Заглушка чи прямі сервери.
Якщо заглушка — перевірте resolved. systemctl status systemd-resolved, resolvectl status, ss -lntu | grep :53.
Протестуйте апстрім-резолвери напряму. dig @server host A, потім порт-тести за потреби.
Перевірте проксі. env | grep -i proxy та записи проксі в /etc/apt/apt.conf.d.
Перевірте реальність IPv6. ip -6 route; тестуйте curl -4 vs curl -6.

Checklist B: Safe mitigations (choose one, don’t stack them blindly)

Очистити кеші (добре, коли ви виправили апстрім, але клієнти все ще падають):
```
cr0x@server:~$ sudo resolvectl flush-caches
```
Рішення: Якщо після очищення кешу розв’язування відновлюється, розгляньте апстрімні флапи або негативне кешування.
Перезапустити resolved (добре, коли заглушка зависла, не коли апстрім недосяжний):
```
cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl query deb.debian.org
deb.debian.org: 146.75.106.132                           -- link: ens3
                2a04:4e42:600::644                        -- link: ens3
```
Рішення: Якщо рестарт допоміг, ви все одно маєте з’ясувати причину: чому воно зависло? Перегляньте логи і апстрімну досяжність.
Тимчасово примусити IPv4 для критичної операції (добре, коли IPv6 зламано і потрібен міст):
```
cr0x@server:~$ sudo apt-get -o Acquire::ForceIPv4=true update
Hit:1 http://deb.debian.org/debian trixie InRelease
Reading package lists... Done
```
Рішення: Якщо це працює, заплануйте виправлення IPv6 або постійно налаштуйте політику, якщо IPv6 не підтримується.
Тимчасово обійти проксі для відомих endpoint-ів (добре, коли конфіг проксі невірна):
```
cr0x@server:~$ unset http_proxy https_proxy no_proxy
cr0x@server:~$ curl -I https://deb.debian.org --max-time 5
HTTP/2 200
server: envoy
content-type: text/html
date: Mon, 29 Dec 2025 02:41:22 GMT
```
Рішення: Якщо від unset все працює, вважайте проксі доменом інциденту. Переналаштуйте його правильно замість того, щоб залишати напіввімкненим.

Checklist C: Make it stay fixed (post-incident hardening)

Єдине джерело правди для конфігурації DNS. Виберіть NetworkManager або networkd. Якщо можливо, видаліть інший.
Моніторте досяжність резолверів. Алармуйте, коли налаштовані DNS-сервери не відповідають на UDP/TCP 53.
Зберігайте відомі коректні виводи. Тримайте базові знімки resolvectl status, цільового /etc/resolv.conf і конфігурації проксі.
Задокументуйте власність проксі. Це змінні середовища, конфіг APT чи системна політика? Зробіть явним.
Визначте, що робити з IPv6. Повністю підтримувати або явно відключити. «Якось працює» — не стратегія.

FAQ

1) Чому `ping` по IP працює, а імена хостів відмовляють?

Бо маршрутизація в порядку, але розв’язування імен не працює. Ви довели L3-зв’язність; далі ізолюйте шлях резолвера (getent, /etc/resolv.conf, resolvectl).

2) Чому `dig` працює, але `getent` відмовляє?

dig опитує DNS напряму. getent використовує NSS, який може звернутись до files, mDNS, SSSD або інших джерел перед DNS. Перевірте /etc/nsswitch.conf і чи доступний DNS-модуль через налаштований резолвер.

3) Чи є 127.0.0.53 у `/etc/resolv.conf` багом?

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

4) Як зрозуміти, чи проксі спричиняє «Could not resolve host»?

Вимкніть проксі для одного тесту. Для curl: curl --noproxy '*'. Для APT: тимчасово закоментуйте проксі в /etc/apt/apt.conf.d (або тестуйте в контрольованому середовищі). Якщо помилка зникає — шлях проксі ваш ворог.

5) Чому примусове IPv4 допомагає?

Бо розв’язування повертає A і AAAA, і клієнт може віддати перевагу IPv6. Якщо маршрутизація/фаєрвол IPv6 зламана, з’єднання зависатиме. Примус IPv4 уникає цього шляху. Це міра пом’якшення, а не моральна перемога.

6) Чи варто хардкодити DNS-сервери в `/etc/resolv.conf`?

Як тимчасовий інструмент під час інциденту — іноді. Як довгострокове рішення — зазвичай ні, бо мережевий стек перезапише його, і це ламає split DNS і внутрішні імена. Виправляйте джерело конфігурації (DHCP, networkd, NetworkManager, VPN-клієнт).

7) Чому внутрішні короткі імена резольвляться по-різному на різних хостах?

Через search-домени і split DNS. Один хост може мати search corp.example, інший — ні. Деякі середовища покладаються на короткі імена; інші ні. Стандартизуйте і вживайте FQDN для автоматизації.

8) Як дізнатися, який компонент «володіє» конфігурацією DNS на Debian 13?

Перевірте, який мережевий сервіс активний (NetworkManager vs systemd-networkd), потім використайте resolvectl status і networkctl status. Також перегляньте, чи /etc/resolv.conf є симлінком у директорію systemd-resolve.

9) Який найбезпечніший спосіб дебагу без шкоди проду?

Спочатку використовуйте команди лише для читання (ip, getent, resolvectl, dig, ss, логи). Коли змінюєте щось — міняйте один параметр, записуйте це і будьте готові відкотити.

10) Яку цитату тримати на увазі під час таких інцидентів?

Надія — це не стратегія. — перефразована думка, яку часто повторюють у колах надійності та операцій.

Висновок: наступні кроки, які можна зробити сьогодні

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

Наступного разу, коли «Could not resolve host» з’явиться на Debian 13:

Доведіть IP-зв’язність (ip route, ping шлюз, ping відомий IP).
Доведіть NSS-резолюцію (getent ahosts) і порівняйте з прямим DNS (dig).
Підтвердіть власника резолвера (/etc/resolv.conf симлінк, resolvectl status).
Перевірте проксі і IPv6, бо вони обманюють у спосіб, схожий на DNS.
Застосуйте одне пом’якшення, відновіть сервіс, потім виправте апстрім причину і приберіть пом’якшення.

Зробіть нудливе інвестування: базові знімки виводу, моніторинг досяжності резолверів і рішення щодо підтримки IPv6. Це те, як зробити так, щоб «Could not resolve host» не ставало постійним героєм ваших інцидентів.