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

December 25, 2025 • February 3, 2026 • Читання: 5 хв • Views: 9

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

Збої DNS рідко заявляють про себе словами «збої DNS». Вони проявляються як помилка TLS, тайм‑аут у клієнта API, вузол Kubernetes, який «не може завантажити образи», або ноутбук, який ламається лише в офісному Wi‑Fi. Тоді хтось вимовляє древнє заклинання: «flush DNS». Через десять хвилин усе ще не працює. Ви витратили час і підвели себе до невірного ритуалу.

Ubuntu 24.04 — особливо хороший привід вивчити цю невтішну істину, бо тут може бути кілька шарів кешування й декілька шляхів резолюції. Результат: ваші DNS‑кеші можуть брехати — не зі зла, а механічно. Ваше завдання — очистити кеш, який реально повертає відповідь, і довести це інструментами, які не брешуть у відповідь.

Ментальна модель: DNS — це конвеєр, а не поодинока перевірка

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

Поведінка резолвера програми (glibc NSS, чистий резолвер Go, Java, curl з c-ares, власний кеш Chromium).
Локальний stub‑резолвер (часто systemd-resolved, який слухає на 127.0.0.53).
Локальний кешуючий форвардер (іноді dnsmasq, іноді відсутній).
Верхні рекурсивні резолвери (корпоративний DNS, ISP, cloud resolver, Unbound, BIND).
Авторитарний DNS (Route 53, Cloud DNS, on‑prem BIND тощо).
Anycast і CDN‑edge (бо «відповідь DNS» може відрізнятися залежно від місця запиту).

Кожен із цих шарів може кешувати. Кожний з них може мати власні правила щодо TTL, негативного кешування (кешування «NXDOMAIN»), поведінки DNSSEC або того, який DNS‑сервер «переважає». Тому так — ваша машина може наполягати, що api.internal.example вказує на стару IP‑адресу навіть після того, як ви «очистили DNS». Ймовірно, ви очистили кеш, який не використовувався.

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

Одна перефразована ідея від Gene Kim (операції та надійність): Покращуйте результати скороченням циклів зворотного зв’язку; робіть проблеми видимими швидко і фіксуйте систему замість сподівань на героїчні дії.

Цікаві факти та історичний контекст (чому це так заплутано)

Факт 1: DNS передував вебу на роки; його розробляли для меншого, повільніше змінного інтернету. Кешування було фічею, а не випадковістю.
Факт 2: Концепція «stub‑резолвера» існує тому, що більшість програм не повинні реалізовувати повну рекурсивну DNS‑логіку. Вони питають локального агента, який питає мережу.
Факт 3: Класичний файл /etc/resolv.conf створювався для статичних серверів. Сучасні системи часто генерують його динамічно, іноді як символьне посилання.
Факт 4: Негативне кешування (кешування «не існує») стандартизоване. Ось чому тимчасово відсутній запис може переслідувати довше, ніж ви очікуєте.
Факт 5: «Split‑horizon DNS» (різні відповіді залежно від того, звідки запитують) поширений у корпоративних мережах. Це також робить налагодження схожим на газлайтинг.
Факт 6: systemd-resolved існує частково, щоб уніфікувати хаотичний світ DNS на різних інтерфейсах, VPN і рішеннях DNSSEC. Можливо, вам це не подобається, але воно намагається зупинити кровотечу.
Факт 7: Деякі мови обходять glibc і роблять свій власний DNS. Go — відомий приклад, але не єдиний. Ваш додаток може не використовувати той самий шлях, що й dig.
Факт 8: Браузери теж кешують DNS. Навіть якщо ОС‑кеш ідеальний, браузер може зберігати застарілу відповідь і змусити вас звинувачувати мережу.

Налагодження DNS дратує через розподілений стан. Коли стан розподілений, упевненість — розкіш. Докази — дешевші.

Стек резолвера в Ubuntu 24.04: хто відповідає на ваш запит?

