DNS-резолвери: негативне кешування — налаштування, що подовжує простої

February 17, 2026 • February 17, 2026 • Читання: 5 хв • Views: 0

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

Ось типовий таймлайн інциденту: ви помилились у DNS-записі, відразу це помітили, виправили за хвилину… але користувачі продовжують отримувати помилки ще 30–60 хвилин. У тікеті пишуть «DNS досі не працює», на дашбордах — «authoritative відповідає коректно», а бізнес питає «ви певні?»

Ласкаво просимо до негативного кешування: функції резолвера, яка кешує відмови (наприклад, NXDOMAIN) і робить короткі помилки схожими на тривалі провали. Це не злий намір. Це просто виконання своєї роботи — часто з дефолтами, які підходили для минулого інтернету й інших очікувань щодо затримки.

Негативне кешування простими словами

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

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

Можуть співіснувати дві правди:

Ваш авторитарний сервер зараз відповідає правильно.
Резолвери ваших клієнтів досі переконані, що ім’я не існує.

Якщо ви коли-небудь бачили, як команда SRE «терпить DNS» зі стиснутими зубами — ось чому.

Сухий жарт №1: «DNS propagation» не існує — існує лише закінчення дії кешів DNS. На жаль, в маркетингу подобається перший варіант.

Як насправді працює негативне кешування (і чому SOA важливий)

NXDOMAIN vs NODATA: однаковий біль, різна семантика

NXDOMAIN означає, що запитуване ім’я не існує в цій зоні. Приклад: ви питаєте про api.example.com, і авторитарний сервер каже «ніколи не чув про таке».

NODATA (часто бачиться як NOERROR з порожньою секцією ANSWER) означає, що ім’я існує, але запитуваний тип запису відсутній. Приклад: www.example.com існує з A-записом, але ви питаєте AAAA, а в зоні таких записів немає. Багато резолверів також негативно кешують це.

Операційно: обидва випадки можуть блокувати rollout’и, особливо dual-stack переходи (AAAA) і патерни service discovery, що покладаються на «відсутність означає вимкнено».

TTL негативного кешування зазвичай визначається SOA

Негативне кешування стандартизоване (RFC 2308), і TTL, який використовується для кешування негативних відповідей, походить зі SOA-запису зони.

Практична версія:

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

Якщо у вашій зоні SOA встановлено негативний TTL в одну годину, ви щойно дозволили кожному резолверу запам’ятати вашу помилку на годину. Це може бути прийнятно для захисту від typo-squatting і зниження кількості запитів. Але це не підходить для швидко змінних сервісів, які створюють імена на вимогу.

Хто такий «резолвер» насправді?

DNS-резолюція часто проходить кілька рівнів кешів:

Локальний (stub) резолвер на хості (або systemd-resolved)
Локальний кеш на вузлі (поширено в Kubernetes, наприклад NodeLocal DNSCache)
Рекурсивний резолвер (Unbound, BIND, PowerDNS Recursor, корпоративні резолвери, резолвери ISP)
Кеші в додатках (JVM DNS cache, поведінка Go-резолвера, in-process кеші)
CDN / пристрої безпеки, що проксірують DNS

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

Цитата, яку варто приклеїти до монітора

Надія — це не стратегія. — Gene Kranz

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

Факти і історичний контекст, які варто знати

Негативне кешування формалізували для захисту DNS від зайвих повторних запитів, коли імена не існують (RFC 2308). Це функція масштабування, а не баг.
«SOA minimum» раніше означав стандартний TTL у старішій практиці DNS; сучасні зони використовують явні TTL, але спадкова термінологія все ще плутає під час інцидентів.
Резолвери майже завжди кешують NXDOMAIN, якщо не налаштовано інакше, бо повторні швидкі відмови можуть DoS-ити авторитарну інфраструктуру так само ефективно, як і успішний трафік.
Негативне кешування застосовується не лише до NXDOMAIN: «немає AAAA» часто кешується як негативна відповідь. Це важливо при впровадженні IPv6.
Деякі резолвери обмежують негативний TTL (наприклад до кількох хвилин), щоб зменшити масштаб помилок, але підприємства часто скасовують такі обмеження «заради продуктивності».
DNSSEC змінив ситуацію для негативних відповідей: аутентифіковане заперечення існування (NSEC/NSEC3) робить негативні відповіді криптографічно доказовими, а отже їх впевненіше кешують.
Браузери та рантайми з часом стали агресивніші щодо кешування, щоб зменшити затримки. Це допомагає завантаженню сторінок; але також продовжує момент «ми виправили, але все ще не працює».
Kubernetes зробив DNS більш критичним для здоров’я додатків, ніж багато підприємств були готові; негативне кешування особливо болюче, коли сервіси й ендпоінти епемерні.

