Ubuntu 24.04: DNS-кеші брешуть — очищуйте правильний кеш (і припиніть чистити не той) (випадок #86)

Реальна модель: де відповіді DNS кешуються на Ubuntu 24.04

DNS на сучасному хості Ubuntu — це естафета, і кожен бігун може вести власний записник. Коли ви запитуєте «яка сьогодні api.example.internal?», відповідь може надійти від:

1) Ваш додаток (так, ваш додаток)

Багато runtime-ів кешують DNS агресивно або дивно:

• Java: кешування DNS залежить від політик безпеки; іноді кеш може зберігатися назавжди в певних налаштуваннях.
• Go: може використовувати системний резолвер або чисто Go-реалізацію (pure-Go) залежно від прапорців збірки та середовища; поведінка відрізняється.
• Python: бібліотеки можуть кешувати, HTTP-клієнти можуть пулити з’єднання, і «проблеми з DNS» іноді — це застарілі keep-alive сокети.
• glibc: традиційно не забезпечує повний DNS-кеш, але має поведінку на кшталт options attempts, timeout і може бути під впливом модулів NSS.

Якщо ваш додаток кешує DNS, очищення systemd-resolved не допоможе. Можливо, треба перезапустити додаток.

2) NSS (Name Service Switch) і порядок його роботи

Файл /etc/nsswitch.conf вирішує, чи перевіряє хост /etc/hosts перед DNS, чи використовує mDNS та інше. Рядок на кшталт цього:

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

…означає, що /etc/hosts може перекривати DNS, а mDNS може короткозамкнути запити. Коли хтось каже «DNS брешуть», іноді це не DNS — це NSS, який виконує правила ваших локальних файлів.

3) systemd-resolved (звичайний підозрюваний на Ubuntu 24.04)

Ubuntu 24.04 зазвичай працює з systemd-resolved і вказує /etc/resolv.conf на stub-резолвер (часто 127.0.0.53). Цей стуб кешує відповіді, виконує DNSSEC-валідaцію залежно від конфігурації, може використовувати DNS-over-TLS і може маршрутизувати запити поінтерфейсно (per-link) залежно від налаштувань мережі.

4) Локальний кешуючий резолвер, який ви встановили навмисно

Деякі середовища розгортали dnsmasq, unbound або bind9 на хостах чи вузлах. Це окремий кеш. Очищення systemd-resolved не очистить unbound. Шок, я знаю.

5) Upstream-резолвери: корпоративні DNS, VPC-резолвери, kube-dns/CoreDNS, резолвери провайдерів

Навіть якщо ваш хост «чистий», upstream-резолвери теж кешують — часто з власними мінімальними TTL, поведінкою prefetch або налаштуваннями негативного кешування. Якщо upstream видає застарілі дані, хост не зможе «очистити» їх. Ви можете лише обійти їх або змусити оновити (і можливо не матимете дозволу).

6) Мережеві пристрої посередині та «корисні» продукти безпеки

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

Одна перефразована ідея, бо вона й досі найкраща операційна порада: перефразована ідея — ви не можете виправити те, що не можете спостерігати (атрибутовано темам надійності/DevOps Джина Кіма).

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

Жарт #1: DNS — це єдина система, де «це кешується» одночасно пояснення і зізнання.

Цікаві факти й історичний контекст (чому сьогоднішній безлад має сенс)

