Ubuntu 24.04: sudo працює повільно — виправлення DNS/hostname, що усувають затримку (випадок №6)

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

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

Ви вводите sudo. Ви чекаєте. Курсор блимає, ніби обдумує зміну кар’єри.
І нарешті з’являється запит пароля — із затримкою в кілька секунд, що повторюється щоразу.

На Ubuntu 24.04 це досі поширена помилка «в мене на ноуті працювало», яка проявляється в найгірших місцях:
bastion-хости, CI-ранери, jump-бокси та щойно розгорнуті хмари VM з ледь помітними проблемами DNS, що можуть зіпсувати вам день.
Хороша новина: більшість затримок sudo зводяться до ідентифікації хоста та резолюції імен, і виправити їх можна нудними, детерміністичними кроками.

Що таке «повільний sudo» насправді (і чим це не є)

«Повільний sudo» зазвичай не пов’язаний з диском, не з процесором і не з наведеними духами PAM-модулів.
Зазвичай це блокуючий виклик розв’язання імен, що відбувається перед тим, як sudo виведе запит пароля.
Такий виклик може бути прямим DNS, зворотним DNS, mDNS, службами імен LDAP/SSSD або навіть резольвером, який неправильно налаштований і терпить таймаут.

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

Як це виглядає

Затримка відбувається перед появою запиту пароля (класично).
Затримка послідовна: ~1–5 секунд, часто точно відповідає шаблонам таймаутів/повторів DNS.
Затримка зникає, коли ви відключаєтесь від VPN / виходите з корпоративної мережі / змінюєте Wi‑Fi.
Затримка присутня як на консолі, так і по SSH, а не лише в одному термінальному емульяторі.

Чим це найчастіше не є

Не належить до конфігурації оболонки. Підказки оболонки з’являються до того, як ви введете sudo.
Не через повільний диск. sudo читає невеликі файли. Ваш NVMe тут не вузьке місце.
Не через нестачу оперативної пам’яті. Затримка — це реальний час, а не використання CPU.

Жарт №1: DNS — це «відділ, що вчора працював». Також це «відділ, що завтра знову працюватиме», що менш заспокоює.

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

Ви хочете найшвидший шлях до відповіді «на чому він блокується?», без зайвих відволікань.
Ось план, який я використовую на продуктивних хостах, де терпіння — розкіш.

Спочатку: виміряйте затримку і підтвердіть, що це розв’язання імен

Заміряйте sudo і відтворіть двічі, щоб підтвердити послідовність.
Запустіть strace на sudo і шукайте connect()/sendto() до DNS або виклики getaddrinfo().
Перевірте локальне розв’язання імен хоста через getent (forward і reverse), оскільки саме це використовує libc/NSS.

По‑друге: визначте, який шлях резолюції використовується

Перевірте /etc/nsswitch.conf на рядок hosts:. Це визначає порядок пошуку (files, dns, mdns4_minimal, resolve).
Перегляньте resolvectl status (systemd-resolved) або /etc/resolv.conf, щоб зрозуміти, куди йдуть запити.
Якщо це корпоративна система, перевірте інтеграцію SSSD/LDAP/AD, оскільки вона може впливати на пошук хостів/користувачів.

По‑третє: виправте найпростіше, що гарантує швидкий шлях

Переконайтеся, що ваше ім’я хоста відображено в /etc/hosts на loopback (наприклад, 127.0.1.1 або 127.0.0.1) із коротким іменем і FQDN, якщо потрібно.
Приберіть «приємні» опції резольверів, що збільшують таймаут (погані search-домени, некоректні nameserver).
Тільки потім, якщо є вагома причина, налаштовуйте sudo/PAM/логування.

Чому sudo торкається DNS/hostname взагалі

sudo — це не лише «запустити команду від root». Це механізм політик з трасою аудиту.
Він має вирішити, чи дозволено вам виконати цю команду тут.
«Тут» означає ідентичність хоста. «Ви» — це ім’я користувача й групи. «Аудит» — це логи, де часто з’являються імена хостів.

