Ubuntu 24.04: sudo повільний — виправлення DNS/hostname, що усувають затримку (справа #66)

Що зазвичай означає «повільний sudo» (і чим це не є)

Коли sudo повільний, це рідко означає «sudo важкий». Зазвичай sudo звертається до стеку служб імен — модулів NSS у glibc — і чекає на шлях резолвера, про який ви навіть не підозрювали, що він важливий.

Класичний сценарій на Ubuntu 24.04:

• Затримка відбувається до запиту пароля: пошук/ініціалізація (hostname, NSS, PAM, DNS, SSSD, LDAP, Kerberos тощо).
• Затримка відбувається після введення пароля: автентифікація каталогів, модулі PAM, мережеві домашні директорії, пошуки груп або цілі для логування.
• Затримка ≈ 5 секунд: виглядає підозріло як тайм-аут DNS або шлях запасного варіанту, що чекає на сплив.
• Затримка 10/15/20 секунд: кілька резолверів опитуються послідовно, або відбуваються тайм-аути для A та AAAA, або повторні спроби.

Також: не витрачайте час на звинувачення CPU, диска або «snap». Якщо система в цілому відгукується, а затримки лише при піднятті привілеїв — ви перебуваєте в царині розв’язування імен та пошуку ідентичності.

Одна операційна істина: sudo — це тест на надійність. Якщо розв’язування імен ненадійне, sudo охоче про це повідомить, ставши надокучливим.

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

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

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

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

1. Заміруйте sudo і порівняйте з sudo -n true.
2. Протестуйте sudo у «чистому» середовищі.
3. Слідкуйте за викликами розв’язування імен через strace (швидко і однозначно).

По-друге: перевірте здоров’я hostname та локального розв’язування

1. Перевірте, що /etc/hostname збігається з тим, що показує hostnamectl.
2. Переконайтеся, що /etc/hosts відображає 127.0.1.1 (або 127.0.0.1) на ваш hostname/FQDN послідовно.
3. Підтвердьте, що getent hosts $(hostname) повертає миттєво.

По-третє: перевірте шлях резолвера та доступність DNS-серверів

1. Перегляньте resolvectl status, /etc/resolv.conf (symlink) та search-домени.
2. Запитайте свій hostname вперед та назад за допомогою resolvectl query і dig.
3. Шукайте тайм-аути в journalctl -u systemd-resolved.

Зупиніться, коли знайдете явний доказ

Ваша мета — не «покращити DNS». Ви видаляєте детермінований тайм-аут на гарячому шляху. Виправляйте те, що повільне; решту залиште як є.

Цікаві факти й контекст (те, що люди забувають)

• Факт 1: sudo часто розв’язує локальний hostname для журналювання «де виконувалась команда», а в деяких конфігураціях також перевіряє invoking user та групи через NSS.
• Факт 2: На Debian/Ubuntu конвенція з 127.0.1.1 у /etc/hosts — давня практика для мапінгу локального hostname на системах без фіксованої зовнішньої адреси (ноутбуки, DHCP).
• Факт 3: NSS у glibc модульний і залежить від порядку. Один повільний модуль (DNS, mdns, sss) у ланцюжку може зупинити все, що викликає getaddrinfo().
• Факт 4: systemd-resolved ввів розділений DNS та маршрутизацію запитів по лінках; це корисно для VPN, але також виявляє неправильно налаштовані search-домени.
• Факт 5: Зворотні DNS-запити (PTR) часто відсутні в корпоративних мережах — особливо для випадкових діапазонів робочих станцій — але багато систем все ще намагаються їх виконати для логування або політики.
• Факт 6: AAAA (IPv6) запит може вносити затримки у мережах лише з IPv4, якщо резолвер намагається v6 першим і чекає тайм-аутів замість швидкого NXDOMAIN.
• Факт 7: mDNS (.local через Avahi) і DNS можуть погано взаємодіяти, якщо ваші вибори hostname або search-доменів недоглянуті; «local» — це спеціальна зона в багатьох середовищах.
• Факт 8: Список search-доменів, що занадто довгий, може множити запити: один lookup короткого імені розширюється в кілька FQDN спроб.
• Факт 9: «П’ятисекундна пауза» часто не випадкова: це стандартний тайм-аут резолвера, який ви можете буквально порахувати.

Одна ідея, яку варто виписати в блокнот кожному операціоннику: paraphrased idea від Gene Kim: надійність досягається зменшенням передач і прихованих залежностей — особливо тих, що тайм-аутяться.

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

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

Що вам потрібно дізнатися:

• Точна тривалість затримки.
• Чи відбувається вона до пароля або після.
• Чи збігається вона з тайм-аутами DNS (5с, 10с і т.і.).
• Яка системна виклик блокує (зазвичай connect() до DNS-сервера або читання, що чекає відповіді).

Кореневі причини: DNS, hostname, NSS та супутні

1) Hostname не розв’язується локально

