Ubuntu 24.04 «Тимчасова помилка розв’язування імен»: припиніть гадати — виправте DNS правильно

November 24, 2025 • February 3, 2026 • Читання: 7 хв • Views: 16

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

Якщо ви бачите Temporary failure in name resolution на Ubuntu 24.04, ви вже марнуєте час у найгірший спосіб: система запущена, застосунок не працює, а всі звинувачують «мережу».

Ця помилка майже ніколи не містична. Зазвичай це дуже конкретний розрив між вашим застосунком і ланцюжком резолверів: libc → NSS → systemd-resolved → upstream DNS (або локальний stub) → маршрутизація/фаєрвол → фактичний nameserver. Вирішення — не «спробуй 8.8.8.8 і пощастить». Потрібно виміряти кожен хоп і змінити ту одну річ, яка насправді неправильна.

Що насправді означає помилка (і чого вона не означає)

Temporary failure in name resolution зазвичай повертається рівнем резолвера, коли DNS-запит не вдається виконати прямо зараз. У POSIX-термінах це часто EAI_AGAIN, що виходить із getaddrinfo(). Система каже: «Я спробував розв’язати ім’я і не зміг дістатися до працюючого ланцюжка резолверів».

Що це не означає:

«Інтернет не працює.» Ваш маршрут за замовчуванням може бути в порядку.
«DNS неправильно сконфігурований.» Іноді налаштування DNS правильні, але UDP/53 блокується, MTU неправильний або ви маршрутизуєте через неправильний інтерфейс.
«Це обов’язково вина systemd-resolved.» Часто це просто кур’єр.

Що це зазвичай означає в продакшені:

Ваш хост не знає, яких DNS-серверів питати (погана конфігурація, порожня конфігурація, перезаписана конфігурація).
Хост знає, які сервери питати, але не може до них дістатися (маршрутизація, фаєрвол, VPN, зламане з’єднання, відмова DNS-сервера).
Хост досягає DNS-сервера, який відповідає інколи (таймаути, втрата пакетів, EDNS/MTU-проблеми, ненадійний upstream).
Хост запитує неправильний DNS-сервер для імені (split DNS, search domains, неправильний пріоритет інтерфейсів).

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

Швидкий playbook діагностики (перший/другий/третій)

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

Перший: це DNS чи маршрутизація?

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

Другий: чи здоровий systemd-resolved і вказує куди треба?

resolvectl status: перевірте, які DNS-сервери використовуються по зв’язку і глобально.
ls -l /etc/resolv.conf: підтвердіть, чи ви використовуєте stub-резолвер або статичний файл, і чи відповідає це вашим намірам.
systemctl status systemd-resolved: упевніться, що сервіс працює і не застряг у циклі.

Третій: чи доступний обраний DNS-сервер і чи відповідає він?

Перевірте досяжність UDP/TCP до DNS-сервера (таймаути важливіші за «відмову»).
Запитуйте A і AAAA записи з dig; порівнюйте поведінку. IPv6 часто «працює» настільки, щоб відняти у вас день.
Якщо split DNS: упевніться, що запит йде через потрібний інтерфейс і з правильними правилами маршрутизації доменів.

Жарт №1: DNS — єдина система, де «це просто ім’я» може зупинити зарплатню.

DNS-стек Ubuntu 24.04 на практиці

Ubuntu 24.04 (як і останні релізи) зазвичай використовує:

Netplan для визначення мережевої конфігурації (YAML у /etc/netplan/).
systemd-networkd або NetworkManager як мережевий бекенд, залежно від server/desktop і вашої конфігурації.
systemd-resolved як локальний кешуючий stub-резолвер, зазвичай прив’язаний до 127.0.0.53.
NSS (Name Service Switch) правила у /etc/nsswitch.conf, що визначають, чи використовують звернення DNS, файли, mDNS тощо.
/etc/resolv.conf як сумісний інтерфейс для застарілих інструментів. На сучасній Ubuntu це часто симлінк на файл, яким керує systemd.

Практична ментальна модель. Коли застосунок питає «що таке repo.internal.corp?»