Звичні підозрювані, що викликають затримки через hostname/DNS

Розв’язання імен хоста для логування й політик.
Багато середовищ хочуть логи з іменами, а не сирими IP. Це може спричинити зворотний пошук.
Порядок NSS (Name Service Switch).
Якщо ваш рядок hosts: перевіряє mDNS, WINS, LDAP або демони резолюції раніше, ніж files,
ви платите за це при кожному виклику.
systemd-resolved або таймаути зовнішніх DNS.
Таймаути резольверів часто становлять кілька секунд — саме така затримка, яку ви бачите.
Невідповідність FQDN.
Машина з іменем web-01, чий DNS каже, що це web-01.corp.example, але /etc/hosts інше —
це може послати запити по повільніших шляхах.
SSSD / інтеграція з AD.
Якщо ви використовуєте доменних користувачів, SSSD може додавати затримки, коли намагається зв’язатися з контролерами — навіть для «локальних» дій.

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

Парафраз ідеї від Werner Vogels (CTO Amazon): Усе ламається весь час; проєктуйте, припускаючи, що компоненти будуть відмовляти.

Факти й історичний контекст, які можна використати в аргументах

Це не тривіальні факти для цікавості. Вони пояснюють, чому сучасна система розв’язання імен в Ubuntu може виглядати як механізм Рубе Голдберга,
якщо підходити до неї, ніби зараз 2009 рік.

NSS (Name Service Switch) походить із Solaris і був широко прийнятий у Linux для контролю порядку пошуку (files, DNS, LDAP тощо). Неправильний порядок досі спричиняє «таємничу повільність».
Ubuntu історично використовувала 127.0.1.1 у /etc/hosts для локального імені хоста, особливо на системах без стабільної IP. Це дивно, але це запобігає зверненням до резольверів.
systemd-resolved вніс локальний stub-resolver, що змінило поведінку /etc/resolv.conf на багатьох дистрибутивах. Шлях «хто відповідає за DNS?» став менш очевидним.
mDNS (multicast DNS) — чудовий для принтерів і ноутбуків; небажаний на серверах, якщо він стоїть перед files і ваша мережа дивно фільтрує multicast.
Зворотний DNS (PTR) часто відсутній або неправильний в внутрішніх мережах. Це нормально, поки щось не блокує на цьому, наприклад система логування/аудит.
VPN-клієнти часто пропихують search-домени і списки nameserver, які коректні для внутрішніх додатків, але гублять латентність, якщо шлях по мережі ненадійний.
Поведінка sudo еволюціонувала з очікуваннями безпеки: більше аудиту, більше контексту політик, більше місць, куди потрапляє ім’я хоста в логи.
Корпоративні DNS-патерни ери Windows (WINS, split DNS, довгі списки search) досі просочуються в конфіги Linux через DHCP і можуть дуже гальмувати пошуки імен.

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

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

Завдання 1: Виміряйте симптом так, ніби маєте на це намір

cr0x@server:~$ time sudo -n true

real    0m2.312s
user    0m0.008s
sys     0m0.010s

Що це означає: 2.3 секунди реального часу, майже нуль CPU. Це кричить «блок на I/O», а DNS — це I/O.
Рішення: Припиніть гадати про CPU/диск. Перейдіть до трасування служби імен.

Завдання 2: Підтвердіть, що це перед появою запиту пароля (інтерактивно)

cr0x@server:~$ time sudo true
[sudo] password for cr0x: 

real    0m2.205s
user    0m0.009s
sys     0m0.012s

Що це означає: Затримка відбувається до прийняття пароля (запит з’являється з запізненням).
Рішення: Дивіться на розв’язання імен і логування, а не на перевірку PAM-пароля.

Завдання 3: Використайте strace, щоб зловити блокувальник (швидко і грубо)

cr0x@server:~$ sudo strace -f -tt -o /tmp/sudo.trace sudo -n true
sudo: a password is required