Машина знає свій hostname, але не може швидко розв’язати його в адресу. Тоді програми, які роблять «яке моє ім’я?» і потім «яка моя адреса?», потрапляють у DNS, який падає на тайм-аутах.

Звичайне виправлення в Ubuntu: переконайтеся, що /etc/hosts містить запис для hostname (та опціонально FQDN) на loopback. Суть у швидкості й детермінізмі, не в елегантності.

2) DNS-сервер недоступний (або невірний per-link DNS)

Ваш резолвер вказує на DNS-сервери, які недоступні з цієї машини (старий VPN DNS, старий офісний DNS, мертва лабораторна мережа). Кожен lookup чекає тайм-аутів перед fallback.

3) Надмірні search-домени

Search-домени корисні — поки вони не стають генератором запитів. Один короткий lookup типу myhost може стати:

• myhost.corp.example
• myhost.dev.example
• myhost.example
• …і потім, можливо, оголене ім’я

Якщо кожен крок тайм-аутиться, ви створили генератор затримок. Виправлення — зменшити список search-доменів або використовувати FQDN там, де це важливо.

4) Порядок NSS тягне повільні мережеві провайдери ідентичності

Якщо в /etc/nsswitch.conf зазначено «консультувати SSSD/LDAP/DNS для всього», навіть локальні пошуки користувачів/груп можуть зависати. sudo часто перевіряє членство в групах і ідентичність користувача. Це нормально. Але робити це через зламаний мережевий шлях — ні.

5) Зворотні DNS та припущення логування

Деякі середовища використовують зворотний DNS для аудиту. Інші випадково викликають зворотні запити через те, як розв’язуються або журналюються хостнейми. Відсутні PTR — не фатальні, але тайм-аути — так.

6) Невідповідність IPv6 і тайм-аути AAAA

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

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

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

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

Завдання 1: Замірте проблему

cr0x@server:~$ time sudo -v

real    0m5.214s
user    0m0.012s
sys     0m0.020s

Що це значить: приблизно 5.2с стінного часу з мізерним використанням CPU вказує на очікування вводу/виводу (часто DNS).

Рішення: Розглядайте як латентність зовнішньої залежності, а не навантаження системи. Переходьте до перевірки hostname/DNS.

Завдання 2: Відокремте автентифікацію від lookup через неінтерактивний sudo

cr0x@server:~$ time sudo -n true

real    0m5.108s
user    0m0.004s
sys     0m0.006s

Що це значить: все ще повільно без запиту пароля. Це не «затримка через набір людини» або обробку PAM-пароля.

Рішення: Зосередьтеся на ініціалізації перед автентифікацією: розв’язування hostname, NSS, резолвер, sudoers lookup.

Завдання 3: Перевірте, чи пов’язано це із розв’язуванням hostname

cr0x@server:~$ hostname
app-node-7

cr0x@server:~$ time getent hosts $(hostname)
10.10.40.77     app-node-7.corp.example app-node-7

real    0m5.014s
user    0m0.003s
sys     0m0.006s

Що це значить: getent теж повільний. Це не лише sudo; це служба імен.

Рішення: Виправляйте шлях NSS/DNS. sudo покращиться автоматично.

Завдання 4: Перевірте локальний мапінг hostname у /etc/hosts

