DNS-резолвери: чому кешування погіршує відмови (і як їх приборкати)

Хто насправді кешує DNS (спойлер: усі)

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

Шари, які кешують відповіді DNS

• Кеші на рівні застосунку: браузери, JVM-резолвери, рантайми мов та бібліотеки, які «допомагають» запам’ятовувати відповіді.
• OS stub resolver: той компонент, до якого звертається ваше застосування. Він може кешувати (залежно від платформи й конфігурації).
• Локальний демпон кешування: systemd-resolved, dnsmasq, nscd, Unbound у «локальному» режимі тощо.
• Кеші на вузлі / сайдкари: поширені в Kubernetes і сервіс-мешах для зменшення затримок і навантаження.
• Рекурсивні резолвери: резолвери ISP, корпоративні резолвери, публічні резолвери. Це великі, спільні кеші.
• Форвардери: корпоративні мережі часто ланцюжать резолвери (філія → HQ → upstream).
• Авторитетні сервери: не «кеші», але вони впливають на кешування через TTL, значення SOA та поведінку відповідей.
• Проміжні пристрої: так, деякі «засоби безпеки» маніпулюють DNS і кешують відповіді. Пакети мовчать у суді.

Коли хтось каже «TTL — 60 секунд», варто відповісти: «На якому шарі, у якому режимі відмови й з яким софтом резолвера?»
Правильна відповідь зазвичай супроводжується довгим зітханням.

Чому кешування посилює відмови

Кешування DNS — це множник. Воно примножує надійність, коли відповіді вірні й стабільні. Воно примножує біль, коли відповідь неправильна,
відсутня або тимчасово недоступна. Суть у тому, що кеші роблять вашу систему станом, який зберігається по інтернету. Ви можете відкотити код за хвилини;
ви не можете відкотити cached NXDOMAIN у рекурсивних резолверах, якими не керуєте.

Режим відмови №1: неправильні відповіді зберігаються

Опублікуйте неправильний A-запис (помилка в IP, застаріла кінцева точка, неправильний регіон) — і ви створите розподілений «токен відмови».
Кожний рекурсивний резолвер, який його побачить, може тримати його до закінчення TTL. Ваше виправлення може бути миттєвим на авторитетному рівні,
але світ уже працює на основі кешованого стану.

Режим відмови №2: таймаути та SERVFAIL стають «липкими»

Деякі резолвери кешують помилки або принаймні поводяться так, ніби кешують, обмежуючи повторні запити, позначаючи сервери як «lame» або віддаючи перевагу
одному NS через попередню затримку. Під час авторитетного інциденту рекурсори можуть вирішити, що один із ваших name server-ів «поганий» і уникати його
значно довше, ніж він був недоступний.

Режим відмови №3: негативне кешування робить відновлення повільнішим за саму відмову

Видаліть запис (або він зник через помилковий деплой) — і резолвери можуть закешувати «не існує» (NXDOMAIN) відповідно до SOA зони.
Цей негативний TTL може становити хвилини або години. Тож навіть після відновлення запису клієнти продовжують вірити в порожнечу.

Жарт №1: DNS нагадує плітку: коли її закешували, виправлення ніколи не поширюється так швидко, як скандал.

Режим відмови №4: навантажувальні сплески від масових пропусків кешу

Коли TTL популярного запису одночасно закінчується у великої кількості резолверів, ви отримуєте сплеск пропусків кешу. Якщо авторитетні сервери вже
під навантаженням, цей сплеск може перевести їх зі стану «повільно» в «вниз», створюючи ще більше пропусків і ще більше сплесків. Це петля зворотного зв’язку.
Деякий софт резолверів має механізми prefetch і serve-stale, щоб зменшити це, але ці опції мають гострі кути.

TTL не обіцянка: брудні реалії

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

Поширені способи, як TTL «підправляють» на практиці