1. Негативне кешування DNS існує десятиліттями. Відповіді NXDOMAIN можуть кешуватися з використанням SOA «minimum» значення, тож «не існувало п’ять хвилин тому» може зберігатися.
2. Історія резолверів в Ubuntu змінювалася кілька разів. Між resolvconf, systemd-resolved, NetworkManager і netplan «правильне місце» для налаштування DNS залежить від епохи.
3. /etc/resolv.conf тепер часто символічне посилання. На системах з systemd воно може вказувати на стуб, яким керує resolved; редагування його вручну може бути скасовано при перезавантаженні або зміні зв’язків.
4. glibc історично уникала повного DNS-кешу. Це рішення перемістило кешування в окремі демони (як nscd) і пізніше в systemd-resolved та програми.
5. Браузери стали власними резолверами. Сучасні браузери агресивно кешують, роблять prefetch і іноді використовують DNS-over-HTTPS; «працює в dig» не гарантує «працює в Chrome».
6. TTL — це не обіцянка; це підказка. Деякі резолвери обрізають TTL (мінімум/максимум), а деякі клієнти продовжують кешувати через внутрішні політики.
7. Split-horizon DNS — це функція, а не помилка. Одне й те саме ім’я може легітимно резолвитися по-різному залежно від мережі; «неправильна» відповідь може бути правильною для іншого інтерфейсу.
8. IPv6 може «перемогти», навіть якщо ви цього не хочете. Багато клієнтів запитують AAAA першими; якщо шлях по IPv6 зламаний, це виглядає як нестабільність DNS.
9. systemd-resolved може маршрутизувати DNS по інтерфейсах. VPN увімкнено? Тепер частина імен йде до VPN-резолвера, а інша — до LAN-резолвера, залежно від routing domains.

Швидкий план діагностики (перевірте спочатку це, по черзі)

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

Крок 1: Визначте, що саме робить додаток

• Він використовує системний резолвер (glibc/NSS) чи внутрішній резолвер (браузер, JVM, Go netgo)?
• Чи «проблема DNS» насправді — застарілий пул TCP-з’єднань?
• Чи працює він у контейнері з власним /etc/resolv.conf?

Крок 2: Доведіть, який стек резолвера на хості

• Чи /etc/resolv.conf — це stub на 127.0.0.53?
• Чи активний systemd-resolved?
• Чи присутні dnsmasq, unbound, nscd?

Крок 3: Порівняйте відповіді по різних шляхах

• Порівняйте getent hosts (шлях NSS) проти dig @server (прямий резолвер) проти поведінки додатку.
• Перевірте як A, так і AAAA, і підтвердіть, який запис використовується.

Крок 4: Якщо є кешування — знайдіть який кеш

• Очищуйте systemd-resolved тільки якщо він дійсно є шаром кешування, що використовується.
• Якщо upstream-резолвер застарілий — обходьте його або запитуйте авторитетні/альтернативні резолвери для підтвердження.
• Якщо додаток кешує — перезапустіть або переналаштуйте додаток; не бийте по ОС.

Крок 5: Перевірте на мережі

• Використовуйте tcpdump на порту 53 (або 853 для DoT), щоб побачити, чи запити виходять з машини.
• Якщо пакети не виходять — ви не маєте справи з «сервером DNS»; маєте справу з локальним резолвером.

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

Це призначено для запуску на серверах і робочих станціях Ubuntu 24.04. Кожне завдання включає (1) команду, (2) що означає вивід і (3) яке рішення приймати далі.

Завдання 1: Подивіться, що насправді становить /etc/resolv.conf

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jun 12 09:41 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Ви використовуєте стуб systemd-resolved. Більшість додатків буде звертатися до 127.0.0.53, а не безпосередньо до upstream DNS-серверів.

Рішення: Перестаньте редагувати /etc/resolv.conf вручну. Перегляньте конфігурацію resolved та DNS для кожного інтерфейсу.

Завдання 2: Підтвердьте, що 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 Fri 2025-12-26 10:12:01 UTC; 2h 41min ago
       Docs: man:systemd-resolved.service(8)

Значення: Є локальний кешуючий стуб у роботі.

Рішення: Використовуйте resolvectl як основний інструмент діагностики; очищення resolved може бути релевантним.

Завдання 3: Знайдіть фактичні upstream DNS-сервери, що використовує resolved

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

Link 2 (ens160)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.internal

Значення: Upstream-серверами є 10.20.0.53/54, і є routing domain (corp.internal).

Рішення: Якщо відповіді застарілі, треба визначити, чи проблема в кеші resolved, чи в 10.20.0.53.

Завдання 4: Порівняйте шлях NSS і прямий DNS-запит

cr0x@server:~$ getent hosts api.corp.internal
10.50.12.19     api.corp.internal

cr0x@server:~$ dig +short api.corp.internal
10.50.12.19

Значення: Принаймні зараз NSS і стуб-резолвер погоджуються.

Рішення: Якщо додаток іще звертається до старої IP, підозрюйте кешування на рівні додатку або повторне використання з’єднань.