cr0x@server:~$ grep -nE '^(127\.0\.0\.1|127\.0\.1\.1)' /etc/hosts
1:127.0.0.1 localhost
2:127.0.1.1 ubuntu

Що це значить: hostname — app-node-7, але 127.0.1.1 мапиться на ubuntu. Така невідповідність часто спричиняє DNS-запити за фактичним hostname.

Рішення: Оновіть /etc/hosts, щоб 127.0.1.1 вказував на ваш реальний hostname (і опціонально FQDN).

Завдання 5: Підтвердьте, що система знає свій hostname

cr0x@server:~$ hostnamectl status
 Static hostname: app-node-7
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 7c9d6e4f9c3d4c3a9d3b9d5d8c0c0e1a
         Boot ID: 2a4f4d8a0d824d1c9c4f2a1a7a3d8a9b
  Operating System: Ubuntu 24.04.1 LTS
            Kernel: Linux 6.8.0-41-generic
      Architecture: x86-64

Що це значить: Static hostname встановлено правильно. Невідповідність, ймовірно, у локальному розв’язуванні або DNS.

Рішення: Не змінюйте hostname лише щоб виправити розв’язування; виправте мапінг.

Завдання 6: Перегляньте порядок NSS (тут ховаються затримки)

cr0x@server:~$ grep -nE '^(hosts|passwd|group):' /etc/nsswitch.conf
8:passwd:         files systemd sss
9:group:          files systemd sss
12:hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

Що це значить: lookup hosts пробує files, потім mDNS minimal, потім DNS, потім myhostname. Такий порядок може спричиняти мережеві запити перед локальним shortcut.

Рішення: Розгляньте переміщення myhostname раніше або переконайтеся, що /etc/hosts правильний, щоб files розв’язував миттєво.

Завдання 7: Підтвердьте, що systemd-resolved працює і які DNS він використовує

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

Link 2 (ens18)
    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

Що це значить: Система використовує stub-режим резолвера і вказує на корпоративні DNS-сервери.

Рішення: Якщо ці сервери недоступні з цього хоста/сегменту, виправте netplan/VPN DNS-налаштування або встановіть правильні per-link DNS.

Завдання 8: Перевірте симлінк /etc/resolv.conf та його вміст

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Oct 10 09:12 /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 127.0.0.53, а systemd-resolved пересилає їх на налаштовані upstream DNS.

Рішення: Налагоджуйте доступність upstream і тайм-аути через логи resolved і прямі запити.

Завдання 9: Запитайте hostname через resolved і подивіться час відповіді

cr0x@server:~$ time resolvectl query $(hostname)
app-node-7: 10.10.40.77                          -- link: ens18

-- Information acquired via protocol DNS in 5.0062s.
-- Data is authenticated: no

Що це значить: Резолвер відповів приблизно за ~5 секунд. Це та сама затримка, що ви бачите в sudo.

Рішення: Підтвердіть, чому upstream DNS повільний: недоступний сервер, фаєрвол, неправильний маршрут, зламані search-домени або тайм-аути зворотних запитів.

Завдання 10: Шукайте тайм-аути resolved у journald

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "10 min ago" | tail -n 30
Oct 10 09:55:11 server systemd-resolved[812]: Sending query via TCP since UDP failed.
Oct 10 09:55:16 server systemd-resolved[812]: DNS server 10.10.0.53 unreachable, trying next.
Oct 10 09:55:21 server systemd-resolved[812]: DNS server 10.10.0.54 unreachable, trying next.
Oct 10 09:55:21 server systemd-resolved[812]: Using degraded feature set UDP instead of TCP for DNS server 10.10.0.53.

Що це значить: Upstream DNS-сервери недоступні. Resolved перемикається між серверами і режимами транспорту, витрачаючи час.

Рішення: Виправте маршрутизацію/фаєрвол/VPN або змініть DNS для цього лінку на доступні. Не починайте з «тонкої» перенастройки тайм-аутів.

Завдання 11: Доведіть доступність DNS-серверів по мережі

cr0x@server:~$ ping -c 2 10.10.0.53
PING 10.10.0.53 (10.10.0.53) 56(84) bytes of data.

--- 10.10.0.53 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1014ms

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