Де живуть негативні кеші: stub, рекурсивні, аплікаційні та «корисні» middlebox’и

1) Локальні (host-level) stub резолвери

У Linux ви можете мати systemd-resolved, nscd, dnsmasq або не мати нічого (glibc відправляє запити прямо до налаштованих рекурсорів). Кожен з них має власну поведінку кешування.

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

2) Рекурсивні резолвери (справжній кеш)

Саме тут негативне кешування зазвичай завдає найбільшої шкоди, бо рекурсивний резолвер обслуговує цілі популяції: офісні мережі, VPC, кластери й VPN-користувачів.

Рекурсивні резолвери зазвичай:

Кешують негативні відповіді з TTL
Можуть «віддавати прострочені» відповіді за певних умов (зазвичай для позитивних відповідей, але поведінка відрізняється)
Мають політики для максимальних/мінімальних TTL, включно з обмеженнями негативного TTL

3) Кеші на рівні додатка та поведінка рантайму

Навіть якщо DNS «виправили», додаток може продовжувати падати, бо він закешував негативний результат.

Поширені винуватці:

Java може кешувати негативні пошуки; дефолти залежать від налаштувань безпеки та версії JVM.
Go може використовувати cgo-резолвер або pure Go-резолвер залежно від збірки/рантайму; кешування в рантаймі зазвичай мінімальне, але ваш додаток або сайдкари можуть кешувати.
Envoy / service mesh можуть кешувати DNS-результати для discovery в кластері.

4) Middlebox’и та «сек’юріті» DNS

Деякі корпоративні пристрої фільтрації DNS повертають NXDOMAIN (або sinkhole IP) для заблокованих доменів і агресивно кешують ці відповіді. Це може конфліктувати з внутрішніми шаблонами доменів і спричинити… креативні інциденти.

Сухий жарт №2: Приємно, що негативне кешування — це єдина частина DNS, яка ніколи не бреше: якщо воно каже «ні», то це означає «ні» протягом наступних 3600 секунд.

Три міні-історії з корпоративного світу (такі, що ви впізнаєте)

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

Компанія мала акуратний DNS-плейбук: ставити низькі TTL для сервісів, автоматизувати створення записів і використовувати health checks для переключення трафіку. Нова команда випустила внутрішній API-шлюз і вирішила створювати DNS-імена під орендаря на вимогу: tenant-id.api.internal.

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

Насправді перший запит стався до завершення автоматизації. Рекурсивний резолвер повернув NXDOMAIN. Та відповідь містила SOA з великим негативним TTL. Тепер резолвер мав дозвіл говорити всім «не існує» довго, навіть після того, як запис було правильно створено.

Симптоми інциденту були дивні: лише нові орендарі падали, і то лише для частини користувачів. Існуючі орендарі працювали. Шлюз працював. Авторитарна зона виглядала коректно. Команда перезавантажувала поди й сервіси, бо так роблять, коли програють і вже пізно.

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

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

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

Потім вони провели ребрендинг. Нові хости, нові піддомени, багато змін під управлінням маркетингу. Авторитарна зона була готова. Рекурсори були готові. Але значна частина підприємства вже намагалася резолвити деякі з нових імен під час попереднього тестування, коли записів ще не було.

Ці NXDOMAIN тепер були кешовані довго через «оптимізацію». Настав день релізу. Деякі користувачі були OK, інші отримували жорсткі відмови. Хелпдеск сприймав це як флейкі rollout. SRE бачили «DNS коректний». Обидва були технічно праві. Інцидент тривав, поки негативні кеші не скінчилися.

Вони відкотили обмеження негативного TTL, але це не скасувало вже закешованих відмов. Довелося чистити кеші і чекати. Провал був не лише в налаштуванні — а в відсутності політики: негативне кешування — це рішення щодо надійності, а не просто налаштування продуктивності.

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

Фінтех-компанія мала правило, яке дратувало продуктові команди: «Жодне DNS-ім’я не може використовуватися у production-коді, поки воно успішно не резолвиться принаймні з двох незалежних рекурсивних резолверів». Це звучало бюрократично. Так і було. Але правило також запобігло дуже конкретному класу відмов.