cr0x@server:~$ tail -n 25 /tmp/sudo.trace
12:20:01.101234 connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.2")}, 16) = 0
12:20:01.101540 sendto(6, "\252\273\1\0\0\1\0\0\0\0\0\0\6server\4corp\7example\0\0\34\0\1", 36, 0, NULL, 0) = 36
12:20:03.103901 recvfrom(6, 0x7ffd8b2a3f10, 2048, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
12:20:03.104220 close(6) = 0

Що це означає: DNS-запит до 10.0.0.2 завершився таймаутом приблизно через ~2 секунди.
Рішення: Виправте досяжність/порядок резольверів або обійдіть DNS для локального імені через /etc/hosts.

Завдання 4: Подивіться, яке ім’я хоста бачить sudo

cr0x@server:~$ hostnamectl
 Static hostname: server
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 8cbe2c8a1b3d4f1e9e6c0c4b3c1c9d2a
         Boot ID: 2f9c9a1de2bf44a6a3a8c5f5f7e38e0a
  Virtualization: kvm
Operating System: Ubuntu 24.04 LTS
          Kernel: Linux 6.8.0-31-generic
    Architecture: x86-64

Що це означає: Статичне ім’я хоста — server (коротке ім’я).
Рішення: Переконайтеся, що server розв’язується швидко через /etc/hosts. Вирішіть, чи потрібен вам також FQDN.

Завдання 5: Перевірте прямий пошук через NSS (не “dig”, не “nslookup”)

cr0x@server:~$ getent hosts $(hostname)
10.22.1.17      server.corp.example server

Що це означає: NSS повертає адресу з DNS швидко (в цьому прикладі).
Якщо ця команда гальмує, sudo теж може гальмувати.
Рішення: Якщо повільно — пріоритет для виправлення /etc/hosts або налаштувань резольвера.

Завдання 6: Перевірте зворотний пошук для вашого основного IP

cr0x@server:~$ ip -br addr show scope global
ens3             UP             10.22.1.17/24

cr0x@server:~$ getent hosts 10.22.1.17
10.22.1.17      server

Що це означає: Зворотний пошук повертає server.
Якщо він таймаутиться, ваш стек логування або sudo можуть ініціювати PTR-запити.
Рішення: Якщо зворотний пошук повільний — або виправте PTR у DNS (краще), або забезпечте локальне відображення в /etc/hosts.

Завдання 7: Перевірте `/etc/hosts` на класичну відсутню відповідність

cr0x@server:~$ sed -n '1,120p' /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Що це означає: Відсутній запис для server. Це змушує NSS звертатися до мережевих джерел.
Рішення: Додайте відображення на loopback для вашого імені хоста, щоб локальна резолюція була миттєвою.

Завдання 8: Перегляньте порядок NSS для пошуку хостів

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

Що це означає: Спочатку files, потім mDNS, потім DNS.
На серверах mDNS може бути зайвим кроком.
Рішення: Якщо mDNS викликає затримки, подумайте про його видалення або переміщення після dns (обережно — див. виправлення).

Завдання 9: Перевірте, чи systemd-resolved керує резолюцією

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

Що це означає: Запити йдуть до 10.0.0.2/10.0.0.3. Режим stub означає, що /etc/resolv.conf вказує на локальний stub.
Рішення: Протестуйте ці DNS-сервери напряму. Якщо вони недоступні з цього хоста/мережі, виправляйте DHCP/VPN/налаштування резольвера.

Завдання 10: Переконайтесь, що DNS-сервери відповідають швидко (прямий запит)

cr0x@server:~$ dig +time=1 +tries=1 @10.0.0.2 $(hostname).corp.example A

; <<>> DiG 9.18.24-0ubuntu0.24.04.1-Ubuntu <<>> +time=1 +tries=1 @10.0.0.2 server.corp.example A
;; global options: +cmd
;; connection timed out; no servers could be reached

Що це означає: Налаштований DNS-сервер недосяжний (або фільтрується).
Рішення: Виправте список резольверів. Або, якщо не можете, обійдіть локальну резолюцію імен через /etc/hosts, щоб sudo не турбувався.

Завдання 11: Перевірте `/etc/resolv.conf` на наявність stub або прямих резольверів

cr0x@server:~$ readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf

Що це означає: Ви використовуєте локальний stub від systemd-resolved.
Рішення: Не «ліпіть» /etc/resolv.conf вручну, якщо ви навмисно не відключаєте systemd-resolved. Виправляйте upstream-конфігурацію.

Завдання 12: Дізнайтесь, чи SSSD в шляху пошуку (поширено в ентерпрайзі)

cr0x@server:~$ systemctl is-active sssd
active

cr0x@server:~$ getent passwd $USER
cr0x:x:1000:1000:cr0x:/home/cr0x:/bin/bash

Що це означає: SSSD активний. Він може впливати на пошуки залежно від конфігурації NSS.
Рішення: Якщо затримки sudo корелюють з недосяжністю AD/DC, перевірте логи SSSD і налаштування NSS; не звинувачуйте лише DNS.

Завдання 13: Виявлення проблем зі списком пошуку (повільний NXDOMAIN)

cr0x@server:~$ resolvectl domain
Global: corp.example lab.example dev.example

Що це означає: Багато search-доменів може спричиняти кілька запитів для одного імені, особливо для некваліфікованих імен.
Рішення: Віддавайте перевагу FQDN у конфігураціях, обрізайте списки пошуку де можливо і переконайтеся, що ваше ім’я хоста розв’язується без «перебігу» search-списку.

Завдання 14: Виміряйте латентність пошуку через NSS (повторювано)

cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname) >/dev/null
2.01 seconds