В Ubuntu 24.04 найпоширеніший дефолт:

systemd-resolved запущений як сервіс.
Stub‑резолвер на 127.0.0.53, опублікований через згенерований /etc/resolv.conf.
Верхні DNS‑сервери, що надаються NetworkManager, netplan/systemd-networkd, DHCP або VPN‑клієнтами.

Але виробничі машини рідко залишаються «дефолтними» надовго. У вас може бути:

dnsmasq встановлений для локального кешування або split DNS для контейнерів.
nscd (Name Service Cache Daemon), що все ще може залишатися через старі гайди з налаштування.
Компоненти Kubernetes, Docker або systemd‑networkd, що маніпулюють DNS для окремих інтерфейсів.
VPN, який пушить свої DNS‑сервери та правила маршрутизації.
Додатки, що використовують DoH (DNS over HTTPS) або власні бібліотеки резолюції.

Суть: «Очистити DNS» — це не одна команда. Це дерево рішень.

Жарт #1: DNS як офісні плітки: поширюється швидко, кешується скрізь, і спростування має значно нижчий TTL.

Що означає «очистити»

Очищення допомагає тільки якщо:

Шар дійсно кешує.
Шар реально використовується для проблемного запиту.
Збій спричинений застарілим кешованим станом (а не маршрутизацією, фаєрволом, невідповідністю TLS SNI, конфігом проксі або вибором IPv6).

Якщо запис неправильний в авторитарному DNS, очищення клієнтів цього не виправить. Якщо верхні рекурсивні резолвери видають застарілі дані через власний кеш, очищення ноутбука теж не допоможе. І якщо програма взагалі не питає ОС про DNS, очищення systemd-resolved — це перформанс‑арт.

Швидкий план діагностики: знайдіть вузьке місце за кілька хвилин

Ось порядок, який я використовую на виклику. Він оптимізований під «що змінилося, що зламалося і який найшвидший доказ».

1) Підтвердьте, що симптом — DNS, а не «неможливо дістатися IP»

Якщо ви маєте очікувану IP‑адресу, спробуйте підключитися напряму по IP (HTTP з Host header, TLS з урахуванням SNI).
Якщо пряме підключення працює, а ім’я — ні, швидше за все це DNS.

2) Визначте, яким шляхом резолюції користується проблемна програма

Чи використовує вона glibc NSS? (Більшість рідних Linux‑інструментів так.)
Чи це Go з чистим резолвером? Java? Браузер з власним кешем/DoH?
Запущена вона в контейнері з іншим /etc/resolv.conf?

3) Запитайте у stub ОС, що він вважає

Використовуйте resolvectl query і перевірте статус кешу, вибір серверів і записи.

4) Запитайте безпосередньо верхні резолвери

Використовуйте dig @server name проти корпоративного резолвера, потім проти відомо‑правильного резолвера в тій же мережі.
Порівняйте відповіді і TTL.

5) Очищуйте конкретний шар, який неправильний

Очистіть systemd-resolved, якщо він неправильний.
Перезапустіть dnsmasq, якщо він у шляху й кешує.
Очистіть кеші браузера/додатка, якщо ОС‑відповідь правильна, але додаток помиляється.

6) Якщо кеші виглядають узгодженими: підозрівайте split DNS, VPN‑маршрути або вибір IPv6

Перевірте DNS по кожному інтерфейсу та правила маршрутизації.
Перевірте, чи додаток не віддає перевагу AAAA‑записам, які не маршрутизуються.

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

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

Task 1: See what `/etc/resolv.conf` really is

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

Значення: Ви використовуєте stub‑файл systemd-resolved (ймовірно 127.0.0.53). Багато гайдів з «flush DNS» для інших дистрибутивів тут не застосуються.

Рішення: Використовуйте resolvectl і systemctl для інспекції та очищення. Не редагуйте /etc/resolv.conf вручну, якщо ви навмисно не перевизначаєте систему.