Вони мігрували endpoint для callback платежів у новий регіон. План включав створення callback.payments.example як CNAME на регіональне ім’я, а потім переключення під час вікна технічних робіт. Вони попередньо створили запис за кілька днів і перевірили його з (1) власних рекурсорів і (2) окремого стеку резолверів для моніторингу.

Під час вікна змін інженер випадково застосував оновлення зонового файлу без цього запису. Авторитарна почала повертати NXDOMAIN. Моніторинг вловив це за кілька хвилин, бо перевірки йшли з кількох резолверів і порівнювалися з очікуваними відповідями. Вони швидко відкотили зміну.

Важлива частина: оскільки запис існував і був стабільним кілька днів, кеші тримали позитивні записи, а не негативні. Вікно, коли клієнти спостерігали NXDOMAIN, було невелике, і багато клієнтів взагалі цього не побачили. Та нудна практика — попереднє створення, верифікація, моніторинг з кількох точок — перетворила потенційний годинний інцидент у коротку перерву.

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

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

Спочатку: визначте, яку саме відмову ви бачите

NXDOMAIN? Ім’я не існує (жорстко закешовано).
NODATA? Ім’я існує, але бракує типу запису (поширено для AAAA).
SERVFAIL/тайм-аути? Це не негативне кешування; зазвичай DNSSEC, досяжність або upstream проблеми.

По-друге: порівняйте відповіді з трьох місць

Авторитарний nameserver напряму (обійти кеші).
Ваш звичний рекурсивний резолвер (той, який реально використовують клієнти).
Відомий «чистий» резолвер (інший рекурсивний стек під вашим контролем або тестовий резолвер в іншому сегменті мережі).

По-третє: витягніть негативний TTL і вирішіть свій хід

Якщо негативний TTL малий (секунди до кількох хвилин): дочекайтесь, але продовжуйте доводити покращення.
Якщо негативний TTL великий (десятки хвилин до годин): виправте налаштування SOA для довготривалої перспективи і, якщо контролюєте рекурсори — почистіть кеші у короткостроковій.
Якщо лише частина клієнтів падає: підозрівайте локальний шар кешування (node-local DNS, systemd-resolved, JVM), а не авторитарну зону.

По-четверте: перевірте split-horizon і умовну переадресацію

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

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

Ці завдання передбачають інструментарій Linux. Якщо ви запускаєте резолвери в контейнерах або апліансах, логіка та сама: запитайте, порівняйте, витягніть TTL, дійте.

Завдання 1: Підтвердьте симптом за допомогою `dig` проти дефолтного резолвера

cr0x@server:~$ dig api.example.internal A

; <<>> DiG 9.18.24 <<>> api.example.internal A
;; global options: +cmd
;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34219
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  1800  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

;; Query time: 12 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Feb  4 10:01:22 UTC 2026
;; MSG SIZE  rcvd: 132

Що це означає: Статус — NXDOMAIN. SOA показано з TTL 1800 секунд. Це сильний натяк, що негативне кешування становить 30 хвилин.

Рішення: Не деплойте додаток поки що. Спочатку перевірте авторитарну правду і підтвердьте, що політика негативного TTL — причина.

Завдання 2: Запитайте авторитарний сервер напряму (обійти рекурсію)

cr0x@server:~$ dig @192.0.2.53 api.example.internal A +norecurse

; <<>> DiG 9.18.24 <<>> @192.0.2.53 api.example.internal A +norecurse
;; global options: +cmd
;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NOERROR, id: 1201
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 3 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Tue Feb  4 10:01:31 UTC 2026
;; MSG SIZE  rcvd: 62

Що це означає: Авторитарний сервер каже, що запис існує і правильний (NOERROR, прапорець aa, є секція ANSWER).

Рішення: Це майже напевно кешований NXDOMAIN у шарах рекурсії. Ваша зона зараз у порядку; проблеми — у кешах.

Завдання 3: Запитайте рекурсивний резолвер і перевірте SOA TTL в authority

cr0x@server:~$ dig @10.10.0.53 api.example.internal A +noall +answer +authority +comments

;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54530
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  1742  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Що це означає: TTL тепер 1742 секунди, відлік йде вниз. Це кешований негативний стан, що зменшується в реальному часі.

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

Завдання 4: Підтвердіть, чи проблема специфічна для типу запису (NODATA для AAAA)

cr0x@server:~$ dig @10.10.0.53 www.example.internal AAAA