Що це означає: Пошук через NSS сам по собі займає ~2 секунди.
Рішення: Виправте розв’язання імен спочатку. sudo — лише посланець, якого стріляють.

Завдання 15: Доведіть, чи mDNS залучений

cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts server.local >/dev/null
1.99 seconds

Що це означає: Запити .local можуть спричиняти mDNS. Якщо це повільно і ваш hosts: включає mdns, ви маєте зачіпку.
Рішення: На серверах вимкніть mDNS або змініть порядок NSS, якщо немає реальної потреби.

Завдання 16: Підтвердіть, що налаштування логування sudo не вимагають дивного FQDN

cr0x@server:~$ sudo -V | sed -n '1,60p'
Sudo version 1.9.15p5
Sudoers policy plugin version 1.9.15p5
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.15p5
Sudoers audit plugin version 1.9.15p5
Local IP address and netmask pairs:
    10.22.1.17 / 255.255.255.0

Що це означає: Ви бачите перелік локальних IP. Іноді ця нумерація ініціює зворотні пошуки залежно від середовища.
Рішення: Зосередьтеся на виправленні резолюції імен/IP локально. Не копіюйте налаштування sudoers, поки не виміряєте проблему.

Шаблони виправлень, що реально усувають затримку

Є десяток способів «зробити так, щоб відчувалось краще», і два способи зробити це правильно.
Правильні способи: (1) зробити резолюцію імен хоста локальною й миттєвою, і (2) зробити зовнішній DNS надійним і доступним.
Робіть обидва, коли можна. Робіть (1), коли треба.

Виправлення №1: Додайте ім’я хоста в /etc/hosts (швидкий шлях, майже завжди безпечний)

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

Що робити (приклад для імені хоста server і FQDN server.corp.example):

cr0x@server:~$ sudoedit /etc/hosts

Приклад вмісту для додавання (зберігайте існуючі рядки):

cr0x@server:~$ sed -n '1,20p' /etc/hosts
127.0.0.1       localhost
127.0.1.1       server.corp.example server

::1             localhost ip6-localhost ip6-loopback

Що це означає: Ім’я хоста розв’язується миттєво через files. Немає залежності від DNS для локальної ідентичності.
Рішення: Якщо це усуває затримку, ви можете планувати чистку DNS пізніше, не витрачаючи весь день.

Мій суб’єктивний погляд: для сервера я хочу, щоб /etc/hosts містив локальне ім’я хоста.
Так, навіть якщо «DNS має бути джерелом істини». DNS — джерело істини, поки воно не стає джерелом викликів аварії.