Завдання 5: Обійдіть стуб і запитайте upstream-сервер безпосередньо

cr0x@server:~$ dig @10.20.0.53 api.corp.internal +noall +answer +ttlid
api.corp.internal.  30  IN  A  10.50.12.19

Значення: Upstream-резолвер повертає 10.50.12.19 з TTL 30 секунд.

Рішення: Якщо ваш хост повертає щось інше — проблема локального кешування/маршрутизації. Якщо upstream неправильний — локальне очищення — театральність.

Завдання 6: Перевірте, чи /etc/hosts не перекриває DNS

cr0x@server:~$ grep -n 'api.corp.internal' /etc/hosts || true
12:10.10.10.10 api.corp.internal

Значення: У вас є жорстке перекриття. NSS ймовірно поверне це перед DNS.

Рішення: Видаліть або виправте запис, потім повторно перевірте getent hosts. Очищення кешів не виправить файл.

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

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

Значення: files (тобто /etc/hosts) стоїть першою. mDNS може перехоплювати деякі імена.

Рішення: Якщо ви переслідуєте ім’я, яке може обробляти mDNS (.local), тестуйте з ним і без нього. Якщо політика забороняє mDNS-сюрпризи, скоригуйте порядок.

Завдання 8: Очищення кешу systemd-resolved (тільки коли це правильний шар)

cr0x@server:~$ sudo resolvectl flush-caches

Значення: Resolved скидає кеш позитивних і негативних відповідей.

Рішення: Негайно повторіть resolvectl query name або getent hosts. Якщо відповіді не змінилися, «брехня» не в кеші resolved.

Завдання 9: Показати статистику кешу (чи використовується кеш?)

cr0x@server:~$ resolvectl statistics
DNSSEC Verdicts:                 Secure=0 Insecure=0 Bogus=0 Indeterminate=0
Cache:                           Current Cache Size=42 Max Cache Size=4096
Cache Hits:                      118
Cache Misses:                    67
Cache Evictions:                 0
DNS Transactions:                79

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

Рішення: Якщо Cache Hits близькі до нуля — ваша проблема, ймовірно, не в кеші resolved; шукайте кешування в додатку або інший резолвер.

Завдання 10: Запит через resolved з детальною інформацією

cr0x@server:~$ resolvectl query api.corp.internal
api.corp.internal: 10.50.12.19                       -- link: ens160

-- Information acquired via protocol DNS in 28.4ms.
-- Data is authenticated: no

Значення: Показує, який інтерфейс/лінк використовувався. Це критично, коли є VPN або кілька NIC.

Рішення: Якщо запит йшов не тим лінком — виправляйте per-link DNS налаштування (netplan/NetworkManager/systemd-networkd), а не кеші.

Завдання 11: Ловіть DNS на мережі (доведіть, чи запити виходять з хоста)

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:41:15.219233 ens160 Out IP 10.20.1.44.53344 > 10.20.0.53.53: 12345+ A? api.corp.internal. (35)
10:41:15.245090 ens160 In  IP 10.20.0.53.53 > 10.20.1.44.53344: 12345 1/0/0 A 10.50.12.19 (51)

Значення: Запити виходять до 10.20.0.53 і відповіді повертаються. Якщо ваш додаток все ще бачить іншу IP, проблема над системним шляхом резолвера (кеш додатка або повторне використання з’єднань) або різниця split-horizon у середовищі додатка.

Рішення: Якщо під час виконання запитів ви не бачите вихідних пакетів — ви потрапляєте в локальний кеш або зовсім інший механізм (наприклад DoH у браузері).

Завдання 12: Перевірте, чи використовується DoT (порт 853)

cr0x@server:~$ sudo tcpdump -ni any 'tcp port 853'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:43:50.102991 ens160 Out IP 10.20.1.44.42132 > 10.20.0.53.853: Flags [S], seq 205383221, win 64240, options [mss 1460,sackOK,TS val 151512 ecr 0,nop,wscale 7], length 0

Значення: Ви використовуєте DNS-over-TLS. Деякі мережеві пристрої та інструменти припускають лише UDP/53; вони введуть вас в оману.

Рішення: При діагностиці «DNS блокується» перевіряйте правила фаєрволу для 853 і підтверджуйте підтримку резолвера.