• Застосування мінімального TTL: деякі корпоративні й публічні резолвери вводять мінімум (з міркувань продуктивності й захисту від зловживань).
• Застосування максимального TTL: деякі накладають верхню межу (щоб записи не кешувалися днями).
• Локальні кеші ігнорують низькі TTL: певні stub-резолвери й застосунки зберігають відповіді довше за TTL.
• Перевикористання з’єднань і пулінг застосунків: застосунки можуть резолвити лише під час старту, фактично створюючи нескінченний TTL до перезапуску.
• Happy Eyeballs і логіка fallback: клієнти можуть обирати сімейство адрес (A проти AAAA) і дотримуватися його навіть після змін DNS.
• Пам’ять вибору серверів резолвера: рекурсивні резолвери відстежують, які авторитетні сервери відповідали, і віддають їм перевагу.

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

Одна корисна настановa, яку варто тримати на стікері, — перефразована думка, приписувана Вернеру Фогельсу: Усе ламається постійно; проектуйте відповідно.
Це не цитата про DNS, але саме DNS часто перевіряє цю філософію на практиці.

Негативне кешування: коли «не знайдено» застрягає

Кешування NXDOMAIN — найменш оцінений фактор, що подовжує відмови. Ви думаєте «ми відновили запис». Ваші клієнти продовжують отримувати «хост не знайдено».
Чому? Тому що «не знайдено» можна кешувати.

Як працює негативне кешування

Коли резолвер отримує NXDOMAIN (ім’я не існує) або NODATA (ім’я є, але не того типу), він може закешувати негативну відповідь.
TTL для цього кешу походить із SOA-запису зони, зокрема з поля SOA MINIMUM (історично) та/або з інтерпретації SOA у сучасних стандартах і реалізаціях.
Операційно: налаштування SOA важливі навіть якщо ви нічого не робите з SOA.

Дві практичні наслідки

• Короткочасний відсутній запис може затриматися. Якщо ваш деплой випадково прибирає A-запис на 30 секунд, резолвери можуть запам’ятати цю
  відсутність на хвилини або довше.
• Нові записи «поширюються» повільно, якщо клієнти питали зарано. Запуск нового піддомену та анонсування його до фактичного створення — класична
  «пістолет-стрілку»: ранні запити сіють негативні кеші.

Виправлення не в «ставте все на TTL 0». Виправлення — контролювати негативні TTL, планувати cutover-и і використовувати техніки busting кешу, коли це потрібно.

Стек резолверів у реальному світі (Linux, macOS, Windows, контейнери)

Фраза «перевірте /etc/resolv.conf» — SRE-еквівалент «ви пробували вимкнути та ввімкнути знову». Вона не хибна; вона просто неповна.
Сучасні системи можуть спрямовувати DNS через локальний stub (127.0.0.53), плагін VPN, корпоративний агент або рантайм контейнера.

Linux: systemd-resolved та інші

Багато дистрибутивів використовують systemd-resolved, який може кешувати і реалізовувати split DNS для VPN. /etc/resolv.conf може вказувати на 127.0.0.53,
що не є вашим реальним резолвером; це локальний stub, який форвардить запити вгору. Під час налагодження потрібно перевіряти як stub, так і upstream-конфігурацію.

macOS: mDNSResponder і DNS на інтерфейс

macOS зберігає налаштування DNS для кожного інтерфейсу. Ви можете бути «на тому самому Wi‑Fi» й водночас мати різну поведінку резолвера, бо одна машина має профіль VPN.
Очищення кешу допомагає, але важливіше підтвердити, які резолвери фактично запитуються.

Windows: служба DNS Client і NRPT

Windows кешує DNS у службі DNS Client. У підприємствах також використовують правила Name Resolution Policy Table (NRPT), особливо з DirectAccess/VPN,
які можуть направляти певні домени до конкретних резолверів. Налагодження вимагає перегляду політик, а не тільки кешу.

Контейнери і Kubernetes: CoreDNS плюс ще шар

Kubernetes додає щонайменше один шар: CoreDNS (або kube-dns), плюс резолвер вузла, плюс те, що робить образ контейнера. Деякі кластери додають NodeLocal
DNSCache, щоб зменшити навантаження на CoreDNS і затримки. Це покращує steady-state продуктивність і робить деякі відмови гіршими, бо застарілі відповіді
зберігаються ближче до робочих навантажень. Ви міняєте навантаження на стійкість. Ця компроміс може бути виправданим, але його треба вимірювати.