; <<>> DiG 9.18.24 <<>> @10.10.0.53 www.example.internal AAAA
;; ->HEADER<<- opcode: QUERY, status: NOERROR, id: 7711
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  900  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Що це означає: NOERROR з порожньою секцією відповіді може кешуватись як «немає AAAA». Це може ламати клієнтів, що віддають перевагу IPv6 (Happy Eyeballs допомагає, але не завжди).

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

Завдання 5: Використайте `dig +trace`, щоб побачити, де відбувається заперечення

cr0x@server:~$ dig +trace api.example.internal A

; <<>> DiG 9.18.24 <<>> +trace api.example.internal A
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

example.internal. 172800 IN NS ns1.example.internal.
example.internal. 172800 IN NS ns2.example.internal.
;; Received 151 bytes from 198.41.0.4#53(a.root-servers.net) in 17 ms

api.example.internal. 60 IN A 198.51.100.20
;; Received 62 bytes from 192.0.2.53#53(ns1.example.internal) in 4 ms

Що це означає: Шлях до авторитарного повертає правильний запис. Якщо клієнти бачать NXDOMAIN, то причина — кешування або split-horizon, а не відсутня делегація.

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

Завдання 6: Перевірте, який резолвер використовує ваш хост

cr0x@server:~$ resolvectl status

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: example.internal

Що це означає: Хост використовує systemd-resolved у режимі stub. Є локальний кеш плюс upstream-рекурсори.

Рішення: Якщо проблемний лише цей хост — почистіть локальний кеш. Якщо багато хостів — очищення одного хоста не допоможе.

Завдання 7: Очистіть кеш `systemd-resolved` (на хості)

cr0x@server:~$ sudo resolvectl flush-caches

Що це означає: Відсутність виводу — нормально. Це не гарантує, що upstream-кеші очищені.

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

Завдання 8: Перевірте, чи `nscd` кешує пошуки хостів

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

Що це означає: nscd не причетний на цьому хості.

Рішення: Не витрачайте час на його перезапуск. Рухайтесь далі.

Завдання 9: Перевірте налаштування негативного кешування в Unbound

cr0x@server:~$ sudo unbound-control get_option neg-cache-size
neg-cache-size: 4m

Що це означає: Unbound відводить місце для негативного кешу. Розмір — не TTL, але підтверджує, що негативне кешування увімкнено.

Рішення: Якщо у вас брак пам’яті і відбуваються витіснення, ви можете бачити непослідовну поведінку. Інакше — переходьте до очищення або регулювання обмежень.

Завдання 10: Скинути конкретне ім’я в Unbound (схоже на хірургію, а не напалм)

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

Що це означає: Закешований запис для цього імені видалено з Unbound.

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

Завдання 11: Скидання імені в BIND (якщо ви використовуєте named)

cr0x@server:~$ sudo rndc flushname api.example.internal

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

Рішення: Негайно перевірте через dig через цей резолвер. Якщо все ще NXDOMAIN — кеш може бути в іншому місці (forwarder, node-local, runtime клієнта).

Завдання 12: Знайти політику негативного TTL у SOA зони BIND

cr0x@server:~$ dig @192.0.2.53 example.internal SOA +noall +answer

example.internal. 300 IN SOA ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Що це означає: Останнє поле (1800) часто використовується як негативний TTL (згідно з семантикою RFC 2308, залежно від реалізації). TTL самого SOA тут — 300, але поле «minimum» — 1800.

Рішення: Якщо вам потрібне швидше відновлення від помилок і швидке створення імен — зменшіть цей minimum/негативний TTL. Не ставте 0, якщо вам подобається самостійно спричинені пікові навантаження на авторитарні сервери.

Завдання 13: Перевірте, що бачить ваш клієнт через `getent`

cr0x@server:~$ getent ahostsv4 api.example.internal
198.51.100.20   STREAM api.example.internal
198.51.100.20   DGRAM
198.51.100.20   RAW

Що це означає: Шлях через libc-resolver повертає результат. Якщо dig падає, а getent працює (або навпаки), у вас може бути split DNS або різні шляхи резолюції (stub vs direct).

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

Завдання 14: Перевірте, чи CoreDNS в Kubernetes кешує негативи надто довго

cr0x@server:~$ kubectl -n kube-system get configmap coredns -o yaml | sed -n '1,120p'
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . 10.10.0.53 10.10.0.54
        cache 30
        loop
        reload
        loadbalance
    }

Що це означає: Плагін cache 30 кешує відповіді 30 секунд за замовчуванням. Залежно від конфігурації, негативні відповіді також можуть кешуватися. Ваш upstream-рекурсор може все ще тримати NXDOMAIN значно довше.