Task 2: Confirm `systemd-resolved` is running

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 Mon 2025-12-30 09:10:14 UTC; 2h 11min ago
       Docs: man:systemd-resolved.service(8)
             man:resolvectl(1)
   Main PID: 812 (systemd-resolve)
     Status: "Processing requests..."

Значення: Локальний кеш і stub активні.

Рішення: Очищення nscd або перезапуск випадкових мережевих сервісів, ймовірно, невірний крок. Почніть із resolvectl.

Task 3: Inspect resolver configuration (servers, interfaces, DNSSEC)

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

Link 2 (ens3)
Current Scopes: DNS
     Protocols: +DefaultRoute
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.example

Значення: Система використовує корпоративні резолвери, а активним сервером є 10.20.0.53. Це підказує, кого слід допитати далі.

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

Task 4: Ask the OS resolver for a name and see what it returns

cr0x@server:~$ resolvectl query api.internal.example
api.internal.example: 10.70.8.19                           -- link: ens3

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

Значення: Це те, що ваш ОС‑резолвер вважає зараз. Тут також видно, який лінк (інтерфейс) використано і, отже, які пер‑інтерфейсні налаштування DNS застосовані.

Рішення: Якщо відповіть ОС неправильна — очистіть кеш systemd-resolved. Якщо вона правильна, а додаток помиляється — підозрюйте кешування на рівні додатка або інший шлях резолюції.

Task 5: Check if the result is coming from cache

cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no

Transactions
        Current Transactions: 0
              Total Requests: 14382
            Cache Hits: 9112
          Cache Misses: 5270

Cache
          Current Cache Size: 216
                  Cache Hits: 9112
                Cache Misses: 5270

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

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

Task 6: Flush `systemd-resolved` cache (the right “flush” most of the time)

cr0x@server:~$ sudo resolvectl flush-caches

Значення: Відсутність виводу — це нормально. Це очищує кеші systemd-resolved (як позитивні, так і негативні).

Рішення: Негайно повторно виконайте resolvectl query. Якщо відповідь залишається неправильною, ймовірно, верхній резолвер повертає ту саму неправильну інформацію.

Task 7: Prove what the upstream resolver says (bypass local cache)

cr0x@server:~$ dig @10.20.0.53 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.internal.example.  300 IN A 10.70.8.19

Значення: Верхній резолвер повертає той же A‑запис з TTL 300 секунд. Якщо він неправильний — upstream або авторитарний DNS неправильні.

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

Task 8: Compare with another resolver to detect split DNS or resolver inconsistency

cr0x@server:~$ dig @10.20.0.54 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28490
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.internal.example.  60 IN A 10.70.8.42

Значення: Два корпоративні резолвери не погоджуються. Це не «DNS, який просто такий»; це зламана реплікація/форвардинг/кешування або неправильна конфігурація split‑horizon.

Рішення: Припиніть очищати клієнти. Виберіть тимчасово резолвер, який правильний, або відкотіться через порядок резолверів, і відкрийте інцидент для DNS‑команди.

Task 9: See if you’re dealing with negative caching (NXDOMAIN)

cr0x@server:~$ resolvectl query new-service.internal.example
new-service.internal.example: resolve call failed: 'new-service.internal.example' not found

Значення: NXDOMAIN (або еквівалент) може кешуватися. Якщо запис щойно створено, ваш шлях резолюції може відмовляти в існуванні запису деякий час.

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

Task 10: Inspect NSS order (is DNS even consulted?)

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

Значення: Система спочатку консультує /etc/hosts, потім mDNS, а потім DNS. Застарілий запис у /etc/hosts перекриє все інше.

Рішення: Якщо резолюція «неправильна, але послідовна», перевірте /etc/hosts. Очищення кешів не перезапише файл.

Task 11: Check for an override in `/etc/hosts`

cr0x@server:~$ grep -n 'api.internal.example' /etc/hosts
12:10.70.8.19 api.internal.example

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

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