Виправлення №2: Узгодьте очікування щодо hostname і FQDN

Проблеми виникають, коли різні шари не погоджуються, чи «реальне» ім’я коротке, чи повністю кваліфіковане.
Деякі середовища трактують server як «server.corp.example» через search-домени; інші — ні.
Ваше завдання — зробити це явним.

Вирішіть, яким має бути ім’я хоста:

Коротке ім’я (server): поширене для VM, внутрішніх хостів і коли не хочете перейменувань.
FQDN (server.corp.example): інколи потрібне для інструментів, сертифікатів або політик AD.

Встановіть його явно (якщо потрібно змінити):

cr0x@server:~$ sudo hostnamectl set-hostname server.corp.example

Рішення: Встановлюйте FQDN як статичне ім’я хоста тільки якщо ваша організація цього вимагає. Інакше тримайте коротке ім’я й відобразіть FQDN у /etc/hosts.
Перейменування хостів у продакшені — чудовий спосіб виявити все, що припускає, що імена ніколи не змінюються.

Виправлення №3: Відновіть досяжність резольверів (припиніть таймаути до мертвих DNS)

Якщо налаштовані DNS-сервери не відповідають, кожен запит стає лотереєю таймаутів.
З systemd-resolved ви часто успадковуєте резольвери від DHCP, VPN або конфігурації netplan.

Знайдіть активні DNS-сервери:

cr0x@server:~$ resolvectl dns
Global: 10.0.0.2 10.0.0.3
Link 2 (ens3): 10.0.0.2 10.0.0.3

Рішення: Якщо вони недосяжні з цього сегмента мережі, виправляйте мережеву конфігурацію (DHCP scope, профіль VPN, netplan).
Не «вирішуйте» це, додаючи випадкові публічні DNS на корпоративному хості, якщо не хочете проблем із split-DNS та відповідністю.

Виправлення №4: Обріжте search-домени (зменшіть множення запитів)

Search-домени можуть спричиняти кілька запитів для одного імені: server стає server.corp.example,
потім server.lab.example і т.д. Коли резольвери повільні, це примножує проблему.

Рішення: Віддавайте перевагу FQDN у конфігураціях і налаштуйте відображення імені хоста так, щоб воно не залежало від search-масиву.
Якщо ви керуєте DHCP, тримайте список пошуку коротким і обґрунтованим.

Виправлення №5: Змініть порядок пошуку NSS так, щоб «files» перемагав швидко

Рядок hosts: у /etc/nsswitch.conf визначає порядок пошуку.
Для серверів я хочу, щоб files був першим, DNS другим, а mDNS — тільки якщо є причина.

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

Якщо mDNS причетний, безпечнішим варіантом на сервері часто є:

cr0x@server:~$ sudo sed -i 's/^hosts:.*/hosts:          files dns/' /etc/nsswitch.conf

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

Виправлення №6: Правильно обробляйте зворотний DNS (PTR або локальне відображення)

Невірний зворотний DNS — поширена й терпима річ — поки політика безпеки або шлях логування не блокує на ньому.
Чисте виправлення — створити PTR-записи для IP серверів в авторитетному DNS.
Тактичне виправлення — забезпечити, щоб власний IP сервера зворотно резолвився локально через /etc/hosts.

Моя порада: якщо ви керуєте зоною DNS, робіть PTR. Це не опціональна гігієна — це операційний борг із відсотками.

Виправлення №7: Остерігайтеся «швидких латок», що ховають симптоми

Ви побачите поради на кшталт «відключити DNS-пошуки в sudo» або підправити логування.
Іноді ці зміни допомагають. Частіше вони просто погіршують аудиторію, лишаючи DNS зламаним для всього іншого.
Використовуйте їх лише коли маєте виміряну причину й запис змін.

Жарт №2: Вимкнути DNS, щоб виправити затримку DNS — це як прибрати спідометр, щоб покращити витрату палива. Вам стане трохи легше на душі ненадовго.

Три корпоративні історії (анонімізовані, правдоподібні, технічно точні)