Що це значить: Немає ICMP-відповіді і TCP/53 тайм-аутиться. Навіть якщо ICMP блокується, тайм-аут TCP/53 — сильний сигнал.

Рішення: Підтвердіть правильні IP DNS для цього підмережі/VPC; виправте security group/фаєрвол або вкажіть альтернативні досяжні резолвери.

Завдання 12: Слідкуйте за sudo через strace (швидка, жорстка правда)

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

cr0x@server:~$ tail -n 25 /tmp/sudo.trace
12:01:10.102345 connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
12:01:10.102612 sendto(7, "\244\243\1\0\0\1\0\0\0\0\0\0\10app-node-7\4corp\7example\0\0\1\0\1", 40, MSG_NOSIGNAL, NULL, 0) = 40
12:01:15.110991 recvfrom(7, 0x7ffd3b0d9a40, 2048, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
12:01:15.111244 close(7) = 0

Що це значить: Затримка — це DNS-запит через локальний stub. Ви бачите приблизно ~5 секундну паузу перед тим, як recvfrom повертає помилку.

Рішення: Перестаньте дебатувати. Виправляйте доступність DNS або локальний мапінг hostname, щоб sudo не потребував DNS для власних операцій.

Завдання 13: Явно перевірте forward і reverse DNS

cr0x@server:~$ dig +time=2 +tries=1 app-node-7.corp.example A

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +time=2 +tries=1 app-node-7.corp.example A
;; connection timed out; no servers could be reached

cr0x@server:~$ dig +time=2 +tries=1 -x 10.10.40.77 PTR

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +time=2 +tries=1 -x 10.10.40.77 PTR
;; connection timed out; no servers could be reached

Що це значить: DNS недоступний взагалі. Зворотний DNS також мертвий, але це симптом тієї ж проблеми доступності.

Рішення: Виправляйте вибір upstream DNS і мережевий шлях; не замазуйте options timeout: випадково, якщо тільки ви не в режимі надзвичайної помилки.

Завдання 14: Перевірте netplan DNS-конфігурацію (поширено після оновлень/шаблонів)

cr0x@server:~$ sudo netplan get
network:
  ethernets:
    ens18:
      addresses:
      - 10.10.40.77/24
      gateway4: 10.10.40.1
      nameservers:
        addresses:
        - 10.10.0.53
        - 10.10.0.54
        search:
        - corp.example
  version: 2

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

Рішення: Змініть nameservers на правильні для цього середовища (або приберіть перевизначення, якщо DHCP має їх надавати).

Завдання 15: Швидкий containment-тест: додайте hostname у /etc/hosts

cr0x@server:~$ sudoedit /etc/hosts

cr0x@server:~$ grep -n '127.0.1.1' /etc/hosts
2:127.0.1.1 app-node-7.corp.example app-node-7

cr0x@server:~$ time sudo -n true

real    0m0.085s
user    0m0.004s
sys     0m0.008s

Що це значить: Затримка зникла. Ви обійшли DNS для локального шляху розв’язування hostname.

Рішення: Залиште це виправлення навіть після ремонту DNS. Локальний мапінг — недорога страховка проти майбутніх DNS-пригод.

Завдання 16: Якщо задіяний SSSD/LDAP — перевірте затримки lookup ідентичності

cr0x@server:~$ time id $USER
uid=1001(cr0x) gid=1001(cr0x) groups=1001(cr0x),27(sudo),1002(devops)

real    0m4.932s
user    0m0.000s
sys     0m0.008s

Що це значить: Навіть id повільний. Це NSS (можливо SSSD), що чекає на мережевого провайдера.

Рішення: Перевірте статус SSSD і доступність upstream каталогу; розгляньте локальні акаунти з пріоритетом files і переконайтеся, що провайдери каталогів здорові.

Виправлення, що працюють (і чому)

Виправлення 1: Забезпечте локальне розв’язування hostname (буденно, але правильно)

Додайте свій hostname у /etc/hosts. Так, навіть якщо у вас є DNS. Так, навіть якщо ви «cloud native». Це про усунення мережевої залежності з локального шляху підняття привілеїв.

Рекомендований патерн на Ubuntu:

• 127.0.0.1 localhost
• 127.0.1.1 yourhost.yourdomain yourhost

Чому це працює: NSS зазвичай перевіряє files першим. Це вирішується миттєво й ніколи не торкається DNS.

Виправлення 2: Вкажіть правильні DNS-сервери для мережі, в якій ви

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

• Netplan статична конфігурація: вкажіть досяжні nameservers.
• DHCP: переконайтеся, що опція DHCP віддає правильні DNS для цього підмережі.
• VPN split DNS: забезпечте per-link DNS тільки коли VPN активна.

Виправлення 3: Зменшіть search-домени (і припиніть використовувати короткі імена в скриптах)

Довгий список search — самонаведений множник запитів. Якщо ви отримали список з п’яти суфіксів — скоротіть його. Якщо не можете — перестаньте використовувати короткі імена в автоматизації. Використовуйте FQDN у скриптах і конфігах.

Виправлення 4: Приберіть хаос у /etc/nsswitch.conf (обережно)

Будьте обережні: зміни NSS можуть мати широкі наслідки. Але в середовищах з передбачуваними локальними потребами можна переставити hosts:, щоб уникнути повільних модулів.

Типові безпечні цілі:

• Переконайтеся, що files перше.
• Переконайтеся, що myhostname не останнє, якщо ви на нього покладаєтесь.
• Уникайте mDNS, якщо ви ним не користуєтесь.

Якщо ваш флот потребує mDNS для ноутбуків розробників — ок. На серверах зазвичай ні.

Виправлення 5: Якщо потрібен зворотний DNS — зробіть PTR записи справжніми

Якщо інструменти безпеки/аудиту очікують PTR, то відсутність PTR — це дефект, а не «шаманство». Додайте PTR для IP серверів. Зробіть forward і reverse відповідними. Ваші майбутні інцидентні звіти будуть коротші й менш емоційні.

Виправлення 6: Працюйте з IPv6 чесно (не підтримуйте наполовину)

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

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

Міні-історія №1: Інцидент, спричинений хибним припущенням

Вони щойно перемістили набір внутрішніх build-runner’ів в інший мережевий сегмент. Команда вважала, що «DNS універсальний», бо новий сегмент мав доступ в інтернет і міг розв’язувати публічні домени.

Все здавалося нормальним, поки не настав перший день патчу. Інженери заходили по SSH, запускали sudo apt-get і чекали. Пауза була стабільною — близько п’яти секунд — на кожній привілейованій команді. Люди почали звинувачувати нове ядро, EDR-агент, і хтось навіть припустив, що «Ubuntu 24.04 просто важчий».

Реальна проблема була проста і тихо принизлива: шаблон netplan хардкодив DNS-сервери, що були доступні лише в старому сегменті. Публічний DNS працював через локальний форвардер, але внутрішні зони — ні. І hostname’и були внутрішніми.

Як тільки хтось заміряв getent hosts $(hostname) і побачив ту саму паузу, таємниця зникла. Вони замінили список DNS на правильні per-segment резолвери і додали hostname у /etc/hosts як страховку.

Дві настанови: «публічний DNS працює» ≠ «DNS працює», і «впливає лише на sudo» часто означає «впливає на розв’язування імен на гарячому шляху».

Міні-історія №2: Оптимізація, що відкотилася

Платформна команда хотіла «чистішої» ідентичності хостів. Вони видалили записи 127.0.1.1 з /etc/hosts через CM, наполягаючи, що DNS має бути джерелом істини. Технічно вони були праві локально і оперативно неправі глобально.

Деякий час нічого не відбувалося. Потім тимчасове технічне обслуговування DNS потрапило в один регіон. Не повний збій — просто вища латентність і поодинокі тайм-аути. Раптом кожна привілейована дія на сотнях інстансів стала липкою. Затримки sudo спричинили повільніші деплоя, повільніший відгук інцидентних команд і загальне відчуття, що регіон проклятий.

«Оптимізація» також створила пастку для дебагу. Оскільки DNS зрідка відновлювався, проблема виглядала інтермітуючою. Насправді це була детермінована поведінка резолвера під час транзитної латентності upstream.

Вони відкотили зміни: hostname у /etc/hosts, DNS залишився авторитетним для сервіс-дискавері, і суворий моніторинг латентності DNS. Ніхто не назвав це «відкатом», бо це було про усунення залежності з шляху підняття привілеїв.

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

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

Фінансово суміжне середовище мало суворий контроль змін, тому їхні базові образи були консервативні. Кожен сервер мав послідовний запис у /etc/hosts для свого hostname і FQDN на 127.0.1.1. Без винятків, навіть у епhemeral autoscaling групах.

Під час інциденту з upstream DNS багато команд побачили каскадні відмови: повільні логіни, повільний sudo і тайм-аути для всього, що робило пошук ідентичності або hostname. А фінансова середа? Більш-менш у нормі. Їхні додатки залежали від DNS для зовнішніх сервісів, але адміністратори могли миттєво отримати root і виконати локальні ремедіації без боротьби з тайм-аутами резолвера.

Що їх врятувало — не героїзм, а нудна гігієна конфігурацій: детерміноване локальне розв’язування, мінімальні search-домени і конфіг резолвера без хитрих fallback-ів.

Після інциденту вони не вихвалялися. Просто показали свої базові стандарти і сказали: «Ми прибираємо мережеві залежності з локальних операцій». Ніхто не сперечався з результатом.

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

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

Причина: lookup hostname врізається в DNS і чекає тайм-аутів (недоступний резолвер або відсутній локальний мапінг).

Виправлення: додайте правильний мапінг hostname у /etc/hosts; переконайтеся, що DNS-сервери доступні через resolvectl status і мережеві правила.

2) Симптом: sudo повільний лише в VPN або лише поза VPN