Цікавинки та історичний контекст (те, що кусає пізніше)

1. DNS замінив HOSTS.TXT, бо центральний файл не масштабується; кешування було функцією від самого початку, а не доповненням.
2. TTL створювався, щоб контролювати навантаження на авторитетні сервери; він не призначався для швидкого failover.
3. Негативне кешування колись було непослідовним; стандартизація еволюціонувала через хаотичну поведінку ранніх резолверів для NXDOMAIN.
4. Резолвери відстежують «lame» name server-и і уникають їх; це добре… поки тимчасова втрата пакетів не позначить ваш найкращий NS як «поганий».
5. Декотрі резолвери обмежують TTL (мінімум і максимум) з політичних причин, що робить «розрахунки поширення» ненадійними.
6. Glue-записи можуть тримати вас у пастці: кешована делегація плюс glue може змушувати клієнтів йти до старих IP NS навіть після виправлення зони.
7. DNSSEC ускладнює режими відмови: зломаний ланцюг довіри може перетворити «працює у мене» на SERVFAIL глобально, додаючи шар кешування зверху.
8. EDNS0 і більші UDP-повідомлення покращили функціональність, але підвищили чутливість до проміжних пристроїв, що відкидають фрагменти або блокують EDNS.
9. Fallback на TCP для DNS існує не просто так; якщо шлях блокує DNS через TCP, великі відповіді можуть періодично відмовляти.

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

Міні-історія №1: Відмова через неправильне припущення

Середня SaaS-компанія планувала «прості» міграції API з одного балансувальника на інший. План: знизити TTL до 60 секунд, перемкнути A-запис,
моніторити, потім підвищити TTL назад. Першу частину виконали ретельно. Дочекалися день. Перемкнули у тихий вікно. І потім з’явилися звернення в підтримку.

Деякі клієнти продовжували підключатися до старого IP годинами. Команда on-call звинуватили «пропагацію DNS у ISP». Мережна команда звинуватила клієнта.
Застосункова команда звинуватила мережну — як це часто буває, коли люди налякані.

Справжня проблема була вражаюче буденною: популярна інтеграція клієнта писалася на Java, і поведінка кешування DNS рантайму на тих машинах була фактично
«кешувати назавжди», якщо не налаштовано інакше. Ці клієнти резолвили один раз при старті й закріпили IP. Зниження TTL нічого не дало, бо застосунок не
перевіряв DNS повторно.

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

Міні-історія №2: Оптимізація, що обернулася проблемою

Інша компанія мала навантаження на CoreDNS. Сплески затримок, час від часу таймаути і постійні скарги розробників, які вважали, що DNS має бути невидимим.
Команда платформи додала node-local DNS кеш, щоб зменшити QPS на CoreDNS. Це спрацювало. Графіки покращилися. Команда тихо пораділа, як інженери, що бояться долі.

Через тижні авторитетний провайдер мав часткову відмову. Правильною поведінкою було б «деякі запити швидко падають, повтори відновлюють, і як тільки upstream зцілиться — усе повернеться до нормального».
Натомість стався повільний інцидент: node-local кеші тримали застарілі помилки й непостійні відповіді достатньо довго, що поди по кластеру бачили непослідовне резолвлення значно довше, ніж тривав upstream downtime.

Node-local кеш також змінив поверхню відмов кластера. Раніше проблеми CoreDNS були централізовані й очевидні. Після цього відмови стали вузловими. Деякі вузли були «в порядку», інші — «прокляті», і scheduler охоче розміщував робочі навантаження на проклятих вузлах, бо там був доступний CPU.

Висновок постмортему не був «ніколи не кешувати». Він був «кешувати з явною політикою serve-stale, явним моніторингом і способом швидко очистити або обійти кеш».
Вони додали health checks, метрики для кожного node-local екземпляра і аварійний DaemonSet, який міг рестартувати кеші по всьому кластеру. Оптимізація — чудова, поки вона не стане тим, що неможливо розгорнути під час інциденту.

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

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