Завдання 13: Підтвердьте, що бачить контейнер (приклад Docker)

cr0x@server:~$ sudo docker run --rm alpine:3.20 cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

Значення: Контейнери можуть використовувати вбудований DNS Docker (127.0.0.11), який має свій шар кешування/форвардингу.

Рішення: Якщо тільки контейнери зламались — перестаньте очищувати кеші хоста і перевірте DNS-конфігурацію контейнера та engine.

Завдання 14: Подивіться, до яких IP реально підключається ваш додаток

cr0x@server:~$ sudo ss -tnp | grep ':443' | head
ESTAB 0 0 10.20.1.44:50412 10.10.10.10:443 users:(("myapp",pid=23144,fd=27))

Значення: Додаток підключений до 10.10.10.10. Якщо DNS показує 10.50.12.19, можливо у вас застарілий пул з’єднань, старий результат резолвингу в процесі або перекриття /etc/hosts.

Рішення: Перезапустіть додаток або перерахуйте його пул з’єднань; не звинувачуйте DNS, поки не довели, що відбувається новий пошук.

Завдання 15: Перевірте наявність nscd (ще один шар кешування)

cr0x@server:~$ systemctl is-active nscd || true
inactive

Значення: nscd не активний. Добре: один кеш менше, з яким сперечатися.

Рішення: Якщо він активний у вашому середовищі — вивчіть, як він кешує, і очищуйте за потреби; інакше ви будете гнатися за привидами.

Завдання 16: Визначте, хто займає порт 53 локально (конфлікти)

cr0x@server:~$ sudo ss -lunp | grep ':53 ' || true
UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=862,fd=13))

Значення: Стуб-резолвер слухає. Якщо ви очікували dnsmasq на 127.0.0.1:53 — це невідповідність.

Рішення: Не запускайте кілька локальних DNS-демонів без плану; вирішіть, який процес володіє стубом і як клієнти повинні до нього звертатися.

Завдання 17: Перевірте негативне кешування (NXDOMAIN), яке може застрягти

cr0x@server:~$ resolvectl query doesnotexist.corp.internal
doesnotexist.corp.internal: resolve call failed: 'does not exist'

Значення: NXDOMAIN в діях. Якщо це ім’я щойно створене, ви можете боротися з негативним кешуванням локально або upstream.

Рішення: Очистіть локальні кеші, потім запитайте upstream безпосередньо. Якщо upstream і надалі повертає NXDOMAIN — зміна DNS ще не розійшлася там.

Очищення правильного кешу (і чому звична порада неправильна)

Класична погана порада звучить так: «У Linux виконайте sudo systemctl restart networking» або «перезапустіть NetworkManager» чи «редагуйте /etc/resolv.conf і впишіть 8.8.8.8». Така порада має місце в музеї поруч із модемами dial-up.

Що може означати «очистити DNS» на Ubuntu 24.04

• Очистити systemd-resolved: sudo resolvectl flush-caches
• Перезапустити resolved (серйозніша дія): sudo systemctl restart systemd-resolved
• Очистити кеш браузера: це не команда ОС; це налаштування або дія в браузері
• Очистити вбудований DNS Docker: часто потребує перезапуску контейнерів або демона; це не стуб хоста
• Очистити upstream-резолвер: потребує доступу до того резолвера; клієнтська машина цього не зробить

Як обрати правильне очищення

Використовуйте це дерево рішень:

1. Якщо getent hosts name неправильне, але dig @upstream name правильне: очистіть systemd-resolved (і перевірте per-link routing domains).
2. Якщо getent правильний, але ваш додаток неправильний: ймовірно кешування на рівні додатку, застарілі з’єднання або інший шлях резолвера (DoH, netgo, JVM).
3. Якщо dig @upstream неправильний: локальне очищення не допоможе. Ескалюйте до власників DNS або обходьте резолвер для перевірки.
4. Якщо контейнери неправильні, а хост правильний: ви в області DNS контейнерів (127.0.0.11, kube-dns, CoreDNS, node-local-dns).

Єдине «очищення», яке слід робити за замовчуванням

Ніяке. За замовчуванням очищення — це робота для зайнятих рук. За замовчуванням ваша дія має бути доведіть шлях, а потім очищайте шар, який реально кешує.