Рішення: Якщо кластер — це постраждала популяція, налаштуйте кешування CoreDNS свідомо і впевніться, що upstream обмеження негативного TTL узгоджуються з потребами service discovery.

Завдання 15: Спостерігайте, чи forwarder повертає кешований NXDOMAIN

cr0x@server:~$ dig @10.10.0.53 api.example.internal A +stats

; <<>> DiG 9.18.24 <<>> @10.10.0.53 api.example.internal A +stats
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32602
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; Query time: 1 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Feb  4 10:02:01 UTC 2026
;; MSG SIZE  rcvd: 132

Що це означає: Час відповіді 1 мс сильно натякає, що відповідь взята з кешу, а не отримана з авторитарних серверів.

Рішення: Вам потрібне управління кешем (скидання/обмеження TTL), а не просто «спробуйте ще раз».

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

1) «Ми створили запис, але користувачі досі бачать NXDOMAIN»

Симптоми: Авторитарний сервер показує запис; клієнти все ще падають з NXDOMAIN; відмови повільно зникають протягом десятків хвилин.

Корінь проблеми: Рекурсивні резолвери раніше кешували NXDOMAIN; негативний TTL, похідний від SOA, довгий.

Виправлення: Зменшіть негативний TTL у зоні (SOA minimum/negative TTL policy), очистіть кеші, якими ви керуєте, і попередньо створюйте записи до того, як клієнти зможуть їх запитати.

2) «Лише IPv6-клієнти падають» (або лише деякі бібліотеки)

Симптоми: A-запити працюють; AAAA-запити повертають порожньо; деякі клієнти тайм-аутять або поводяться дивно.

Корінь проблеми: NODATA для AAAA кешується; клієнт віддає перевагу IPv6; додаток не коректно відпрацьовує fallback.

Виправлення: Публікуйте AAAA, якщо це доречно, або налаштуйте поведінку клієнта; розгляньте зменшення негативного кешування для NODATA пов’язаного з AAAA, якщо це ускладнює rollout.

3) «Працює на моєму ноутбуці, не працює в дата-центрі»

Симптоми: Той самий запит дає різні відповіді залежно від мережі.

Корінь проблеми: Split-horizon DNS, умовна переадресація або різні стекі рекурсивних резолверів з різним негативним станом кешу.

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

4) «Перезапуск подів тимчасово виправив…»

Симптоми: Додаток працює після рестарту, потім знову падає; або різні поди поводяться по-різному.

Корінь проблеми: Локальні кеші вузлів різняться; деякі вузли потрапляли на кешований NXDOMAIN; рестарти змінюють вузол, на який ви потрапляєте.

Виправлення: Вирішіть проблему на рівні резолвера (локальний кеш вузла / CoreDNS / upstream recursor). Не використовуйте рестарти як інструмент інвалідизації кешу.

5) «Ми встановили низькі TTL, то чому все ще зламано?»

Симптоми: Позитивні TTL низькі (наприклад 60с), але NXDOMAIN триває набагато довше.

Корінь проблеми: Негативний TTL — не ваш TTL запису. Він походить від полів SOA і політик резолверів.

Виправлення: Аудитуйте поля SOA і обмеження негативного TTL у резолверів. Розглядайте негативний TTL як контрольну метрику SLO надійності.

6) «DNSSEC погіршив ситуацію»

Симптоми: Після ввімкнення DNSSEC негативні відповіді затримуються або з’являється SERVFAIL, і очищення кешів виглядає неефективним.

Корінь проблеми: Резолвери з валідацією DNSSEC впевненіше кешують аутентифіковане заперечення існування; крім того, невірна конфігурація може давати SERVFAIL (не NXDOMAIN).

Виправлення: Розрізняйте NXDOMAIN і SERVFAIL. Для SERVFAIL — перевірте ланцюг DNSSEC і підписи. Для NXDOMAIN — налаштуйте негативний TTL і стратегію очищення кешу.

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

Чекліст: перед створенням нових імен у production

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

Чекліст: під час інциденту «DNS виправлено, але все ще зламано»