1) Інцидент через хибне припущення: «Наш DNS завжди доступний»

Команда керувала флотом Ubuntu VM у двох мережевих зонах: аплікаційні сервери в одній, спільні сервіси (включно з DNS) в іншій.
Під час рев’ю безпеки правила фаєрволу були посилені. DNS був «дозволений», але лише з підмереж, перелічених у таблиці — яка була, як сказати м’яко, оптимістичною.

Першим симптомом не був збій додатка. Люди почали скаржитися в чаті, що sudo «інколи зависає».
Ротація на чергуванні списувала це на особисті ноутбуки і VPN-диверсії. Потім почалося оновлення пакетів, і автоматика, яка використовувала sudo, почала таймаутитися.
Отже, проблема вийшла за межі незручності й стала інцидентом.

Хибне припущення: «Якщо SSH працює, то DNS теж працює». SSH працював, бо IP-маршрути були в порядку і хости були зафіксовані в known_hosts.
DNS не працював, бо фаєрвол мовчки відкидав UDP/53, що перетворюється на «чекати таймаут, а потім повторити».

Виправлення фаєрволу було необхідним, але довготермінова міра — додавання локальних відображень імен у /etc/hosts через менеджер конфігурації.
Це зробило ідентифікацію локальною, тож навіть при хиткому DNS адміністративні дії не зупинялися.

Після інциденту вони додали перевірку здоров’я: вимір latency getent hosts $(hostname) і оповіщення.
Нудна метрика. Надзвичайно ефективна.

2) Оптимізація, що відігралася навпаки: «Додамо більше search-доменів»

Мережева команда вирішила покращити досвід розробників, скопіювавши щедрий список search-доменів через DHCP:
декілька внутрішніх доменів, щоб люди могли вводити короткі імена хостів, і вони «просто працювали».
Здавалося нешкідливим. І навіть працювало — поки DNS був швидким.

Потім в віддаленому офісі з’явилися переривчасті втрати пакетів до головних DNS-резольверів.
Кожен некваліфікований запит (наприклад, server) став низкою спроб: server.corp, server.lab, server.dev і т.д.
Помножте це на таймаути й повтори — і раптом тривіальні команди стали займати секунди.

Інженери помітили це першими в інструментах, що часто звертаються до NSS: sudo, ssh з GSSAPI, агенти моніторингу, що роблять зворотні пошуки для тегів.
Мережева «оптимізація» створила підсилювач латентності.

Відкат списку пошуку допоміг, але реальне лікування — дисципліноване іменування:
критичні системи використовували FQDN у конфігах, хости фіксували свої імена локально.
Короткі імена залишились для інтерактивної роботи, але продакшн-автоматика припинила залежати від магії search.

3) Нудна, але правильна практика, що врятувала ситуацію: стандартизовані записи /etc/hosts

Інша компанія мала строгий базовий стандарт: кожний Linux-хост мав запис у /etc/hosts для власного імені,
яким керував менеджер конфігурації і який переглядався як будь‑яка інша зміна.
Люди бурчали, бо це здавалося надлишковим при наявності DNS.

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

Причина: адміністративні робочі процеси не вимагали DNS для локальної ідентифікації.
sudo, локальне маркування логів і багато скриптів, що використовували hostname -f, не блокувалися, бо хост міг відповісти «хто я?» з локальних файлів миттєво.

Це не усунуло проблему DNS. Але це її стримало.
Ось в чому суть нудних стандартів: вони не загасають кожне полум’я, але не дозволяють вогню перекинутися в інші кімнати.

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

1) Симптом: sudo зупиняється ~2–5 секунд перед запитом пароля

Корінна причина: DNS-сервери в конфігурації резольвера недосяжні; libc чекає таймауту.

Виправлення: Виправте список DNS-серверів (DHCP/VPN/netplan) і додайте відображення імені хоста в /etc/hosts як захисний шар.

2) Симптом: sudo швидкий в одній мережі, повільний в іншій

Корінна причина: Split DNS/VPN змінює резольвери або search-домени; запити йдуть до резольвера, що повільний з цієї локації.