Застосунок викликає getaddrinfo().
glibc консультує /etc/nsswitch.conf (рядок hosts:) і вибирає методи.
Для DNS glibc читає /etc/resolv.conf і використовує список nameserver-ів.
Якщо цей файл вказує на 127.0.0.53, запити йдуть до systemd-resolved.
systemd-resolved вибирає upstream DNS-сервер на основі налаштувань по інтерфейсу та доменних правил маршрутизації, потім виконує запит.

Отже, коли ви «редагуєте resolv.conf», ви можете редагувати симлінк, який перезаписується, або обходити передбачений шлях резолвера. Ви можете зробити тимчасово так, щоб працювало, і при цьому поставити пастку для Майбутнього Вас.

Цікаві факти та історичний контекст (коротко, але корисно)

DNS старший за кар’єри багатьох людей. Він був спроектований на початку 1980-х як розподілена заміна єдиному файлу HOSTS.TXT, який тоді всім доводилося завантажувати.
«resolv.conf» — скам’янілість, що відмовляється вмирати. Він все ще універсальний інтерфейс, хоча сучасні системи мають динамічні правила DNS по зв’язках.
systemd-resolved ввів локальний stub за замовчуванням. Тому ви часто бачите nameserver 127.0.0.53 — це не «неправильно», це шар опосередкування.
DNS по UDP швидкий, поки не ні. Втрата пакетів перетворює «швидко» на «загадково повільно», бо повтори і таймаути складаються через бібліотеки і застосунки.
Відкат на TCP важливіший, ніж багато хто визнає. Великі відповіді, DNSSEC або деякі middlebox-и можуть примусити TCP/53, і якщо TCP заблокований — виникають таймаути, що виглядають як випадкові відмови.
Search domains — інструменти продуктивності й генератори відмов. Відсутня крапка може викликати кілька запитів (api стає api.prod.corp, api.corp тощо), додаючи затримку і плутанину.
Негативне кешування існує. Якщо ваш резолвер кешує «NXDOMAIN», а ви щойно створили запис, ви можете витрачати TTL на сперечання з реальністю.
Split DNS став поширеним через VPN і SaaS. Ваш ноутбук/сервер може потребувати публічного DNS для світу і приватного DNS для внутрішніх імен одночасно.
За замовчуванням Ubuntu змінювався з часом. Старі релізи покладалися на resolvconf або прямі DHCP-записи; сучасні — віддають перевагу systemd-інструментам. Копіювання старих playbook-ів може тихо зламати речі.

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

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

Завдання 1: Підтвердьте симптом через системний резолвер (не ping)

cr0x@server:~$ getent ahosts archive.ubuntu.com
getent: Name or service not known

Значення: Це використовує libc/NSS і відображає те, що відчувають більшість застосунків. «Name or service not known» або таймаути тут підтверджують, що це не просто дивний випадок ping.

Рішення: Продовжити налагодження ланцюжка резолвера. Якщо getent працює, але ваш застосунок падає — підозрюйте специфічні налаштування застосунку (контейнери, chroot, кастомні бібліотеки резолвера).

Завдання 2: Перевірте, чи працює IP-маршрутизація взагалі

cr0x@server:~$ ip route
default via 10.0.0.1 dev ens3 proto dhcp src 10.0.0.42 metric 100
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.42

Значення: У вас є маршрут за замовчуванням через 10.0.0.1. Якщо немає маршруту за замовчуванням, DNS може падати, бо нічого не може дістатися upstream-серверів.

Рішення: Якщо маршрут за замовчуванням відсутній/неправильний — виправте мережу спочатку (Netplan, DHCP, стан інтерфейсу) перед тим, як торкатися DNS.

Завдання 3: Пінгніть шлюз за замовчуванням (локальна L2 санітарна перевірка)

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

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1024ms
rtt min/avg/max/mdev = 0.391/0.401/0.412/0.010 ms

Значення: L2/L3 до шлюзу в порядку. DNS-помилки менш імовірно через «мережеву карту померла».

Рішення: Переходьте вгору по стеку: конфігурація резолвера та досяжність DNS.

Завдання 4: Перегляньте /etc/resolv.conf (симлінк розказує історію)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 May  8 10:14 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Цей хост використовує systemd stub-резолвер на 127.0.0.53. Якщо ви «виправляєте DNS», редагуючи /etc/resolv.conf напряму, його ймовірно перезапишуть або він ігноруватиметься.