Одного дня моніторинг сповістив: запити до одного провайдера почали час від часу повертати SERVFAIL для підписаної зони. З більшості клієнтських мереж усе ще виглядало добре, бо кеші ховали проблему.
Компанія не отримала скарг, бо відмова була молода й замаскована.

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

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

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

Коли звинувачують DNS, ваше завдання — зрозуміти, де в систему потрапила помилка: авторитетні дані, рекурсивне кешування, локальний кеш чи застосунок.
У вас немає часу на філософію. Ось порядок, який швидко виведе вас до кореневої причини.

Перший крок: визначити, чи ім’я невірне повсюди або лише для деяких клієнтів

• Перевірте авторитетні сервери напряму (запитайте авторитетні NS по імені/IP, оминаючи рекурсори).
• Перевірте один-два публічні рекурсори, щоб побачити, чи відрізняється кешований вигляд.
• Перевірте шлях резолвера на ураженому клієнті (якому серверу він фактично ставить питання?).

Другий крок: класифікуйте тип відмови

• Неправильний IP: застарілий кешований запис або неправильна публікація.
• NXDOMAIN: відсутній запис і негативне кешування.
• SERVFAIL: DNSSEC, зламана делегація, недоступний авторитетний сервер або політика резолвера.
• Таймаут: мережевий шлях, MTU/фрагментація, фаєрвол або перевантажений компонент DNS.
• Переривчасто: зміни в авторитетних відповідях, проблеми anycast-шляху, втрата пакетів або один NS «lame».

Третій крок: знайдіть шар кешування, що «липне»

• Локальний stub-кеш (systemd-resolved, nscd, dnsmasq).
• Кеш на вузлі / CoreDNS (Kubernetes).
• Корпоративні форвардери (ланцюги додають стан).
• Рекурсивні резолвери (ISP/публічні).
• Рантайм застосунку (JVM, Go, власне кешування).

Четвертий крок: вирішіть — чекати, очистити чи обійти

• Чекати, якщо кешована величина правильна, але потрібно час, щоб зійтися; повідомте очікуваний час відновлення з урахуванням TTL і поведінки кешів.
• Очистити, якщо ви контролюєте резолвер і можете зробити це безпечно (і якщо не спричините штампедо).
• Обійти, тимчасово додавши альтернативні записи, змінивши делегацію або використавши інше ім’я хоста під час інциденту.

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

Це не «іграшкові» команди. Це ті, які ви запускаєте, поки хтось питає ETA. Кожне завдання містить, що означає вивід і яке рішення далі приймати. Припускаємо Linux, якщо не зазначено інше.

Завдання 1: Визначити, яким резолвером хост фактично користується

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

Що це означає: Цей хост вказує на локальний stub (127.0.0.53), ймовірно systemd-resolved.
Рішення: Не робіть висновків про upstream ще; спершу перевірте конфігурацію systemd-resolved і поведінку кешу.

Завдання 2: Перевірити upstream-сервери 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

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Що це означає: systemd-resolved форвардить на 10.10.0.53/54.
Рішення: Якщо лише деякі хости падають, порівняйте цей вивід на «хороших» і «поганих» машинках. Різниця часто пояснює усе.

Завдання 3: Запитати ім’я через дефолтний резолвер і подивитися TTL

cr0x@server:~$ dig api.example.com A +noall +answer +ttlid
api.example.com.  42  IN  A  203.0.113.20

Що це означає: Ви отримали відповідь з 42 секундами, що залишилися в кеші.
Рішення: Якщо IP неправильний, ви дивитесь на кешований стан. Далі: порівняйте з авторитетним і іншими рекурсорами.

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

cr0x@server:~$ dig @1.1.1.1 api.example.com A +noall +answer +ttlid
api.example.com.  60  IN  A  198.51.100.77

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

Завдання 5: Запитати авторитетні name server-и напряму (щоб обійти рекурсію)

cr0x@server:~$ dig api.example.com A +noall +answer +authority +additional +trace
api.example.com. 300 IN A 198.51.100.77