Жарт #2: Перезапуск NetworkManager, щоб виправити DNS, — це як перезавантажити офіс, щоб виправити опечатку.

Три корпоратні міні-історії з DNS-траншей

Міні-історія 1: Інцидент через хибне припущення («очистили DNS, все ще зламано»)

Середня SaaS-компанія розгорнула нову внутрішню кінцеву точку за балансувальником навантаження. Зміна була чистою: оновили DNS зі старого VIP на новий, TTL встановили 30 секунд, і зробили повільне міграційне вікно. On-call виконав dig і одразу побачив нову IP. Почуття перемоги.

Але сервери додатків продовжували викликати старий VIP ще годину. Деякі запити вдавалося обробити (бо старий VIP ще обслуговував), інші потрапляли в мертвий бекенд і таймаути. Канал інциденту наповнився повідомленнями «DNS кешовано десь». Хтось очистив systemd-resolved на підмножині серверів. Без змін.

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

Виправлення було не в «очищенні DNS». Виправлення: зменшити TTL кешу DNS у JVM до розумних значень для цього сервісу, додати крок перезапуску/перерозподілу пулу з’єднань під час зміни кінцевих точок і покращити ранбуки, щоб «dig каже X» не завершував розслідування.

Вони також болісно засвоїли: TTL DNS не змушує клієнтів поводитися. Він ввічливо пропонує. Продакшн-системи не відомі своєю ввічливістю.

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

Велике підприємство з шумною мережею мікросервісів вирішило зменшити навантаження на центральні резолвери. Ідея була раціональною: встановити локальний кешуючий резолвер на кожній VM. Вони обрали легкий форвардер з агресивними налаштуваннями кешування. Латенсія покращилася в синтетичних тестах. Графіки резолверів стали спокійніші. Два тижні — і всі пішли додому вчасно.

Потім стався інцидент з безпеки, коли треба було швидко перенаправити набір імен сервісів від скомпрометованого сегмента мережі. DNS-зміни внесли централізовано. Деякі вузли оновилися швидко, інші ні. План «кеш у кожного» перетворився на «нестиковка у всіх місцях».

Що їх підвело — не лише позитивне кешування. Негативне кешування і поведінка serve-stale (налаштована, щоб приховати upstream-флапи) означали, що деякі хости продовжували повертати старі відповіді, навіть коли upstream змінився. Весь сенс DNS — швидка індикація — був притлумлений «налаштуванням на продуктивність».

Виправлення вимагало двох змін: політики нав’язування обмежень TTL (не розширювати авторитетний TTL для критичних імен) і наявності операційного важеля для інвалідизації кешів для певних зон під час інцидентів. Вони залишили локальні кеші, але почали ставитися до них як до інфраструктури з контролем змін і спостережуваністю, а не як до «швидкої оптимізації».

Урок: кеші не безкоштовні. Це маленькі розподілені бази даних з характером.

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

Команда фінтеху працювала на Ubuntu 24.04 на суміші bare metal і VM. Одного ранку підмножина вузлів перестала діставати до API платіжного партнера після змін DNS у партнера. Партнер наполягав, що DNS оновлено. Команда одразу побачила нові записи в dig на одному хості. Інші — ні. Паніка з’явилася швидко.

On-call дотримувався нудної, але надійної рутини: спочатку resolvectl status, щоб підтвердити upstream-сервери; потім getent hosts для поведінки NSS; потім прямий dig @upstream. Результати були послідовні: деякі вузли запитували один корпоративний резолвер, інші — інший, через per-link DNS маршрутизацію після події failover VPN.

Вони не «очищували DNS і молилися». Вони зробили короткий tcpdump, який показав, до якого резолвера кожен уражений хост звертається та які відповіді повертаються. Той пакетний дамп закінчив суперечку за десять хвилин, бо пакети не займаються політикою.

Коли корінь проблеми став зрозумілий — розбіжність шляхів резолверів — вони виправили мережеву конфігурацію, щоб усі вузли використовували ту ж пару резолверів для того routing domain, і додали моніторинг, що перевіряє список per-link DNS серверів у resolved на дрейф.