Task 12: Confirm what glibc-based tools see (getent is your friend)

cr0x@server:~$ getent ahosts api.internal.example
10.70.8.19      STREAM api.internal.example
10.70.8.19      DGRAM
10.70.8.19      RAW

Значення: getent використовує NSS конфігурацію системи. Якщо getent збігається з resolvectl, шлях ОС узгоджений.

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

Task 13: Identify whether a local caching forwarder like dnsmasq is in play

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

Значення: dnsmasq не запущений як системний сервіс. Добре: на один шар кешу менше.

Рішення: Не перезапускайте dnsmasq «на всяк випадок». Якщо він неактивний — це не ваш кеш. Зосередьтесь в іншому місці.

Task 14: Check if `nscd` is caching host lookups

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

Значення: NSCD немає. Багато постів «як очистити DNS кеш на Linux» — артефакти епохи NSCD.

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

Task 15: Confirm which nameserver your tools actually query (127.0.0.53 vs direct)

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

Значення: Більшість інструментів, що залежать від libc, проходять через stub. Але dig може обходити його, якщо ви явно не вказали 127.0.0.53 або верхній резолвер.

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

Task 16: Query the stub resolver directly with dig

cr0x@server:~$ dig @127.0.0.53 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.internal.example.  287 IN A 10.70.8.19

Значення: Це поточне кеш‑представлення stub‑резолвера. Зменшення TTL підказує, що ви дивитесь на кешовані дані (це нормально).

Рішення: Якщо після очищення TTL скидається (або відповідь змінюється), ви довели, що кеш stub мав значення. Якщо нічого не змінюється — бреше upstream.

Task 17: Look for per-interface DNS that might be different under VPN

cr0x@server:~$ resolvectl dns
Global: 10.20.0.53 10.20.0.54
Link 2 (ens3): 10.20.0.53 10.20.0.54
Link 3 (tun0): 172.16.100.1

Значення: VPN‑інтерфейс tun0 має власний DNS‑сервер. Залежно від правил маршрутизації, запити можуть йти туди.

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

Task 18: Check if you have a routing/domain search rule that changes resolution

cr0x@server:~$ resolvectl domain
Global: corp.example
Link 2 (ens3): corp.example
Link 3 (tun0): ~internal.example

Значення: Префікс ~ позначає домен тільки для маршрутизації (split DNS). Запити для internal.example йдуть до VPN‑резолвера, інші — ні.

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

Жарт #2: Очищати неправильний кеш — це оперна версія «вимкнути монітор, щоб вирішити дедлок у базі даних».

Три корпоративні міні‑історії з полів DNS

Міні‑історія 1: Інцидент через неправильне припущення (капкан «dig — це істина»)

Середня SaaS‑компанія проводила поетапну міграцію внутрішнього API з одного VPC в інший. План був простий: заздалегідь зменшити TTL, оновити A‑записи у вікні обслуговування, моніторити помилки й при потребі повернути назад. Команда тестувала резолюцію за допомогою dig з bastion‑хоста, бачила нову IP‑адресу і оголошувала DNS «готовим».

Через тридцять хвилин робочі флотилії почали падати на перевірках живості. Помилка не була «NXDOMAIN» або «не вдалося розв’язати хост». Це були тайм‑аути з’єднань. На виклику шукали проблеми в security groups, NAT‑шлюзах і балансувальниках. Все виглядало добре. Тим часом dig усе ще показував правильну нову адресу. Впевненість була помилкова.

У чому була загвоздка: їхні воркери були написані на Go та використовували конфігурацію резолвера, яка обходила локальний stub і мала власну поведінку кешування. На уражених Ubuntu 24.04 вузлах systemd-resolved був правильний, але Go‑процеси тримали старі відповіді довше, ніж команда очікувала, через власні патерни кешування і повторного використання з’єднань. Деякі процеси навіть не виконували нові запити, бо keepalive‑з’єднання залишалися прив’язаними до мертвих кінцевих точок.