Причина: split DNS неправильно налаштований; per-link DNS вказує на VPN-резолвер навіть коли тунель опущений (або навпаки).

Виправлення: виправте інтеграцію DNS у VPN-клієнті; переконайтеся, що systemd-resolved оновлює link-specific DNS; уникайте хардкоду DNS у netplan, якщо DHCP/VPN має керувати ними.

3) Симптом: повільний SSH-login і повільний sudo

Причина: зворотні DNS-запити або тайм-аути NSS-провайдера ідентичності (SSSD/LDAP) впливають на обидва процеси.

Виправлення: перевірте PTR-записи і доступність провайдера каталогів; переконайтеся, що files перший у nsswitch.conf і що кеші здорові.

4) Симптом: getent hosts повільний для всього, включно з публічними доменами

Причина: upstream DNS-сервери недоступні; resolved робить повторні спроби і fallback.

Виправлення: вкажіть досяжні DNS; виправте фаєрвол/маршрути; перевірте через dig і journalctl -u systemd-resolved.

5) Симптом: sudo іноді швидкий, іноді повільний, корелює з jitter мережі

Причина: підхід «DNS авторитетний лише»; локальний hostname відсутній у /etc/hosts, тому sudo залежить від латентності upstream.

Виправлення: відновіть локальний мапінг hostname; сприймайте це як особливість надійності, а не як хак.