Це не було гламурно. Це було правильно. І це запобігло багатогодинним суперечкам між командами застосунків, мережі та зовнішнім партнером.

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

1) Симптом: dig показує нову IP, додаток усе ще використовує стару IP

Корінь проблеми: Кешування на рівні додатку або постійне повторне використання з’єднань (pooling/keep-alive). Іноді додаток ніколи не переобчислює адресу після старту.

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

2) Симптом: Очищення systemd-resolved нічого не змінює

Корінь проблеми: Неправильний шар кешу. Або upstream застарілий, або клієнт не використовує resolved (контейнери, DoH, власний резолвер).

Виправлення: Запитайте upstream напряму з dig @server; перевірте /etc/resolv.conf в контейнері; зловіть трафік tcpdump.

3) Симптом: Лише деякі інтерфейси/вузли резолвлять внутрішні домени

Корінь проблеми: Per-link DNS маршрутизація / split-horizon domains; VPN або вторинний NIC змінили routing domains у resolved.

Виправлення: Використовуйте resolvectl status і resolvectl query, щоб побачити, який лінк відповів; виправте netplan/NetworkManager конфіг, щоб потрібний інтерфейс володів доменом.

4) Симптом: Ім’я «не існує» одразу після створення

Корінь проблеми: Негативне кешування (локальне або upstream). Ваш резолвер закешував NXDOMAIN згідно з параметрами SOA.

Виправлення: Очистіть локальні кеші; запитайте кілька upstream-резолверів; зачекайте негативний TTL або інвалідуйте кеш upstream, якщо ви контролюєте його.

5) Симптом: getent hosts повертає дивну IP, яку dig не показує

Корінь проблеми: Перекриття /etc/hosts або порядок NSS/mDNS-перехоплення.

Виправлення: Перевірте /etc/hosts і /etc/nsswitch.conf; приберіть застарілі перекриття; повторно виконайте getent hosts.

6) Симптом: IPv4 іноді працює, IPv6 падає і це «виглядає як DNS»

Корінь проблеми: Присутній AAAA-запис; клієнт віддає перевагу IPv6; шлях IPv6 зламаний.

Виправлення: Перевірте dig AAAA name; підтвердьте IPv6-зв’язність; виправте маршрутизацію/фаєрвол або змініть політику клієнта.

7) Симптом: Контейнери не резолвлять, хост — так

Корінь проблеми: DNS-шар runtime контейнера (127.0.0.11) або конфігурація Kubernetes DNS; node-local кеш може відрізнятись.

Виправлення: Перевірте /etc/resolv.conf всередині контейнера; протестуйте резольвінг з контейнера; налаштуйте daemon/kube DNS замість кешів хоста.

8) Симптом: DNS-запити періодично таймаутять

Корінь проблеми: Фаєрвол, проблеми MTU або досяжність резолвера; іноді TCP-фолбек блокується; іноді DoT блокується.

Виправлення: Використовуйте tcpdump для перегляду повторних спроб; тестуйте TCP/53 і TCP/853; підтвердьте маршрутизацію й правила безпеки.

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

Контрольний список при інциденті: «DNS неправильний на Ubuntu 24.04»

1. Підтвердьте, що ви тестуєте: Ви тестуєте додаток, NSS чи прямий DNS?
2. Перевірте режим резолверу: ls -l /etc/resolv.conf і systemctl status systemd-resolved.
3. Проінспектуйте per-link DNS: resolvectl status.
4. Порівняйте відповіді: getent hosts name vs dig name vs dig @upstream name.
5. Перевірте перекриття: grep name /etc/hosts і grep '^hosts:' /etc/nsswitch.conf.
6. Очищуйте лише якщо обґрунтовано: sudo resolvectl flush-caches.
7. Підтвердіть на мережі: tcpdump для портів 53/853 під час запитів.
8. Якщо невідповідність додатка триває: перевірте з’єднання (ss -tnp), перезапустіть/оновіть пул додатка і дослідіть кешування в runtime.
9. Якщо upstream застарілий: ескалюйте до власників DNS або обходьте для перевірки; не очищуйте клієнти без потреби.

Профілактичний чекліст: щоб уникнути майбутніх «брехливих DNS»