Що це означає: Авторитетні сервери кажуть 198.51.100.77 з TTL 300.
Рішення: Резолвер, який повертає 203.0.113.20, застарів або використовує інший вигляд зони (split-horizon, старий зоновий файл або неправильний форвардинг).

Завдання 6: Перевірити NXDOMAIN і чи кешується він негативно

cr0x@server:~$ dig new.api.example.com A +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1443
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

example.com.  900  IN  SOA  ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 900

Що це означає: NXDOMAIN, і SOA показує 900 секунд негативного кешування (часто походить з SOA MINIMUM).
Рішення: Якщо ви щойно створили цей запис, можливо доведеться чекати завершення негативного кешу або змінити стратегію (тимчасове інше ім’я або попереднє створення перед анонсом).

Завдання 7: Підтвердити, чи DNSSEC перетворює помилки в SERVFAIL

cr0x@server:~$ dig api.example.com A +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39012
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: Резолвер віддав SERVFAIL. Часто це виглядає як помилка валідації DNSSEC, але так само може проявлятися при таймаутах.
Рішення: Порівняйте результати з резолвером, у якого валідація DNSSEC відключена (у контрольованому середовищі), і запросіть авторитетні DNSKEY/DS для перевірки коректності.

Завдання 8: Виміряти досяжність і затримку авторитетних серверів з вашої мережі

cr0x@server:~$ dig @ns1.example.com api.example.com A +tries=1 +time=1 +stats
api.example.com. 300 IN A 198.51.100.77
;; Query time: 18 msec
;; SERVER: 192.0.2.53#53(ns1.example.com) (UDP)
;; WHEN: Tue Feb 04 12:02:51 UTC 2026
;; MSG SIZE  rcvd: 56

Що це означає: Авторитетно відповідає швидко звідси.
Рішення: Якщо клієнти в інших місцях таймаутять, можливо проблеми географічного маршруту/anycast, фаєрволу або вибору upstream резолверів.

Завдання 9: Виявити проблеми MTU/фрагментації, що впливають на DNS (розмір EDNS0)

cr0x@server:~$ dig dnskey example.com +dnssec +bufsize=4096 +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58807
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: Великі UDP-відповіді працюють звідси. Якщо це не вдається десь ще, але працює з меншим bufsize або через TCP, у вас проблема шляху або проміжного пристрою.
Рішення: Тестуйте з TCP і/або з меншим bufsize; якщо TCP працює, але великий UDP — ні, залучайте мережні команди для захоплення пакетів і перевірки MTU.

Завдання 10: Примусити DNS через TCP, щоб підтвердити проблему UDP

cr0x@server:~$ dig dnskey example.com +dnssec +tcp +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4926
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: TCP успішний. Якщо UDP періодично відмовляє, ймовірно падіння фрагментів UDP, ліміти швидкості або дивна поведінка stateful фаєрволу.
Рішення: Налаштуйте розмір EDNS, перевірте правила фаєрволу і зверніться до авторитетного провайдера; не «виправляйте» це підвищенням TTL.

Завдання 11: Переглянути статистику кешу Unbound (локальний резолвер)

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'total.num.queries|total.num.cachehits|total.num.cachemiss|unwanted'
total.num.queries=184392
total.num.cachehits=151004
total.num.cachemiss=33388
unwanted.queries=219

Що це означає: Відношення cache hit високе; Unbound виконує роботу. «unwanted» може вказувати на відкинуті запити (політика, ліміти або інші проблеми).
Рішення: Якщо під час інциденту кількість cache miss зростає, ви можете бачити stampede; розгляньте prefetch/serve-stale політику і потужність авторитетних серверів.

Завдання 12: Очищення одного імені в Unbound (коли ви контролюєте резолвер)

cr0x@server:~$ sudo unbound-control flush api.example.com
ok

Що це означає: Це ім’я видалено з кешу на цьому резолвері.
Рішення: Повторно запитайте, щоб підтвердити, що тепер використовується авторитетна відповідь. Будьте обережні: масове очищення може спричинити сплеск cache-miss.