6) Симптом: sudo повільний лише при використанні короткого hostname

Причина: search-домени змушують робити кілька спроб; один суфікс тайм-аутиться.

Виправлення: скоротіть search-домени; використовуйте FQDN в автоматизації; якщо коротке ім’я має залишитися — забезпечте його локальне розв’язування.

7) Симптом: після оновлення до 24.04 з’явилися затримки, а в 22.04 їх не було

Причина: зміни в поведінці resolved за замовчуванням, інтеграції мережевого стека або інший вибір DNS-серверів (особливо при split DNS/VPN).

Виправлення: перевірте фактичний ефективний DNS через resolvectl status; не припускайте, що старий ланцюжок резолверів пережив оновлення без змін.

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

Покроково: виправити повільний sudo з мінімальним ризиком

1. Вимір: заміряйте sudo -n true і getent hosts $(hostname). Якщо обидва повільні — це служба імен.
2. Локальна страховка: упевніться, що /etc/hosts мапить 127.0.1.1 на hostname (і FQDN, якщо використовується).
3. Підтвердження покращення: повторіть замір sudo -n true. Якщо тепер швидко — ви видалили основне вузьке місце.
4. Виправлення upstream DNS: перевірте resolvectl status; переконайтеся, що DNS-сервери доступні; скоригуйте netplan/DHCP/VPN.
5. Зменште мультиплікацію запитів: звужуйте search-домени; уникайте коротких імен в автоматизації.
6. NSS-саніті: перевірте порядок у /etc/nsswitch.conf для hosts; уникайте повільних модулів, якщо вони не потрібні.
7. Регресійний захист: додайте моніторинг доступності/латентності DNS і простий smoke-тест «sudo швидкий» у pipeline провіжингу.