Рішення: Використовуйте resolvectl і конфігурацію Netplan/NetworkManager замість ручного редагування файлу.

Завдання 5: Переконайтесь, що systemd-resolved працює і не в деградованому стані

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-12-18 09:51:22 UTC; 2h 13min ago
       Docs: man:systemd-resolved.service(8)
             man:resolvectl(1)
   Main PID: 812 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18712)
     Memory: 7.9M
        CPU: 1.231s
     CGroup: /system.slice/systemd-resolved.service
             └─812 /usr/lib/systemd/systemd-resolved

Значення: Сервіс запущений. Це не гарантує, що upstream DNS досяжний, але знімає «демон резолвера впав» зі списку.

Рішення: Перегляньте конфігурацію резолвера і досяжність upstream далі.

Завдання 6: Перевірте конфігурацію резолвера через resolvectl

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.internal

Link 2 (ens3)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.internal

Значення: DNS-сервери — 10.0.0.53 і 10.0.0.54; search domain — corp.internal. Здається правдоподібним. Якщо тут немає DNS-серверів — ви знайшли проблему.

Рішення: Якщо DNS-сервери порожні або неправильні — виправте Netplan/DHCP/NetworkManager. Якщо виглядає правильно, перевірте досяжність та поведінку відповіді.

Завдання 7: Запитайте через systemd-resolved явно

cr0x@server:~$ resolvectl query archive.ubuntu.com
archive.ubuntu.com: resolve call failed: Temporary failure in name resolution

Значення: Це підтверджує, що збій відбувається на рівні або за межами systemd-resolved (а не в якомусь специфічному DNS-настроюванні застосунку).

Рішення: Виконайте прямі запити до upstream DNS-серверів, щоб відділити «resolved» від «upstream-мережі».

Завдання 8: Запитайте upstream DNS-сервер напряму з dig (обійти stub)

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Значення: Налаштований DNS-сервер недосяжний (або не відповідає). Це не проблема «systemd-resolved config»; це проблема досяжності або сама помилка на боці сервера.

Рішення: Перевірте маршрутизацію до DNS-сервера, правила фаєрволу, стан VPN і чи сам DNS-сервер живий.

Завдання 9: Підтвердіть мережеву досяжність DNS-сервера

cr0x@server:~$ ping -c 2 10.0.0.53
PING 10.0.0.53 (10.0.0.53) 56(84) bytes of data.
64 bytes from 10.0.0.53: icmp_seq=1 ttl=63 time=1.12 ms
64 bytes from 10.0.0.53: icmp_seq=2 ttl=63 time=1.09 ms

--- 10.0.0.53 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1014ms
rtt min/avg/max/mdev = 1.09/1.10/1.12/0.015 ms

Значення: Сервер досяжний по ICMP. Це не доводить, що UDP/53 або TCP/53 дозволені, але добрий знак.

Рішення: Тестуйте UDP та TCP DNS явним чином.

Завдання 10: Перевірте поведінку UDP/53 і TCP/53 (бо існують middlebox-и)

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +notcp

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +notcp
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +tcp

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41861
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;archive.ubuntu.com.          IN      A

;; ANSWER SECTION:
archive.ubuntu.com.   60      IN      A       91.189.91.81

;; Query time: 24 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (TCP)
;; WHEN: Wed Dec 18 12:06:12 UTC 2025
;; MSG SIZE  rcvd: 59

Значення: UDP-запити таймаутяться, але TCP працює. Класичний випадок «UDP/53 блокується десь» (локальний фаєрвол, ACL мережі, security group або надмірно сувора політика DNS).

Рішення: Виправте фаєрвол/мережеву політику для UDP/53 або тимчасово змусьте використовувати тільки TCP (неідеально).

Завдання 11: Перевірте локальні правила фаєрволу (UFW та nftables)

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
        chain input {
                type filter hook input priority filter; policy drop;
                ct state established,related accept
                iif "lo" accept
                tcp dport 22 accept
        }
        chain output {
                type filter hook output priority filter; policy accept;
        }
}

Значення: Output дозволений, тож локальний фаєрвол, ймовірно, не блокує вихідний UDP/53. Якщо політика output була б drop або ви мали явний deny — це б і було причиною.