Завдання 13: Перевірити поведінку BIND щодо рекурсії та кешу

cr0x@server:~$ sudo rndc status
version: BIND 9.18.18 (Stable Release)
running on server: Linux x86_64
boot time: Tue Feb 04 09:11:03 UTC 2026
last configured: Tue Feb 04 09:12:01 UTC 2026
current serial: 2026020401
number of zones: 104 (104 automatic)
recursive clients: 12/1000/1000
tcp clients: 3/100
server is up and running

Що це означає: Резолвер працює, не перевантажений клієнтами.
Рішення: Якщо клієнти все ще падають, перевірте логи запитів на SERVFAIL/таймаути і підтвердіть доступність upstream і стан валідації DNSSEC.

Завдання 14: Перевірити, чи CoreDNS у Kubernetes помиляється або працює повільно

cr0x@server:~$ kubectl -n kube-system logs -l k8s-app=kube-dns --tail=20
[INFO] 10.244.1.18:39976 - 56512 "A IN api.example.com. udp 44 false 512" SERVFAIL qr,rd,ra 44 0.002153s
[INFO] 10.244.2.21:34771 - 22341 "A IN api.example.com. udp 44 false 512" NOERROR qr,rd,ra 60 0.001122s

Що це означає: Змішане SERVFAIL/NOERROR свідчить про upstream або непостійні проблеми валідації/досяжності, а не просту «відсутність запису».
Рішення: З’ясуйте, до яких upstream CoreDNS форвардить, і протестуйте цей резолвер напряму з мережевого неймспейсу вузла.

Завдання 15: Підтвердити, чи застосунок перевіряє DNS повторно або закріплює його

cr0x@server:~$ sudo strace -f -e trace=network -p 24817 2>&1 | head
connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("203.0.113.20")}, 16) = 0

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

Завдання 16: Переглянути живі сокети, щоб помітити використання застарілого IP

cr0x@server:~$ ss -ntp | egrep ':443' | head
ESTAB 0 0 10.0.5.12:53014 203.0.113.20:443 users:(("myclient",pid=24817,fd=12))

Що це означає: Активні з’єднання йдуть на 203.0.113.20.
Рішення: Якщо авторитетний зараз вказує в інше місце, у вас є закріплені з’єднання або застарілий DNS на якомусь шарі. Вирішіть, чи відключати, перезапускати чи додати тимчасовий маршрут.

Жарт №2: Очищення DNS-кешів під час інциденту схоже на переставляння стільців на поромі — іноді допомагає, але краще знати, що саме тече.

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

1) «Авторитетні дані правильні, але користувачі все ще потрапляють на старий IP»

Симптом: Деякі клієнти продовжують підключатися до старих кінцевих точок довго після зміни DNS.

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

Виправлення: Плануйте cutover з накладенням (тримайте стару кінцеву точку живою), заздалегідь скоротіть TTL, і перевірте поведінку DNS у рантаймі клієнтів. Надавайте альтернативні імена для переходу.

2) «NXDOMAIN триває після додавання запису»

Симптом: Новий піддомен не працює хвилинами/годинами; деякі мережі резолвлять, інші — ні.

Причина: Негативне кешування за SOA; ранні запити засіяли NXDOMAIN-кеші.

Виправлення: Заздалегідь створюйте записи перед анонсом. Налаштуйте адекватний негативний TTL у SOA. Для термінових випадків використайте нове ім’я (bust кеш), а не чекайте на закінчення NXDOMAIN.

3) «Переривчастий SERVFAIL на одному резолвері, інший — в порядку»

Симптом: Деякі резолвери повертають SERVFAIL; інші — NOERROR.

Причина: Помилка валідації DNSSEC, зламана пара DS/DNSKEY або переривчаста доступність авторитетних серверів (один NS недоступний).

Виправлення: Перевірте ланцюг DNSSEC end-to-end і підтвердьте, що всі авторитетні сервери відповідають послідовно. Якщо один NS проблемний — видаліть або виправте його; часткова авторитетність гірша за меншу кількість працездатних серверів.

4) «Таймаути тільки для великих відповідей»