Виправлення: Виміряйте через resolvectl status і прямі dig @server. Виправте профіль VPN або маршрути DNS; уникайте довгих списків search.

3) Симптом: getent hosts $(hostname) зависає, але dig працює

Корінна причина: Порядок NSS використовує повільне джерело (mDNS, LDAP/SSSD) перед DNS; dig обходить NSS.

Виправлення: Відрегулюйте /etc/nsswitch.conf, щоб віддавати перевагу files, потім dns. Підтвердіть часом getent.

4) Симптом: hostname -f повільний; sudo повільний; логи показують FQDN-запити

Корінна причина: Невідповідність hostname/FQDN плюс «прогулянка» search-доменами; відсутній PTR викликає додаткові пошуки.

Виправлення: Забезпечте послідовну стратегію імен хостів і відповідний запис у /etc/hosts; додайте PTR, якщо ви керуєте DNS.

5) Симптом: sudo повільний лише коли контролери домену недоступні

Корінна причина: Затримки SSSD/AD впливають на шляхи NSS/PAM.

Виправлення: Підтвердіть через systemctl is-active sssd і виміряні getent. Налаштуйте SSSD failover/таймаути і зберігайте локальну резолюцію імен у files.

6) Симптом: затримка sudo з’являється після увімкнення Avahi або «desktop features» на сервері

Корінна причина: mDNS підключається і таймаутиться або фільтрується, додаючи затримку.

Виправлення: Видаліть/вимкніть mDNS на серверах або змініть порядок NSS, щоб уникнути mDNS для не‑.local запитів.

7) Симптом: sudo повільний тільки в мережах з IPv6

Корінна причина: IPv6 DNS-сервери або маршрути неправильно налаштовані; резольвер спочатку пробує AAAA потім A з затримками.

Виправлення: Перевірте resolvectl status на наявність v6 резольверів і тестуйте з dig -6. Виправте маршрути або відключіть некоректні v6 резольвери; тримайте локальне відображення імені хоста.

8) Симптом: «sudo: unable to resolve host …» плюс повільність

Корінна причина: Ім’я хоста взагалі не розв’язується через NSS; sudo виводить помилку і чекає на повільний fallback.

Виправлення: Додайте правильний запис у /etc/hosts для імені хоста; перевірте через getent hosts $(hostname).

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

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

Виміряйте затримку:
```
cr0x@server:~$ time sudo -n true
sudo: a password is required

real    0m2.101s
user    0m0.008s
sys     0m0.010s
```
Рішення: Якщо реальний час — секунди при мінімальному CPU, переходьте до перевірок служби імен.
Заміряйте NSS-пошук імен хоста:
```
cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname)
2.00 seconds
10.22.1.17      server.corp.example server
```
Рішення: Якщо це повільно, виправлення резолюції імен, ймовірно, вирішить sudo.
Додайте відображення імені хоста, якщо відсутнє:
```
cr0x@server:~$ sudo grep -nE '127\.0\.1\.1|127\.0\.0\.1' /etc/hosts
1:127.0.0.1       localhost
```
```
cr0x@server:~$ sudoedit /etc/hosts
```
Рішення: Додайте 127.0.1.1 server.corp.example server (або ваші реальні імена). Збережіть.
Повторно протестуйте:
```
cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname)
0.00 seconds
127.0.1.1       server.corp.example server
```
```
cr0x@server:~$ time sudo -n true

real    0m0.050s
user    0m0.008s
sys     0m0.012s
```
Рішення: Якщо виправлено — зупиніться. Тепер ви можете вирішувати проблему з DNS upstream без видимого болю для користувачів.

Контрольний список B: Флотне виправлення (те, що бажано було зробити раніше)