Вирішення прийшло від зміни процедури розгортання, а не від «сильнішого очищення». Додали контрольований рестарт процесів після зміни DNS для цього класу сервісів і валідували резолюцію тим самим шляхом, яким користувались воркери (невеликий діагностичний бінарник). Також припинили вважати «dig на bastion» джерелом істини.

Урок запам’ятався: резолвер, яким ви тестуєте, має збігатися з резолвером, який використовує навантаження. Інакше ви вимірюєте інше і називаєте це валідацією.

Міні‑історія 2: Оптимізація, яка дала протилежний ефект (історія локального кешуючого форвардера)

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

Це працювало — допоки не перестало. Під час ротації сертифікатів і переміщення сервісу за новий VIP ім’я сервісу залишилось, а IP змінився. Авторитарний DNS і корпоративні резолвери вели себе правильно. Але build‑агенти продовжували пробувати старий IP набагато довше за TTL. Деякі відновлювалися через деякий час, деякі — ні, а збої були дивно «липкими» на рівні машини.

Корінь проблеми не був у «багу dnsmasq». Це був дрейф конфігурацій: деякі агенти мали різні розміри кешу і політику TTL, а кілька мали дві локальні верстви резолвера (dnsmasq попереду systemd‑resolved) через еволюцію образів. Результат — непослідовна семантика кешування і невивідні варіації. Інженери почали випадково перезапускати мережеві сервіси, що іноді допомагало і частіше марнувало час.

Виправлення було нудним і ефективним: прибрали dnsmasq з більшості агентів, залишили його тільки там, де split DNS реально потрібен, і поклалися на стабільні upstream‑резолвери, призначені для кешування в масштабі. Для небагатьох випадків, що потребували локального форвардингу, стандартизували конфіги і додали просту перевірку «яким резолвером я користуюся» у пайплайн надання образів.

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

Міні‑історія 3: Нудна, але правильна практика, що врятувала ситуацію (дисципліна TTL і поетапна верифікація)

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

Перед будь‑яким плановим переміщенням вони знижували TTL за 24 години наперед. Не до «5 секунд» — до значення, яке їхні резолвери і клієнти реально шанують без спричинення хвилі запитів. Вони також мали стандартну послідовність перевірок: опитати авторитарний, опитати кожен корпоративний рекурсивний резолвер, потім опитати репрезентативного клієнта через stub. Лише після збігу цих відповідей вони перемикали трафік.

Під час одного інциденту відбувся відкат без проблем, але підмножина клієнтів усе ще потрапляла на стару ціль. Рукбук пришвидшив розслідування: авторитарний був вірний, один корпоративний рекурсор давав застарілі дані. Оскільки в них вже був список резолверів і стандартний набір запитів, вони виділили поганий резолвер, тимчасово видалили його з DHCP‑сфери і відновили сервіс, поки DNS‑команда лагодила резолвер.

Геройських вчинків не було. Ніхто не знайшов «магічну команду для очищення». Було просто доказове, впорядковане діяння і заздалегідь погоджений план. Ось що їх врятувало.

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

1) Симптом: «`dig` показує нову IP, але додаток все ще звертається до старої»

Корінь проблеми: Різні шляхи резолюції або кешування/повторне використання з’єднань на рівні додатка. dig — не ваш додаток.

Виправлення: Підтвердіть за допомогою getent ahosts (glibc‑шлях) і поведінки DNS у рантаймі програми. Розгляньте рестарт сервісу після змін DNS, якщо рантайм кешує або тримає з’єднання.

2) Симптом: «Очищення локального DNS нічого не дає»

Корінь проблеми: Неправильний кеш. Верхній рекурсивний резолвер видає застарілі дані або ім’я прив’язано в /etc/hosts.

Виправлення: Опитайте верхні резолвери напряму через dig @server. Перевірте /etc/hosts. Ескалюйте до власників upstream, якщо потрібно.