1. Уніфікуйте власність над резолвером: вирішіть, чи повсюди використовується resolved як стуб, чи ви запускаєте виділений локальний резолвер. Не робіть обох випадково.
2. Встановіть розумні очікування TTL: документуйте, які TTL використовуються для критичних імен і як кеші можуть їх обрізати.
3. Операціоналізуйте зміни DNS: для міграцій кінцевих точок додавайте кроки перезапуску/перерозподілу пулів додатків, коли клієнти можуть кешувати.
4. Моніторьте дрейф резолверів: налаштуйте оповіщення, якщо per-link DNS сервери відрізняються від очікуваних (особливо після VPN-подій).
5. Розділіть «резольвінг» і «підключення» в ранбуках: завжди перевіряйте фактичну підключену IP і маршрут, не лише відповіді DNS.
6. Навчайте команди NSS: зробіть getent стандартним інструментом для відповіді на питання «що побачать додатки?».

FAQ

1) На Ubuntu 24.04 яка правильна команда для очищення DNS?

Якщо ви використовуєте systemd-resolved (поширено на 24.04), використовуйте sudo resolvectl flush-caches. Але лише після того, як довели, що resolved — шар кешування у вашому шляху.

2) Чому dig показує одну IP, а мій додаток використовує іншу?

dig — це прямий DNS-клієнт; ваш додаток, ймовірно, використовує NSS і системний стек резолверів, або кешує всередині процесу, або повторно використовує існуючі з’єднання. Порівняйте з getent hosts і перевірте активні з’єднання за допомогою ss -tnp.

3) Чи краще перезапустити systemd-resolved, ніж очищати кеш?

Перезапуск — важчий крок і може тимчасово порушити резольвінг. Спочатку краще спробувати resolvectl flush-caches. Перезапускайте тільки якщо resolved завис або ви змінили його конфігурацію.

4) Чому мені не варто редагувати /etc/resolv.conf прямо?

Бо на Ubuntu 24.04 це часто символічне посилання, яким керують systemd/netplan/NetworkManager. Ваші правки можуть зникнути після перезавантаження або зміни зв’язків, і ви будете дебажити файл вчорашнього дня.

5) Яка команда дає «істину» про те, що система справді резолвить?

getent hosts name. Вона слідує правилам NSS, включно з /etc/hosts, mDNS та DNS через налаштований стек резолверів.

6) Чи може systemd-resolved маршрутизувати DNS по різних інтерфейсах?

Так. Він може обирати DNS-сервери та пошукові домени для кожного лінку. Це типова причина, чому «деякі вузли працюють, а деякі ні», особливо з VPN.

7) Як дізнатися, що проблема кешу — upstream, а не локальна?

Запитайте upstream-сервер напряму: dig @DNS_SERVER name. Якщо upstream неправильний, локальне очищення не змінить відповідь.

8) Чому новостворений DNS-запис досі повертає NXDOMAIN?

Через негативне кешування. NXDOMAIN відповіді можуть кешуватися згідно з параметрами SOA. Очистіть локальні кеші, перевірте upstream; якщо upstream і далі повертає NXDOMAIN — зачекайте або інвалідуйте кеш upstream, якщо ви керуєте ним.

9) Мій хост резолвить добре, а контейнери — ні. Чому?

Контейнери часто використовують іншу адресу резолвера (наприклад Docker 127.0.0.11) і мають інші правила форвардингу. Діагностуйте зсередини контейнера і виправляйте шар DNS контейнера, а не стуб хоста.

10) Як довести, який IP резолвер використовує хост без гадань?

resolvectl status показує поточний DNS-сервер і per-link DNS. Поєднайте це з tcpdump, щоб підтвердити, чи трафік іде саме куди ви думаєте.

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

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

Наступного разу робіть це в такому порядку:

1. Виконайте getent hosts, щоб побачити, що бачитимуть додатки.
2. Виконайте resolvectl status і resolvectl query, щоб дізнатися, який лінк і який upstream-резолвер задіяні.
3. Виконайте dig @upstream, щоб відокремити локальне кешування від upstream-старіння.
4. Використовуйте tcpdump, коли починаються суперечки. Пакети розставляють крапки над i.
5. Очищуйте тільки той кеш, який ви довели, що знаходиться у шляху.

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