Контрольний список для зміни конфігурацій (флот)

• Базовий /etc/hosts містить мапінг hostname на loopback.
• Шаблони netplan не хардкодять DNS, які відсутні в деяких оточеннях.
• Search-домени короткі й навмисні.
• NSS-конфіг послідовний по хостах з локальною розв’язкою першочергово.
• Провайдери каталогів (SSSD/LDAP) моніторяться, тайм-аути зрозумілі.
• IPv6 або підтримується наскрізь, або відключений послідовно (жодного «примарного IPv6»).

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

1) Чому sudo взагалі зважає на DNS?

Бо він запитує систему, хто ви (lookup користувача/групи) і часто розв’язує локальний hostname для логування, політик або перевірок середовища. Ці виклики йдуть через NSS, який може звертатись до DNS.

2) Я додав hostname у /etc/hosts і sudo тепер швидкий. Це халтура?

Ні. Це патерн надійності: локальні операції не повинні залежати від мережевих сервісів. Залишайте DNS для service discovery; залишайте локальні мапінги для ідентичності машини.

3) Чому затримка часто точно п’ять секунд?

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

4) У чому різниця між /etc/hosts і DNS для розв’язування hostname?

/etc/hosts локальний, миттєвий і детермініований. DNS — мережевий і може відмовляти або зависати. NSS вирішує, які джерела використовувати і в якому порядку.

5) Чи варто відключати systemd-resolved, щоб це виправити?

Зазвичай — ні. systemd-resolved рідко є кореневою причиною; він лише показує, що ваша DNS-конфігурація невірна або недоступна. Спочатку виправляйте upstream DNS.

6) Чи можуть самі search-домени спричиняти повільний sudo?

Так. Коротке ім’я може розширитися в кілька DNS-запитів. Якщо будь-який із шляхів тайм-аутиться — ви отримуєте затримку, яка виглядає як «sudo повільний», але насправді це «DNS вагається».

7) Як зрозуміти, чи проблема у SSSD/LDAP, а не в DNS?

Заміряйте id $USER і getent passwd $USER. Якщо вони повільні — повільний lookup ідентичності. Якщо лише розв’язування hostname повільне — зосередьтеся на hosts: і доступності DNS.

8) Чому це проявилося після переміщення VM або зміни мережі?

Бо DNS-сервери часто специфічні для мережі. Хардкодні резолвери, застарілі DHCP-опції або політики DNS VPN не виживають при переміщенні.

9) Чи важливий IPv6, якщо я «не використовую IPv6»?

Важливий, якщо ваш резолвер намагається AAAA-запити, а мережа їх відкидає або «поглинає». Підтримуйте IPv6 повністю або відключіть послідовно; напівзаходи створюють тайм-аути.

10) Який найкращий швидкий фікс під тиском?

Додайте правильний мапінг hostname у /etc/hosts і переконайтеся, що getent hosts $(hostname) миттєвий. Потім виправляйте upstream DNS, коли опинитеся поза зоною негайного ризику.

Висновок: практичні наступні кроки

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

Робіть це по порядку:

1. Заміряйте sudo -n true і getent hosts $(hostname).
2. Виправте /etc/hosts, щоб hostname розв’язувався локально і миттєво.
3. Використайте resolvectl status і логи resolved, щоб знайти недоступні DNS-сервери і скорегувати netplan/DHCP/VPN.
4. Обріжте search-домени і уникайте коротких імен в автоматизації.
5. Лише потім думайте про налаштування порядку NSS і робіть це обдумано.

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