Симптом: A/AAAA-запити в основному в порядку, але DNSKEY/TXT або деякі відповіді таймаутять.

Причина: Проблеми EDNS0/фрагментації, невідповідність MTU, проміжні пристрої, що відкидають UDP-фрагменти або блокують fallback на TCP.

Виправлення: Тестуйте з +tcp і налаштуйте EDNS buffer size. Виправте мережевий шлях. Не прикривайте це зменшенням розміру відповідей, поки не розумієте компроміс.

5) «Сюрпризи split-horizon після додавання VPN»

Симптом: Внутрішні імена резолвляться неправильно зовні або навпаки; лише користувачі VPN падають.

Причина: Політики per-domain forwarding/split DNS; резолвери різні по інтерфейсу; корпоративні агенти переопреділяють резолвери.

Виправлення: Документуйте домени зі split-horizon, уніфікуйте налаштування резолверів і тестуйте з VPN і без нього. Переконайтесь, що внутрішні зони не витікають, а зовнішні зони доступні.

6) «Зниження TTL не допомогло нашому failover»

Симптом: Ви зменшили TTL до 30–60 секунд, але failover усе одно займав багато часу.

Причина: Деякі резолвери застосовують мінімальні TTL; деякі клієнти закріплюють DNS; кеші могли вже містити старі значення до зміни TTL.

Виправлення: Знижуйте TTL заздалегідь, за кілька днів до планованих змін. Тестуйте на реальних клієнтських популяціях. Використовуйте retry-логіку й підтримку кількох кінцевих точок у застосунку; DNS сам по собі — не система failover.

7) «Ми почистили кеш і зробили гірше»

Симптом: Після очищення резолверів QPS на авторитетні сервери виросла, і більше запитів таймаутить.

Причина: Cache stampede: ви перетворили флот резолверів у синхронізований генератор промахів.

Виправлення: Очищайте прицільно (одне ім’я, один рівень резолверів), розтягайте рестарти й переконайтеся в потужності авторитетних серверів. Віддавайте перевагу політикам serve-stale/prefetch там, де це доречно.

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

Контрольний список A: Перед запланованим DNS cutover

1. Знизьте TTL заздалегідь (принаймні на один повний попередній інтервал TTL; часто 24–48 годин), щоб існуючі кеші встигли витримати.
2. Підтвердіть негативні TTL у SOA, щоб коротка помилка не затягнулася на годину.
3. Тримайте старі кінцеві точки живими достатньо довго, щоб пережити клієнтів, які закріплюють DNS або мають довгі з’єднання.
4. Тестуйте з кількох резолверів (корпоративні, публічні, мобільні) і з різних регіонів.
5. Перевірте здоров’я авторитетних серверів і узгодженість між усіма NS (включно з DNSSEC, якщо увімкнено).
6. Майте план відкату, що не залежить від TTL: альтернативне ім’я хоста, переваження делегації або дублювання кінцевих точок.

Контрольний список B: Під час інциденту, пов’язаного з DNS

1. Встановіть істину: запитайте авторитетні сервера напряму; запишіть очікувані відповіді.
2. Порівняйте кеші: опитайте щонайменше два різні рекурсори; зафіксуйте відмінності.
3. Визначте шар, що відмовив: локальний stub, кеш на вузлі, корпоративний форвардер, публічний резолвер або застосунок.
4. Класифікуйте відмову: неправильна відповідь, NXDOMAIN, SERVFAIL, таймаут, нестабільність.
5. Виберіть пом’якшення: чекати, очистити (прицільно), обійти (альтернативне ім’я) або змінити шлях (перевага в делегації).
6. Комунікуйте реалістичні терміни: включіть негативні кеш-терміни та «деякі клієнти закріплюють DNS» у повідомлення про ETA.

Контрольний список C: Після інциденту (частина, яку люди пропускають і потім повторюють)