Рішення: Якщо локальний фаєрвол чистий — дивіться на upstream ACL/ security groups / VPC NACLs або на фаєрвол самого DNS-сервера.

Завдання 12: Підтвердіть, який бекенд керує лінком (NetworkManager vs networkd)

cr0x@server:~$ networkctl status ens3
● 2: ens3
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-ens3.network
                          Type: ether
                         State: routable (configured)
                  Online state: online
                       Address: 10.0.0.42 (DHCP4)
                       Gateway: 10.0.0.1
                           DNS: 10.0.0.53 10.0.0.54

Значення: Цей інтерфейс керується systemd-networkd через Netplan-згенерований файл. Ваші DNS-налаштування слід виправляти в Netplan (або в DHCP), а не в NetworkManager.

Рішення: Відредагуйте /etc/netplan/*.yaml відповідно і застосуйте.

Завдання 13: Перегляньте Netplan DNS-конфіг (і помітите «виглядає правильно, поводиться неправильно»)

cr0x@server:~$ sudo netplan get
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true

Значення: DNS приходить від DHCP, а не з статичної конфігурації. Якщо DHCP роздає мертві DNS-сервери — ви впадете, навіть якщо конфіг на хості «чистий».

Рішення: Виправте опції DHCP upstream або перекрийте DNS локально в Netplan для ролі цього хоста.

Завдання 14: Перекрийте DNS-сервери в Netplan (правильний спосіб) і застосуйте

cr0x@server:~$ sudo tee /etc/netplan/50-dns-override.yaml >/dev/null <<'EOF'
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      nameservers:
        addresses: [10.0.0.53, 10.0.0.54]
        search: [corp.internal]
EOF

cr0x@server:~$ sudo netplan apply

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

Рішення: Повторно перевірте resolvectl status і виконайте запит ще раз. Якщо все ще не працює — це не проблема «відсутніх DNS-серверів».

Завдання 15: Перевірте журнали resolved (таймаути лишають відбитки)

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "20 min ago" --no-pager
Dec 18 11:52:07 server systemd-resolved[812]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.0.0.53.
Dec 18 12:02:14 server systemd-resolved[812]: DNS server 10.0.0.53: Timeout while contacting DNS server.
Dec 18 12:02:19 server systemd-resolved[812]: Switching to DNS server 10.0.0.54.

Значення: Resolved таймаутить і перемикається. «Degraded feature set» часто натякає на проблеми MTU/фрагментації, некоректну роботу EDNS0 або middlebox-и.

Рішення: Якщо кілька серверів таймаутять — це досяжність. Якщо тільки один поганий — видаліть/замініть його. Якщо EDNS0 викликає відмови — перевірте MTU/шлях і поведінку DNS-сервера.

Завдання 16: Перевірте порядок NSS (іноді ви навіть не використовуєте DNS)

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

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

Рішення: Якщо запити зависають перед відмовою, подумайте, чи не затримує mDNS або неправильно налаштовані локальні сервіси імен. Не «оптимізуйте» це без розуміння радіусу ураження (див. історії далі).

Жарт №2: Якщо ви хардкодите DNS усюди, рано чи пізно у вас буде розподілена система, що складається виключно з винятків.

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

Інцидент через неправильне припущення: «Це не DNS, бо IP пингується»

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

Репозиторій не був падшим. Білд-ноди використовували корпоративний DNS-форвардер, доступний лише через правило security group, яке нещодавно «пожорсткіли». ICMP був дозволений, TCP/443 був дозволений, але вихідний UDP/53 з того сабнету був видалений. Не зловмисно — просто хтось оптимізував правило у табличці.

Команда втратила години, бо продовжувала тестувати не те. Пінг до DNS-сервера вдався, що підсилювало припущення. Але DNS-запити були UDP і тихо відкидалися. Інструменти збірки повторювали спроби, потрапляли на таймаути і поводилися по-різному в різних мовах та бібліотеках. Тому це виглядало ненадійно.

Виправлення було нудним: відновили вихід UDP/53 із сабнету до форвардерів і задокументували, що DNS — не «просто досяжність». Пізніше додали canary-тест, що виконує dig +notcp і dig +tcp окремо, бо «DNS працює» — це не булева величина.

Оптимізація, що обернулася проти: агресивний кешинг (і кешування неправильних відповідей)

У іншої організації платформа команда захотіла пришвидшити деплои. Вони помітили багато повторюваних DNS-запитів під час pull-ів контейнерів, service discovery і телеметрії. Їхня ідея: агресивніше кешувати і зменшити навантаження на upstream-регесолвери.

Вони розгорнули зміни резолвера широко. Обсяг запитів впав. Графіки виглядали відмінно. Потім почалося дивне: деякі хости не могли дістати нові сервіси протягом хвилин після релізу. Інші розв’язували сервіс на старий IP довго після переміщення. Кілька нод «виліковувалися» після рестарту, що робило інцидент надприродним.

Корінь проблеми не в «кешуванні як такому». Корінь — у кешуванні без дисципліни. Серверні записи мали низький TTL з причини (швидке failover, blue/green). Примусовим довшим кешуванням і шаруванням кешів (кеш на вузлі плюс форвардер) вони фактично помножили поведінку TTL. Негативне кешування додало ще ефект: тимчасові NXDOMAIN відповіді зафіксувалися.

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

Нудна, але правильна практика, що врятувала ситуацію: DNS-настроювання за ролями і тест, з яким неможливо сперечатися

Фінансова організація мала Ubuntu 24.04 сервери у кількох мережевих зонах: користувацька, внутрішня аплікаційна і обмежена для даних. Кожна зона мала трохи різні потреби DNS. Спокусливим був підхід «один golden image» з «однією конфігурацією резолвера». Вони так не зробили.

Вони підтримували Netplan-сніпети за ролями: кожна роль явно декларувала свої DNS-сервери і search domains, з DHCP лише для адресації, а не для довіри до деталей резолвера. Мережна команда все ще надавала DNS через DHCP, але хости не довіряли цьому бездумно.

Ключовий елемент: health check, що запускався на кожному хості кожні кілька хвилин і звітував три показники: (1) getent lookup для внутрішнього імені, (2) dig до кожного налаштованого DNS-сервера по UDP, і (3) тест TCP-фолбеку. Чек давав однозначні режими відмов: «локальний резолвер зламався» vs «DNS-сервер недосяжний» vs «UDP заблоковано».

Коли upstream-зміна зламала UDP для однієї з зон, сигналізація не казала «збій розв’язування імен». Вона казала «UDP/53 заблоковано до dns-a; TCP/53 працює». Мережна команда виправила ACL за кілька хвилин, бо проблема була сформульована точно, а платформа не витрачала час на перезапуски сервісів як ритуал.

Поширені помилки: симптом → корінна причина → виправлення

Ось патерни, які я бачу повторно на Ubuntu 24.04. Симптоми схожі; виправлення — ні.

1) Симптом: `apt update` не працює, але `ping 1.1.1.1` працює

Корінна причина: ланцюжок резолвера зламаний або upstream DNS недосяжний, при тому як загальна маршрутизація працює.
Виправлення: Використайте resolvectl status, щоб ідентифікувати активні DNS-сервери; потім dig @server для тесту досяжності. Виправте DHCP/Netplan DNS або фаєрвол/ACL для UDP/TCP 53.

2) Симптом: `/etc/resolv.conf` показує правильний nameserver, але він постійно повертається назад

Корінна причина: /etc/resolv.conf керується (симлінк на systemd-resolved або згенерований NetworkManager). Ручні правки перезаписуються.
Виправлення: Налаштуйте DNS у Netplan (networkd) або NetworkManager, або відредагуйте /etc/systemd/resolved.conf, якщо хочете глобальний оверрайд. Не бійтеся генератора.

3) Симптом: внутрішні імена не працюють, публічні працюють (або навпаки)

Корінна причина: Split DNS неправильно маршрутизований (вибрано неправильний інтерфейс, відсутні доменні маршрути, DNS VPN не застосований).
Виправлення: Перевірте DNS та домени по посилці в resolvectl status. Переконайтесь, що правильний зв’язок має потрібний DNS Domain і що VPN-клієнт інтегрується коректно (або налаштуйте per-link домени через Netplan/NetworkManager).

4) Симптом: DNS працює деякий час після перезавантаження, потім падає

Корінна причина: оновлення DHCP змінює DNS-сервери, повторне підключення VPN змінює пріоритет зв’язків, або cloud-init/скрипти мережі перезаписують конфіг.
Виправлення: Ідентифікуйте «письменника»: перевірте journalctl на події мережі, підтвердіть Netplan-конфіг і, якщо потрібно, зафіксуйте DNS у Netplan або NetworkManager. Уникайте «разових» правок.

5) Симптом: `dig` працює, але застосунки все ще падають

Корінна причина: Застосунок використовує інший шлях резолвера (контейнер з власним resolv.conf, статична конфігурація DNS, налаштування JVM), або NSS-конфіг відрізняється у середовищі.
Виправлення: Тестуйте getent на хості і всередині контейнера. Порівняйте /etc/resolv.conf і /etc/nsswitch.conf в обох контекстах. Виправте на потрібному шарі.

6) Симптом: UDP-запити таймаутяться, TCP працює

Корінна причина: UDP/53 блокується або пошкоджується; іноді MTU/фрагментація/EDNS призводять до невдач великих UDP-відповідей.
Виправлення: Дозвольте UDP/53. Якщо підозрюєте EDNS/MTU — шукайте «degraded feature set» у логах resolved і валідируйте path MTU або підтримку EDNS на DNS-сервері.

7) Симптом: Дуже повільні пошуки, а потім періодичні відмови

Корінна причина: Розширення search domain викликає кілька запитів; втрата пакетів; один з множинних DNS-серверів кидає пакети.
Виправлення: Використовуйте resolvectl statistics (якщо доступно) і dig з +tries=1 +time=1 до кожного сервера. Видаліть мертві сервери; скоротіть search domains для серверних ролей.

Контрольні списки / поетапний план (зробіть нудно і правильно)

Покроково: відновити DNS на зламаному хості Ubuntu 24.04

Підтвердіть, що це реальна помилка: запустіть getent ahosts example.com. Якщо це працює — ваша проблема вищого рівня (проксі, TLS, конфіг застосунку).
Підтвердіть маршрутизацію: ip route і ping шлюз.
Перевірте режим резолвера: ls -l /etc/resolv.conf.
Огляньте конфіг resolved: resolvectl status і зауважте:
- Глобальні DNS-сервери
- Link-specific DNS servers
- Search/routing domains
- Який лінк позначений як default route
Обійдіть стек: dig @<dns-server> example.com A з коротким таймаутом. Зробіть це для кожного конфігурованого сервера.
Перевірте UDP vs TCP: dig +notcp і dig +tcp до того ж сервера.
Перевірте локальний фаєрвол: ufw status verbose і nft list ruleset.
Виправте правильного власника конфігурації:
- Якщо інтерфейс керує networkd: виправте Netplan YAML і netplan apply.
- Якщо керує NetworkManager: використайте nmcli для встановлення DNS і властивостей з’єднання.
- Якщо DHCP неправильний: виправте опцію 6 upstream, потім оновіть оренду.
Перевірте після змін: resolvectl query, getent та реальний сценарій (apt update, якщо це був шлях, що падав).
Стабілізуйте: додайте невеликий DNS-чек у моніторинг, щоб фіксувати дрейф та часткові відмови до того, як користувачі їх помітять.

Операційний чеклист: запобігти наступному інциденту

Стандартизувати «хто відповідає за DNS-налаштування» по ролі хоста: лише DHCP, Netplan override або політика NetworkManager. Виберіть один підхід.
Мати принаймні два DNS-сервери, але не перераховувати «мертві на потім». Мертвий secondary все одно може коштувати секунд на запит залежно від поведінки повторів.
Документувати split DNS домени і який інтерфейс їх надає (особливо з VPN-клієнтами та overlay-мережами).
Тестувати UDP і TCP DNS у CI для базових образів, якщо ви працюєте у сильно фільтрованих мережах.
Тримати короткі search domains для серверів. Ноутбуки розробників можуть дозволити зручність; production-сервіси потребують детермінізму.
Вирішіть, чи підтримуєте IPv6. Якщо підтримка неповна — ви підписуєтесь на дивні таймаути.

FAQ

1) Чому Ubuntu показує `nameserver 127.0.0.53` у `/etc/resolv.conf`?

Це локальний stub для systemd-resolved. Застосунки питають localhost; resolved пересилає до реальних DNS-серверів на основі per-link конфігурації і кешує відповіді.

2) Чи варто відключити systemd-resolved, щоб «виправити DNS»?

Тільки якщо у вас є чітка причина і план. Відключення може працювати, але це грубий інструмент, що часто ламає split DNS, поведінку VPN і майбутнє обслуговування. Спочатку виправте upstream досяжність або коректно налаштуйте Netplan/NetworkManager.

3) Я відредагував `/etc/resolv.conf` і це спрацювало — чому потім зламалося?

Тому що цей файл часто згенерований. Ваша правка або зачепила stub-файл (який перегенерується), або ви замінили симлінк, який очікує пакет/сервіс. Правильне надійне виправлення — у Netplan, NetworkManager або конфігурації resolved.

4) Чому деякі інструменти працюють, а інші падають (наприклад, `dig` працює, `apt` падає)?

dig може звертатися безпосередньо до конкретного сервера, обходячи системний шлях резолвера. apt зазвичай використовує libc-резолвер і те, що хост надає через NSS і /etc/resolv.conf. Тестуйте getent, щоб відповідати поведінці застосунку.

5) Який найшвидший спосіб відрізнити «проблема конфігурації DNS» від «DNS-сервер недосяжний»?

Запустіть resolvectl status, щоб побачити, який сервер ви використовуєте, потім dig @that-server example.com з коротким таймаутом. Якщо прямий запит таймаутиться — проблема на шляху до сервера. Якщо працює — локальний ланцюжок резолвера неправильно сконфігурований.

6) Чому UDP важливий, якщо TCP працює?

Більшість DNS-запитів за замовчуванням йдуть по UDP для продуктивності. Якщо UDP/53 блокується, багато клієнтів чекатимуть таймауту перед відкатом на TCP (якщо взагалі відкатать). Це виглядає як випадкові відмови і сплески затримки.

7) Як VPN-і викликають «Temporary failure in name resolution» після відключення?

VPN-клієнти часто додають link-specific DNS і доменні маршрути, а потім не чисто відновлюють попередній стан. Ви отримуєте DNS-сервери, які недосяжні після VPN, або інший інтерфейс стає «за замовчуванням» для маршрутизації DNS.

8) Чи варто додавати публічні резолвери (напр., 1.1.1.1) на серверах як fallback?

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

9) Мої DNS-сервери досяжні, але в логах resolved видно «degraded feature set UDP instead of UDP+EDNS0». Це погано?

Це підказка. Зазвичай вказує на шлях, який відкидає фрагментовані UDP-пакети або некоректно обробляє EDNS0. Ви можете іще «працювати», але ви близькі до періодичних відмов — особливо з DNSSEC, великими TXT-записами або навантаженими резолверами.

10) Який безпечний «аварійний обхід» під час простою?

Використайте тимчасовий Netplan-override, щоб вказати відомі робочі внутрішні DNS-сервери для тієї зони, застосуйте і перевірте. Уникайте ручного редагування /etc/resolv.conf, якщо ви не готові документувати і прийняти, що воно може бути перезаписане.

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

Припиніть ставитися до Temporary failure in name resolution як до погодної події. На Ubuntu 24.04 DNS-помилки діагностуються, якщо ви поважаєте ланцюжок: застосунок → NSS → resolv.conf → systemd-resolved → upstream DNS → мережева політика.

Наступні кроки, які дадуть негайний ефект:

Опануйте швидкий playbook діагностики і навченіть його для вашої ротації on-call.
Стандартизуйте відповідальність за DNS (Netplan vs NetworkManager vs DHCP) по ролях хостів і задокументуйте це у репозиторії, що будує ваші образи.
Додайте один невеликий DNS-canary чек, що відрізняє: збій локального резолвера, збій upstream-сервера, і проблеми з UDP/TCP політиками.
Коли ви виправляєте — робіть це на правильному шарі, щоб зміна витримала оновлення оренди, перезавантаження і VPN-драму.