3) Симптом: «Працює по Ethernet, не працює по VPN (або навпаки)»

Корінь проблеми: Split DNS і правила резолвера по інтерфейсу. Різні домени маршрутизуються до різних резолверів, іноді несподівано.

Виправлення: Інспектуйте resolvectl dns і resolvectl domain. Виправте routing‑only домени і налаштування DNS, які пушить VPN, замість очищення кешів.

4) Симптом: «Новий хостнейм повертає NXDOMAIN кілька хвилин після створення»

Корінь проблеми: Негативне кешування на якомусь шарі резолюції.

Виправлення: Очистіть кеші там, де повертається NXDOMAIN (systemd-resolved, dnsmasq, upstream‑резолвери). Підтвердіть, що авторитарний сервіс має запис.

5) Симптом: «Випадкові клієнти падають, інші в порядку»

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

Виправлення: Опитайте кожен налаштований резолвер напряму і порівняйте. Стандартизujte конфігурацію резолверів і видаліть зайві шари кешування, якщо вони не вирішують реальної проблеми.

6) Симптом: «Хостнейм резольвиться в IPv6 і з’єднання падають; IPv4 працює»

Корінь проблеми: Існують AAAA‑записи, але шлях для IPv6 зламаний або фільтрується; поведінка Happy Eyeballs відрізняється в залежності від програми.

Виправлення: Опитайте AAAA і A окремо, перевірте маршрутизацію IPv6 або тимчасово відкоригуйте записи/політику. Не вважайте це проблемою кешу, доки не доведете, що так.

7) Симптом: «Після зміни DNS‑серверів машина все ще опитує старі»

Корінь проблеми: Застаріла пер‑інтерфейсна конфігурація, VPN пушить налаштування або статичний /etc/resolv.conf перекриває зміни.

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

Чеклісти / покроковий план (робіть це, а не відчуття)

Чекліст A: «DNS‑зміна щойно сталася, деякі клієнти помиляються»

На ураженому клієнті: зніміть вигляд ОС за допомогою resolvectl query name.
Зніміть вигляд upstream: dig @current_upstream name +noall +answer +comments.
Порівняйте з відповіддю другого upstream‑резолвера, якщо він є.
Якщо upstream різняться: трактуйте як непослідовність резолверів. Ескалюйте і/або тимчасово виведіть з обігу поганий резолвер.
Якщо upstream збігаються, але неправильні: опитайте авторитарні сервери (з місця, звідки можна до них достукатися) і виправте DNS‑дані.
Якщо ОС правильний, а додаток неправильний: перевірте резолвер програми і кеші; перезапустіть/перезавантажте сервіс, якщо доречно.

Чекліст B: «Припиніть очищати неправильний кеш»

Перевірте ls -l /etc/resolv.conf. Якщо воно вказує на systemd‑stub, ви в systemd-resolved світі.
Перевірте systemctl is-active systemd-resolved. Якщо він неактивний, його очищення — плацебо.
Перевірте додаткові шари: systemctl is-active dnsmasq, systemctl is-active nscd.
Використовуйте getent ahosts як базовий орієнтир для того, що бачать програми, що залежать від libc.

Чекліст C: «Планована міграція з DNS‑фліпами»

Зменшіть TTL заздалегідь (години до доби, залежно від кешуючої поведінки вашого середовища).
Задокументуйте, які резолвери використовуються (DHCP‑сфери, профілі VPN, датасентрові рекурсори).
Під час вікна перевіряйте в такому порядку:
1. Авторитарна відповідь — правильна.
2. Кожен рекурсивний резолвер дає правильну відповідь і TTL адекватний.
3. Репрезентативні клієнти через stub дають правильну відповідь.
4. Додатки резольвлять коректно через реальний шлях резолюції.
Майте план відкату, який не залежить від «очищення кешів у людей». Якщо ваш план відкату — людське інвалювання кешів, це не план.