Стандартизуйте ідентичність хостів: вирішіть політику короткого імені vs FQDN.
Нав’яжіть стандарт /etc/hosts: локальне відображення для імені хоста і (якщо використовується) FQDN.
Явно налаштуйте порядок NSS: hosts: files dns для серверів, якщо немає задокументованої потреби інакше.
Моніторте латентність пошуків: оповіщення при getent hosts $(hostname) більше ніж 200ms стійко.
Виправте PTR-записи для підмереж серверів, якщо ви володієте DNS. Уникайте міфу «зворотний DNS можна ігнорувати».
Тестуйте зміни VPN/DHCP на канарковому хості, заміряючи latency NSS та sudo.

Контрольний список C: Якщо потрібно змінювати конфігурацію DNS

Підтвердіть, хто володіє резольверами (мережева команда, платформа, провайдер хмари).
Перевірте досяжність (UDP і TCP порт 53) з ураженого підмережі.
Тримайте список резольверів коротким (2–3 сервера) і локальним для регіону мережі.
Уникайте довгих списків пошуку; ставтеся до них як до множників при збої.
Розгорнення поступове і виміряне; оцінюйте latency NSS, а не лише «dig працює».

Питання й відповіді

Чому sudo взагалі звертається до DNS?

Тому що це інструмент політик/аудиту, а не примітивний перемикач привілеїв. Він може розв’язувати імена хостів для логування, контексту політик або перевірок ідентичності через NSS.
Якщо NSS потрапляє на DNS, а DNS повільний, sudo успадковує цю затримку.

Чому `dig` швидкий, а `sudo` повільний?

dig спілкується з DNS напряму. sudo використовує libc для розв’язання імен через NSS, який може звертатися до files, mDNS, SSSD/LDAP і DNS — у цьому порядку.
Потрібно вимірювати через getent, а не лише dig.

Чи додавання імені хоста в `/etc/hosts` — це «погана практика»?

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

Користуватися `127.0.1.1` чи `127.0.0.1`?

В Ubuntu 127.0.1.1 — звична конвенція для відображення імені хоста без захоплення localhost.
Обидва варіанти можуть працювати, але тримайте localhost коректним і уникайте випадкового відображення кількох несумісних імен на 127.0.0.1.

Але якщо «реальний» IP сервера має бути в DNS, а не loopback?

Помістіть реальний IP у DNS (A/AAAA) та PTR у зворотну зону. Все одно зберігайте локальне відображення для імені хоста, якщо ваше середовище це допускає,
або відобразіть ім’я хоста на основний IP у /etc/hosts, якщо потрібно відобразити реальність. Мета — швидка, послідовна резолюція.

Чи systemd-resolved спричиняє це?

systemd-resolved часто просто кур’єр. Він може виявити погані upstream списки, DNS, що штовхає VPN, або недосяжні nameserver’и.
Використовуйте resolvectl status, щоб побачити, що реально відбувається, перш ніж його звинувачувати.

Чи IPv6 може бути причиною затримки?

Так. Якщо конфігурація резольверів включає зламані IPv6-шляхи або недоступні IPv6 DNS-сервери, запити можуть ставати в чергу перед відкатом.
Міряйте через resolvectl і тестуйте IPv6; не відключайте IPv6 бездумно, якщо ви не контролюєте середовище та не приймаєте наслідків.

Чи безпечно редагувати `/etc/nsswitch.conf`, щоб прибрати mDNS?

На серверах зазвичай так, якщо ви не залежите від .local-виявлення. На десктопах видалення mDNS може зламати виявлення пристроїв.
Робіть зміну свідомо і перевіряйте через вимірювання getent hosts.

Який найшвидший «доказ», що DNS — вузьке місце?

Заміряйте getent hosts $(hostname) і запустіть strace на sudo, щоб знайти таймаути DNS-сокетів.
Якщо NSS розв’язання займає секунди, проблема не в sudo — у службі імен.

Чому воно погіршується на VPN?

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

Наступні кроки

Якщо sudo повільний на Ubuntu 24.04, ставтеся до цього як до проблеми залежності, а не як до проблеми sudo.
Виміряйте через time, доведіть через strace, перевірте через getent.
Потім зробіть швидкий шлях локальним: відобразіть ім’я хоста в /etc/hosts і переконайтеся, що files першим у пошуку хостів.

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