Підтвердьте тип відмови: NXDOMAIN vs NODATA vs SERVFAIL.
Запитайте авторитарний сервер напряму з +norecurse.
Запитайте рекурсивний резолвер, яким користуються клієнти; витягніть залишковий TTL з рядка SOA.
Перевірте, чи час відповіді вказує на кеш (1–2ms) або upstream (10ms+).
Якщо контролюєте резолвер — скиньте конкретне ім’я; повторно перевірте.
Якщо не контролюєте — тимчасово перемістіть клієнтів на інший резолвер (останній засіб, але іноді це єдиний важіль).
Після відновлення зменшіть негативний TTL, якщо він розтягнув тривалість відмови.

Покроковий план: оптимізація негативного кешування без розплавлення авторитарних серверів

Перелікуйте зони і категоризуйте їх: стабільні публічні, внутрішні стабільні, внутрішні динамічні (service discovery, епемерні імена).
Виміряйте частоту NXDOMAIN на рекурсорах і авторитарних серверах. Високий обсяг NXDOMAIN вказує на друкарки, сканування або зламані клієнти.
Встановіть цілі негативного TTL за категоріями:
- Стабільні публічні зони: довший TTL може бути прийнятним.
- Внутрішні динамічні зони: короткий негативний TTL зазвичай виправданий.
Налаштуйте обмеження на резолверах, щоб одна погана SOA не наклала погоджений годинний простій на всіх.
Протестуйте навантаження авторитарних серверів, якщо різко зменшите негативний TTL. Менше кешованих NXDOMAIN означає більше upstream-запитів.
Поступово розгортайте зміни по фліту резолверів; моніторте обсяг запитів, затримку та SERVFAIL.

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

1) Чи є негативне кешування тим самим, що й «DNS propagation»?

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

2) Що контролює, як довго кешується NXDOMAIN?

Зазвичай це SOA зони (семантика негативного TTL) плюс будь-які обмеження чи переозначення на рекурсивних резолверах. Деякі резолвери застосовують мінімальні/максимальні політики.

3) Якщо я встановлю TTL запису 60 секунд, чи буде NXDOMAIN кешуватися також 60 секунд?

Ні. TTL запису впливає на позитивні відповіді. Кешування NXDOMAIN керується негативним TTL, зазвичай похідним від SOA.

4) Чи можу я просто встановити негативний TTL у 0 скрізь?

Можна, але ви заплатите за це збільшенням навантаження запитів і потенційно самостійним DoS ваших авторитарних серверів. Для динамічних внутрішніх зон зазвичай підходить маленьке (але не нульове) значення.

5) Як визначити, чи бачу я кешований NXDOMAIN чи авторитарний NXDOMAIN?

Запитайте авторитарний сервер напряму з dig @auth +norecurse. Якщо авторитарний каже NOERROR, а рекурсивний — NXDOMAIN, то це кеш або split-horizon. Також спостерігайте за відліком TTL у рядку SOA при повторних запитах.

6) Чому лише деякі користувачі бачать відмову?

Бо різні користувачі звертаються до різних резолверів або різних шарів кешу. Дехто міг закешувати стару відмову; інші могли ніколи не робити запиту під час поганого вікна.

7) Чи очищення кешів завжди моментально вирішує проблему?

Тільки якщо ви очистили кеш, що тримає поганий запис, і клієнти справді використовують цей резолвер. Очищення ноутбука не виправить корпоративний рекурсивний кеш upstream.

8) Що з кешами браузера?

Браузери можуть кешувати DNS непрямим шляхом через reuse з’єднань і внутрішні кеші, але більша операційна проблема зазвичай — кешування на рівні рекурсивних резолверів і кешування рантайму додатків.

9) Як DNSSEC впливає на негативне кешування?

DNSSEC може зробити негативні відповіді перевіреними (authenticated denial of existence), що підвищує довіру до кешування. Але воно також вводить режими відмов (SERVFAIL), коли валідація не проходить — це відмінно від NXDOMAIN.

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

Попередньо створіть запис заздалегідь, перевірте з кількох рекурсивних резолверів, тримайте негативний TTL коротким у цій зоні й постійно моніторте резолюцію.

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

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

Зробіть ці три кроки

Аудитуйте негативні TTL у SOA для зон, що використовуються динамічними сервісами. Якщо значення рахуються годинами — ви обираєте довгі відмови.
Додайте один графік: rate NXDOMAIN і топ NXDOMAIN назв на ваших рекурсорах. Не можна керувати тим, чого не видно, і спалахи NXDOMAIN часто — перше попередження.
Напишіть рукопис для скидання кешу для кожного рівня резолверів, якими ви оперуєте (systemd-resolved, node-local, CoreDNS, Unbound/BIND). Включіть команди верифікації і очікувані результати.

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

Схожі статті

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