1. Додайте моніторинг, що обходить кеші: запити авторитетних серверів напряму з кількох мереж.
2. Відстежуйте помилки резолверів: SERVFAIL, таймаути, сплески NXDOMAIN і розподіли затримок.
3. Документуйте топологію резолверів: які мережі використовують які резолвери; включіть VPN і форвардери філій.
4. Уніфікуйте контролі кешу: політика serve-stale, prefetch, процедури очистки і безпечні шаблони рестарту.
5. Аудитуйте поведінку DNS у застосунках: особливо налаштування JVM, пулінг з’єднань та бібліотеки, що кешують.

Поширені запитання

1) Чому моя зміна DNS «не поширилася», хоча TTL був низький?

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

2) У чому різниця між авторитетним DNS і рекурсивними резолверами?

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

3) Чи можна встановити TTL 0, щоб уникнути кешування?

Можна поставити дуже низькі TTL, але багато резолверів не дотримуються 0, і ви значно збільшите навантаження запитів. Низькі TTL також не вирішують закріплення на рівні застосунку і можуть спричиняти штампедо. Використовуйте низькі TTL тактично під час запланованих cutover-ів, а не як постійне рішення.

4) Що таке негативне кешування і чому мені це важливо?

Негативне кешування — це кешування відповіді «ім’я не існує» (NXDOMAIN) або «немає даних» (NODATA). Це важливо, бо коротка помилка — наприклад, відсутній запис — може зберігатися в кешах довше, ніж тривала сама помилка, уповільнюючи відновлення.

5) Коли слід очищати DNS-кеші?

Очищайте, коли ви контролюєте резолвер і впевнені, що авторитетні дані правильні, а вам потрібна конвергенція швидше, ніж дозволяє TTL.
Робіть це прицільно (одне ім’я, один шар) і майте на увазі ризик штампедо. Очищення всього — часто інцидент продуктивності, замаскований під виправлення.

6) Як визначити, чи SERVFAIL пов’язаний з DNSSEC?

Порівняйте поведінку на резолверах з відомою політикою DNSSEC, запросіть з +dnssec і перевірте DS/DNSKEY на узгодженість.
SERVFAIL також може бути через таймаути, тож виміряйте досяжність і спробуйте TCP, щоб виключити UDP-проблеми.

7) Чому деякі клієнти працюють, а інші падають одночасно?

Тому що вони використовують різні резолвери (ISP vs корпоративний vs публічний), мають різний вміст кешу або знаходяться за різними мережевими політиками (split DNS у VPN).
Також деякі клієнти тримають довгі з’єднання і не роблять нових запитів до моменту повторного підключення.

8) Чи погіршує Kubernetes проблеми з DNS?

Може. Kubernetes додає шари DNS (CoreDNS, опційний node-local кеш), збільшує обсяг запитів і створює нові режими відмов, де кеш одного вузла може стати локальною відмовою.
Якщо зроблено правильно — усе гаразд. Якщо неуважно — отримаєте розподілену загадку.

9) Чи варто покладатися на DNS для failover між регіонами?

Використовуйте DNS як інструмент, але не як єдиний. DNS-failover — це eventual-consistent і залежить від клієнта. Поєднуйте його з retry-логікою в застосунку, підтримкою кількох кінцевих точок
і балансуванням з перевірками здоров’я там, де це можливо. Припускайте, що деякі клієнти певний час будуть «неправі», і проєктуйте так, щоб «неправильно» не було критичним.

Висновок: наступні кроки, щоб уникнути повторних інцидентів

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

Зробіть три кроки цього кварталу:

1. Задокументуйте шлях резолвера для кожного важливого оточення (прод вузли, офіс, VPN, CI, Kubernetes). Запишіть і тримайте актуальним.
2. Побудуйте монітори, що обходять кеші: опитуйте авторитетні сервери напряму і валідуйте очікувані відповіді (включно з DNSSEC, якщо використовується).
3. Операціоналізуйте зміни DNS: знижуйте TTL заздалегідь, контролюйте негативні TTL, плануйте накладення кінцевих точок і вважайте очистку кешу скальпелем, а не пожежним сигналом.

Мета не в тому, щоб позбутися кешування. Мета — зробити кешування передбачуваним, відслідковуваним і нудним. Бути нудним у продакшні — це комплімент.