FAQ

1) Який «правильний» DNS‑кеш очищувати в Ubuntu 24.04?

Зазвичай: systemd-resolved. Використовуйте sudo resolvectl flush-caches, потім перевірте з resolvectl query.

2) Чому «restart networking» іноді фіксує DNS?

Бо це може перезапустити або переконфігурувати стек резолверів (інтерфейси, DNS‑сервери, search‑домени). Це грубий інструмент, який може спричинити нові збої. Віддавайте перевагу цільовим перевіркам через resolvectl status.

3) Чому `dig` показує одну відповідь, а `getent` іншу?

dig опитує DNS‑сервер, який ви йому скажете (або дефолтний, залежно від запуску). getent слідує NSS і часто використовує локальний stub. Вони не рівнозначні, якщо ви не вкажете їм один і той самий резолвер.

4) Чи кешує Ubuntu 24.04 DNS у glibc?

glibc сама по собі не надає загальноцільового DNS‑кешу як демон. Кеш зазвичай роблять systemd-resolved, dnsmasq, nscd або всередині додатків.

5) Як дізнатися, чи `/etc/hosts` перекриває DNS?

Перевірте /etc/nsswitch.conf на порядок для hosts:, потім пошукайте хост у /etc/hosts. Якщо він там є — DNS не має значення, поки ви не виправите файл.

6) А що з кешем DNS у браузерах на Ubuntu?

Браузери часто кешують DNS і можуть використовувати власний резолвер або DoH. Якщо інструменти ОС показують правильну відповідь, а браузер — ні, очистіть кеш браузера або вимкніть/сконфігуруйте DoH.

7) Що робити, якщо я очистив `systemd-resolved`, а відповідь все ще неправильна?

Тоді неправильна відповідь походить від upstream або авторитарного DNS, або ви не використовуєте systemd-resolved для цього шляху запиту. Доведіть поведінку upstream за допомогою dig @upstream і перевірте пер‑інтерфейсні DNS через resolvectl status.

8) Чи може VPN split DNS спричиняти симптоми «DNS‑кешу»?

Так. Це може виглядати як кеш, бо відповіді відрізняються залежно від інтерфейсу й routing‑domain. Використайте resolvectl domain і resolvectl dns, щоб побачити, куди йдуть запити.

9) Чи варто відключати `systemd-resolved`, щоб зробити DNS «простішим»?

Зазвичай ні. Вимкнення може погіршити VPN і пер‑інтерфейсний DNS, а не покращити. Якщо вам потрібна інша архітектура резолвера (наприклад, локальний Unbound), робіть це свідомо і задокументуйте. «Просто» не буде простим, якщо ніхто не знає, що працює.

10) Який найбезпечніший спосіб валідувати зміну DNS?

Опитайте авторитарний, потім кожен рекурсивний резолвер, потім репрезентативних клієнтів їхнім реальним шляхом резолюції. Якщо будь‑який шар не погоджується — вважайте його джерелом інциденту, поки не доведете інше.

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

Припиніть ставитися до очищення DNS як до духовного очищення. На Ubuntu 24.04 найпоширеніший кеш, що має значення — це systemd-resolved, а найпоширеніший режим відмови — очищення його тоді, коли бреше upstream, або коли додаток взагалі не питав його.

Зробіть ось що:

Уніфікуйте стек резолвера в образах ваших флотилій (і видаліть зайві шари кешування, якщо ви не можете їх обґрунтувати).
Навчіть команду користуватися resolvectl status, resolvectl query і getent ahosts як базовими джерелами доказів.
Для кожного інциденту з DNS фіксуйте: stub‑відповідь клієнта, відповідь upstream‑резолвера і чи використовує додаток шлях ОС‑резолюції.
Для планованих міграцій складіть рукбук, що верифікує авторитарний → рекурсивний → клієнтський шар і містить план відкату, що не залежить від «очищення людських мозків».

Схожі статті

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