Ви оновили запис DNS. Ви зачекали «кілька хвилин». У консолі все ще відображається старий IP. Хтось у Slack пише:
«знову щось із DNS», а інша людина пропонує перезапустити все підряд, поки графік не стане зеленим.
Реальність така: DNS зазвичай не зламався. Ваша зміна просто застрягла за конкретним кешем, десь
між авторитетним сервером і користувачем. Завдання — знайти, який кеш вам брешe, очистити лише те, що допоможе,
і лишити інші шари у спокої — бо неправильне очищення може перетворити невелику затримку на повноцінний інцидент.
Ментальна модель: звідки насправді приходять відповіді DNS
Коли люди говорять «поширення DNS», вони уявляють собі єдину глобальну систему, що повільно синхронізується. Це не те, що відбувається.
DNS — це ланцюжок делегацій і кешів, і кожне ланка незалежно вирішує, що повертати і як довго.
Ви публікуєте записи на авторитетному сервері (або через провайдера). Але більшість клієнтів ніколи з ним не спілкуються.
Вони питають рекурсивний резолвер (часто ваш провайдер інтернету, корпоративна мережа або публічний резолвер), і цей резолвер
кешує відповіді. Потім ваша ОС може кешувати. Браузер може кешувати. Додаток може кешувати. Сервісна сітка може робити «корисне»
кешування. Балансувальник навантаження може зберігати застаріле відображення upstream. А потім Kubernetes CoreDNS теж може мати свою думку.
«DNS‑зміни не видно» майже завжди означає одне з наступних:
- Ви змінили не те, що думаєте (невірна зона, невірний запис, неправильне ім’я, неправильний view).
- Ви змінили, але TTL каже «ще ні» (включно з негативним кешуванням — воно підступніше).
- Ви змінили, але тестуєте через кеш (локальний резолвер, корпоративний форвардер, браузер тощо).
- Ви змінили, але різні користувачі отримують різні відповіді (гео DNS, EDNS Client Subnet, split‑horizon).
Мета не в «очистити все». Мета: знайти вузьке місце‑кеш, потім обрати найменш ризиковану дію.
Продуктивні системи винагороджують точність.
Швидкий план діагностики (перевірити 1/2/3)
Якщо ви на виклику, вам потрібен шлях до ясності за 60–180 секунд. Ось порядок дій, який мінімізує самостворені проблеми.
1) Перевірте авторитетну правду (обійдіть кеші)
Запитайте безпосередньо авторитетні неймсервери для запису, який ви змінили. Якщо авторитетні не показують змін — зупиніться.
Ваша проблема не «поширення». Ваша проблема — публікація.
- Знайдіть NS запис зони.
- Запитайте кожен NS напряму з
dig @nsX. - Перевірте запис, TTL і будь‑який CNAME‑ланцюг.
2) Перевірте резолвер, який реально використовується в шляху збоїв
Якщо авторитетні відповіді правильні, протестуйте рекурсивний резолвер, який використовує клієнт з проблемою. Це може бути:
корпоративний форвардер, VPC резолвер, node‑local кеш або публічний резолвер.
Порівняйте:
- Розділ ANSWER (A/AAAA/CNAME)
- Залишок TTL (якщо високий — ви чекаєте, а не зламаюся)
- NXDOMAIN vs NOERROR (негативне кешування теж означає «ви чекаєте»)
3) Перевіряйте кеші на стороні клієнта в останню чергу (ОС, браузер, додаток)
Лише після того, як авторитетні та рекурсивні резолвери в порядку, переходьте до локальної машини. Локальне очищення дешеве,
але це також відволікає: ви можете «вилікувати свій ноутбук», поки реальні користувачі все ще бачать застарілі дані.
Перефразована ідея від Richard Cook (resilience engineering): «Успіх і невдача походять з тих самих щоденних процесів.»
DNS‑кешування — один із таких процесів. Воно виконує свою роботу — поки вам не потрібно, щоб воно припинило її виконувати.
Які кеші існують (і у чому їхня провина)
1) Поведінка авторитетного сервера (не кеш, але часто винний)
Ваші авторитетні сервери повертають те, що зараз у зоні/базі. Якщо вони помиляються:
неправильний запис, неправильна зона, не синхронізовано, застарілий секондар, неправильний view, або ви редагували UI, який записує в інше місце,
ніж ви думаєте.
Класичний режим відмови: ви оновили www.example.com, але трафік насправді йде на api.example.com
через CNAME‑ланцюг, про який ви забули.
2) Кеші рекурсивних резолверів (головний підозрюваний)
Рекурсивні резолвери кешують згідно TTL. Ось у чому суть. Якщо вчора ви поставили TTL 3600 і змінили запис зараз,
деякі резолвери триматимуть стару відповідь до години від останнього запиту.
Гірше: резолвери також кешують негативні відповіді (NXDOMAIN, NODATA). Якщо резолвер недавно запитував
запис, якого не існувало, він може кешувати відповідь «не існує» на основі SOA minimum/negative TTL.
Люди це забувають, а потім звинувачують інтернет у газлайтингу.
3) Форвардери та корпоративні DNS‑шари (де істина «оптимізується»)
Багато мереж використовують ланцюжок: клієнт → локальний stub → корпоративний форвардер → верхній рекурсивний. Кожен хоп може кешувати.
Кожен хоп також може змінювати поведінку: фільтрація DNS, split‑horizon, умовна пересилка або «засоби безпеки», що MITM‑ять DNS.
4) Кеші stub‑резолвера ОС (systemd‑resolved, mDNSResponder, Windows DNS Client)
Сучасні ОС часто кешують DNS‑відповіді локально для продуктивності. Це зазвичай невеликий кеш, але його достатньо,
щоб ваш ноутбук не погоджувався з сервером, і це вже може зʼїсти цілий вечір.
5) Кеші на рівні додатка (Java, Go, glibc та інші)
Деякі рантайми кешують DNS‑результати агресивно або непередбачувано. Java історично кешувала назавжди, якщо не налаштовано інакше.
Деякі HTTP‑клієнти пулюють зʼєднання і продовжують використовувати старий IP без повторного резолвінгу. Це не DNS‑кешування — це
повторне використання зʼєднань. Інша помилка, схоже симптом: «я змінив DNS, а нічого не змінилося».
6) Кеші браузера
Браузери тримають власні кеші і можуть предфетчити імена. Вони також можуть зберігати встановлені зʼєднання і продовжувати
спілкуватися зі старим кінцевим пунктом навіть після зміни DNS.
7) CDN / edge резолвери та геофункції
Якщо ви використовуєте гео DNS, маршрутизацію за латентністю або EDNS Client Subnet, різні рекурсивні резолвери можуть отримувати різні відповіді.
Ви можете бути «праві» в одному місці і «неправі» в іншому без жодного багу — просто через політику.
8) Kubernetes DNS (CoreDNS) та node‑local кеші
У кластерах DNS — залежність, як будь‑яка інша. CoreDNS кешує. Node‑local DNS кеші є.
І потім ваш додаток може кешувати ще раз. Якщо ви відлагоджуєте сервіс, який не бачить нового endpoint, треба вирішити,
з якого шару ви тестуєте: pod, node чи ззовні кластера.
Практичні завдання: команди, виводи, рішення (12+)
Це реальні завдання, які ви можете виконати. Кожне містить: команду, типове значення виводу і рішення, яке потрібно прийняти.
Використовуйте dig коли можете. nslookup підходить, але ховає деталі, які вам часто потрібні (TTL, прапори, authority).
Завдання 1: Знайти авторитетні неймсервери зони
cr0x@server:~$ dig +noall +answer example.com NS
example.com. 3600 IN NS ns1.dns-provider.net.
example.com. 3600 IN NS ns2.dns-provider.net.
Що це значить: Це авторитетні NS записи, якими має користуватися світ.
Рішення: Питайте їх напряму далі. Якщо ви не бачите очікуваного провайдера — ви редагуєте неправильну зону або делегація неправильна.
Завдання 2: Запитати авторитетний прямо (обхід рекурсивних кешів)
cr0x@server:~$ dig @ns1.dns-provider.net www.example.com A +noall +answer +authority
www.example.com. 300 IN A 203.0.113.42
example.com. 3600 IN SOA ns1.dns-provider.net. hostmaster.example.com. 2025123101 7200 900 1209600 300
Що це значить: Авторитетний каже, що A запис — 203.0.113.42 з TTL 300 секунд.
Рішення: Якщо це неправильно — виправте публікацію (запис/значення/зона). Якщо правильно — проблема нижче по шляху через кеші або поведінку клієнта.
Завдання 3: Порівняти всі авторитетні сервери (виявити застарілих вторинних)
cr0x@server:~$ for ns in ns1.dns-provider.net ns2.dns-provider.net; do echo "== $ns =="; dig @$ns www.example.com A +noall +answer; done
== ns1.dns-provider.net ==
www.example.com. 300 IN A 203.0.113.42
== ns2.dns-provider.net ==
www.example.com. 300 IN A 198.51.100.77
Що це значить: Розбіжність на рівні авторитетних: різні NS повертають різні відповіді.
Рішення: Перестаньте дебажити кеші. Виправте розповсюдження зони/AXFR/IXFR/hidden primary або синхронізацію провайдера. Поки авторитетні не погодяться — інші шари роблять шум.
Завдання 4: Перевірити, що бачить публічний рекурсивний резолвер
cr0x@server:~$ dig @1.1.1.1 www.example.com A +noall +answer
www.example.com. 245 IN A 203.0.113.42
Що це значить: Публічний резолвер має нове значення; залишок TTL — 245 секунд.
Рішення: Якщо користувачі все ще бачать старі дані, вони можуть використовувати інший резолвер (корпоративний/VPC), або проблема в локальному/додатковому кешуванні.
Завдання 5: Явно перевірити корпоративний/VPC резолвер
cr0x@server:~$ dig @10.20.30.40 www.example.com A +noall +answer
www.example.com. 3240 IN A 198.51.100.77
Що це значить: Цей резолвер все ще має стару відповідь у кеші, залишилось майже година.
Рішення: Чекати (найкраще) або очистити кеш саме цього резолвера, якщо ви ним управляєте і це безпечно. Не перезапускайте половину флоту.
Завдання 6: Виявити негативне кешування (NXDOMAIN) на резолвері
cr0x@server:~$ dig @10.20.30.40 newhost.example.com A +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41433
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
example.com. 300 IN SOA ns1.dns-provider.net. hostmaster.example.com. 2025123101 7200 900 1209600 300
Що це значить: Повертається NXDOMAIN і SOA в секції authority підказує про поведінку негативного TTL.
Рішення: Якщо ви щойно створили newhost, цей резолвер може кешувати «не існує» до вичерпання негативного TTL з SOA. Можна очистити кеш резолвера або зачекати; не поспішайте постійно «пробувати знову» і чекати іншого результату.
Завдання 7: Пройти CNAME‑ланцюг до реальної цілі
cr0x@server:~$ dig www.example.com A +noall +answer
www.example.com. 300 IN CNAME www.example.com.cdn.vendor.net.
www.example.com.cdn.vendor.net. 60 IN A 203.0.113.42
Що це значить: Ваша «зміна запису» може бути на хості CDN, а не на вашому vanity‑імені.
Рішення: Відлагоджуйте правильну зону. Якщо ви контролюєте лише www.example.com, але вендор керує ціллю, очищення ваших кешів не змінить TTL вендора.
Завдання 8: Перевірити, яким резолвером насправді користується ваш Linux‑хост (systemd‑resolved)
cr0x@server:~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.40
DNS Servers: 10.20.30.40 10.20.30.41
Що це значить: Ваша машина використовує 10.20.30.40 як резолвер, не той, який ви перевіряли раніше.
Рішення: Запитайте цей резолвер напряму. Якщо він застарів — очищення браузера не допоможе.
Завдання 9: Очистити кеш systemd‑resolved (клієнтська сторона)
cr0x@server:~$ sudo resolvectl flush-caches
Що це значить: Локальний stub кеш очищено.
Рішення: Повторно протестуйте з dig на тому самому хості. Якщо результати не змінилися — проблема вгору по ланцюгу або взагалі не DNS.
Завдання 10: Проінспектувати шлях NSS в glibc (чи взагалі ви використовуєте DNS?)
cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
Що це значить: Пошук спочатку дивиться у /etc/hosts, потім мDNS, потім DNS.
Рішення: Якщо хтось прописав старий IP у /etc/hosts, жодне очищення DNS не допоможе. Перевірте /etc/hosts далі.
Завдання 11: Перевірити, чи /etc/hosts не перекриває вашу зміну
cr0x@server:~$ grep -n 'www.example.com' /etc/hosts
12:198.51.100.77 www.example.com
Що це значить: Хост локально зашитий на старий IP.
Рішення: Видаліть або оновіть запис. Це не проблема DNS; це локальне перекриття.
Завдання 12: Побачити фактичне резолвінг через getent (те, чого часто використовують додатки)
cr0x@server:~$ getent ahostsv4 www.example.com
203.0.113.42 STREAM www.example.com
203.0.113.42 DGRAM
203.0.113.42 RAW
Що це значить: Системний стек резолвінгу (NSS + stub) повертає новий IP.
Рішення: Якщо ваш додаток все ще підключається до старого endpoint — підозрюйте пулювання зʼєднань, жорстко вбиті upstream або внутрішній сервіс‑дискавері шар.
Завдання 13: Перевірити TTL і кешування в BIND (резолвер, яким ви керуєте)
cr0x@server:~$ sudo rndc status
version: BIND 9.18.24
running on dns-cache-01: Linux x86_64 6.8.0
number of zones: 102
recursive clients: 17/1000/1000
Що це значить: Ви запускаєте рекурсивний резолвер (або принаймні BIND присутній).
Рішення: Якщо цей шар повертає застарілі відповіді — плануйте контрольоване очищення кешу (наступне завдання), а не сліпе перезапускання демонa.
Завдання 14: Безпечно очистити кеш BIND‑резолвера (цільовий підхід)
cr0x@server:~$ sudo rndc flushname www.example.com
Що це значить: BIND видаляє запис кешу для цього імені (та повʼязаних даних).
Рішення: Вдень віддавайте перевагу flushname замість глобального очищення. Глобальне очищення може створити навантаження на upstream і виглядати як відмова.
Завдання 15: Перевірити поведінку 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
ttl 30
}
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
Що це значить: CoreDNS явно кешує 30 секунд, плюс плагін Kubernetes має TTL 30.
Рішення: Якщо «DNS‑зміни не видно» тривають хвилини, швидше за все CoreDNS не причина. Дивіться вгору по ланцюгу або перевіряйте кешування додатка.
Завдання 16: Протестувати зсередини pod (прибрати ноутбук із розповіді)
cr0x@server:~$ kubectl run -it --rm dns-debug --image=alpine:3.20 -- sh -lc "apk add --no-cache bind-tools >/dev/null && dig www.example.com A +noall +answer"
www.example.com. 300 IN A 203.0.113.42
Що це значить: Кластер бачить нову відповідь.
Рішення: Якщо в кластері робоче навантаження все ще потрапляє на старий IP — підозрюйте додаток (повторне використання зʼєднань) або сайдкар/сервіс‑меш.
Завдання 17: Доведіть, що це не DNS — перевірте, куди йдуть зʼєднання
cr0x@server:~$ curl -sS -o /dev/null -w "remote_ip=%{remote_ip}\n" https://www.example.com/
remote_ip=198.51.100.77
Що це значить: Ви все ще підключаєтеся до старого IP навіть якщо DNS показує інше (або TLS/SNI вас спрямовує туди).
Рішення: Перевірте проксі, балансувальники, конфіг CDN і чи клієнт повторно використовує існуюче зʼєднання. DNS може бути вже правильним.
Завдання 18: Перевірити, чи локальний кеш‑демон працює (nscd)
cr0x@server:~$ systemctl is-active nscd
inactive
Що це значить: nscd не запущений, отже це не ваш шар кешування.
Рішення: Не витрачайте час на очищення того, чого немає. Знайдіть реальний компонент кешування.
Кеші, які не слід очищати (якщо вам не до вподоби відмови)
Очищення кешів схоже на вимикання роутера: іноді корисно, іноді необхідно, але воно небезпечно вводить звичку.
Деякі кеші безпечні для локального очищення. Інші — це спільна інфраструктура, і їх очистка може спричинити «тюленяче стадо».
Не очищайте глобально великі рекурсивні резолвери в пікові години
Якщо ви керуєте корпоративним флотом резолверів або спільним рівнем VPC‑резолверів, глобальне очищення може спричинити:
- стрибок QPS на upstream
- зростання латентності та таймаутів
- посилення залежності від зовнішніх резолверів
- ланцюгові відмови в додатках, які трактують таймаути DNS як фатальні
Віддавайте перевагу цільовому очищенню (flushname / по зоні / по view) або, краще, зачекайте TTL, коли це безпечно.
Не перезапускайте CoreDNS як перший крок
Перезапуск CoreDNS може зламати резолвінг усього кластера. Це великий радіус ураження для проблеми, яка часто просто повʼязана з TTL.
Якщо ви підозрюєте кешування CoreDNS, підтвердьте це через dig у pod і подивіться Corefile спочатку.
Не «виправляйте» панічно шляхом зниження TTL
Зниження TTL — це інструмент планування, а не екстрений важіль. Зниження TTL зараз не допоможе клієнтам, які вже закешували старий запис.
Воно вплине лише на наступне заповнення кешу.
Жарт №1: DNS‑кешування схоже на офісні плітки: коли щось пішло в люди, виправити це займе довше, ніж почати.
Цікаві факти і трохи історії DNS
- DNS замінив проблему масштабування HOSTS.TXT. Ранні хости ARPANET використовували спільний файл hosts; з ростом мережі розповсюдження файлу стало вузьким місцем.
- TTL не створювався під ваш графік деплою. Він створювався для масштабованості і стійкості глобальної системи і не для миттєвих маркетингових редиректів.
- Негативне кешування стандартизоване. Кешування «не існує» — це навмисно; інакше резолвери безперервно б бомбардували авторитетні сервери помилками і опечатками.
- SOA впливає на негативне кешування. Поле minimum/negative TTL у SOA часто вводить в оману; різні інструменти маркують його по‑різному.
- Резолвери кешують не лише A/AAAA. Вони також кешують NS делегації та glue, що робить зміни делегації «липкими», навіть якщо запис оновився швидко.
- DNS зазвичай працює через UDP. Це швидко, але означає, що втрата пакетів і MTU‑проблеми можуть маскуватися під «застарілий DNS». Існує fallback на TCP, але він не завжди надійний.
- EDNS Client Subnet змінив динаміку кешування. Деякі резолвери варіюють відповіді залежно від підмережі клієнта, що знижує хіт‑рейт кешу і збільшує «в мене працює, в тебе ні» моменти.
- Браузери стали учасниками DNS. Сучасні браузери попередньо резолвлять, кешують незалежно і іноді запускають кілька зʼєднань одночасно, тож DNS уже не лише справа ОС.
Три корпоративні міні‑історії з реального життя
Міні‑історія 1: Інцидент через неправильне припущення
Компанія середнього розміру мігрувала клієнтський API на новий балансувальник. План був простий: оновити A запис
api.example.com зі старого VIP на новий VIP. Вони за тиждень поставили TTL 300. Добре.
На момент cutover половина трафіку пішла. Інша половина й надалі потрапляла на стару інфраструктуру і почала таймаутитись, бо пул старого балансувальника дренувався. Канал інциденту заповнився повідомленнями «DNS не поширився».
Неправильне припущення: усі зверталися до api.example.com. Насправді ні. Застарілий мобільний клієнт мав жорстко прописаний
api-v2.example.com, який був CNAME до вендорського імені з TTL 3600. Команда змінила vanity‑ім’я, яке знали люди, але не залежність,
яку використовували пристрої.
Виправлення було не в очищенні кешів. Виправлення — оновити фактичну CNAME‑ціль (через процес вендора) і тимчасово тримати старий VIP активним.
Також задокументували повний CNAME‑ланцюг у runbook, бо tribal knowledge — це не заміна change‑менеджменту.
Міні‑історія 2: Оптимізація, що обернулася проти
Інша організація втомилася від стрибків латентності DNS і вирішила «оптимізувати» шляхом агресивного кешування скрізь:
node‑local DNS кеш на вузлах Kubernetes, внутрішній рівень форвардерів і бібліотека кешування всередині додатку.
Обґрунтування звучало добре: менше запитів, швидше відповіді, менші витрати.
Потім вони ввели blue/green деплоя за допомогою DNS. Під час rollout деякі поди резолвили нову ціль і успішно працювали.
Інші продовжували використовувати старий endpoint і падали. Панелі виглядали у вигляді штрих‑коду: то успіх, то фіаско через кілька секунд.
Повернення в норму сталося через накладання кешів і невідповідність семантики TTL. Кеш додатка тримав записи довше, ніж ОС TTL.
Node‑local кеш дотримувався TTL, але мав баг, що закріплював негативні відповіді довше під навантаженням. Форвардер мав застарілі делегації після зміни неймсерверів.
Кожен шар «працював», але композиція була хаотичною.
Відновлення було нудне: прибрати кешування на рівні додатка, стандартизувати один шар кешування (node‑local або центральний, не обидва),
і налаштувати алерти на підвищення SERVFAIL у резолверах. Вони також перестали використовувати DNS для тонкого розшарування трафіку
і перейшли на ваги балансувальника для швидких cutover.
Міні‑історія 3: Нудна, але правильна практика, що врятувала ніч
Фінансова компанія мала процес змін, продиктований комплаєнсом, який усі зневажали, поки він не окупився. Треба було перемістити
інтеграцію з зовнішнім вендором на інший endpoint. Інтеграція використовувала hostname, а не фіксований IP — вже добре.
За два тижні до переміщення вони знизили TTL із 3600 до 300. Не в паніці — за планом. Вони перевірили нове TTL запитами до авторитетних і кількох резолверів.
Також зберегли базові відповіді в тікеті, включно з CNAME‑ланцюгом і SOA.
В ніч cutover вони змінили запис, перевірили авторитетні, потім перевірили через корпоративні резолвери.
Вони не очищали кеші. Вони спостерігали, як TTL відраховується. Для невеликої кількості клієнтів за впертим резолвером вони застосували цільове очищення на рівні резолверів, якими володіли.
Міграція пройшла без впливу на клієнтів. Ніхто не відправляв листа з перемогою, бо нудна правильність не трендить.
Але інженер на виклику спав — і це єдина метрика, що має значення о 2:00 ночі.
Типові помилки: симптом → корінь проблеми → виправлення
1) Симптом: «Авторитетний показує новий IP, але деякі користувачі впродовж годин все ще потрапляють на старий IP»
Корінь проблеми: Рекурсивні резолвери закешували стару відповідь з високим TTL, або ви занизили TTL занадто пізно.
Виправлення: Вичекайте TTL; наступного разу знижуйте TTL принаймні за одне повне TTL‑вікно до зміни. Якщо ви контролюєте резолвер — зробіть цільове очищення імені.
2) Симптом: «Нове ім’я повертає NXDOMAIN, хоча ми його створили»
Корінь проблеми: Негативне кешування на рекурсивних резолверах від попередніх запитів, коли запис не існував.
Виправлення: Перевірте негативний TTL з SOA; очистіть кеш резолвера, якщо контролюєте його, або зачекайте. Щоб уникнути цього, попередньо створюйте записи до go‑live.
3) Симптом: «На моєму ноутбуці працює, у продакшені — ні»
Корінь проблеми: Різні резолвери. Ваш ноутбук використовує публічний резолвер або VPN; продакшн — VPC резолвер або внутрішній форвардер із застарілим кешем.
Виправлення: Запитайте продакшн‑резолвер напряму. Не використовуйте свій пристрій як вимірювальний прилад для продакшну.
4) Симптом: «dig показує новий IP, але сервіс все одно підключається до старого IP»
Корінь проблеми: Пулювання зʼєднань / keep‑alive / довгоживучі клієнти (не DNS). Або маршрутизація проксі за SNI/Host.
Виправлення: Перевірте віддалений IP за допомогою curl -w %{remote_ip}; перезапустіть або перезавантажте пул клієнтів, а не шар DNS. Розгляньте зниження keep‑alive або проактивне оновлення DNS у клієнта.
5) Симптом: «В деяких регіонах видно нову відповідь, в інших ні»
Корінь проблеми: Geo DNS / маршрутизація за латентністю / EDNS Client Subnet, або split‑horizon view.
Виправлення: Тестуйте з резолверами в тих регіонах або з корпоративних egress точок. Підтвердіть політику провайдера. Переконайтеся, що ви змінили правильний view.
6) Симптом: «Після очищення резолвера все стало повільніше»
Корінь проблеми: Cache stampede. Ви примусили холодний кеш по багатьох іменах, підвищивши QPS на upstream і латентність.
Виправлення: Уникайте глобальних очищень. Використовуйте цільове очищення. Якщо мусите очищувати глобально — робіть це у непіковий час і спостерігайте за навантаженням upstream та рівнем SERVFAIL.
7) Симптом: «Тільки один сервер бачить старий запис»
Корінь проблеми: Локальне перекриття в /etc/hosts, локальний кеш‑демон або різні налаштування resolv.conf/resolved.
Виправлення: Перевірте /etc/hosts, resolvectl status і getent. Очищайте локальний stub кеш лише після підтвердження шляху резолвінгу.
8) Симптом: «Ми змінили NS записи і тепер деякі клієнти не можуть резолвити домен»
Корінь проблеми: Кешування делегацій і TTL для glue/батьківської зони; деякі резолвери все ще користуються старим NS набором.
Виправлення: Плануйте зміни NS із запасом часу. Тримайте старі неймсервери в роботі під час переходу. Перевірте делегацію у батьківській зоні і правильність glue.
Жарт №2: Очищення DNS кешів — єдиний випадок, коли «вимкнути і ввімкнути знову» може DDoS‑нути вашу власну інфраструктуру.
Чеклісти / покроковий план
Чекліст A: Ви змінили A/AAAA запис і користувачі цього не бачать
- Підтвердіть авторитетну правду: опитайте кожен авторитетний NS напряму. Підтвердіть значення та TTL.
- Перевірте CNAME‑ланцюг: впевніться, що ви не змінили ім’я, яке ніхто фактично не запитує.
- Визначте резолвер у шляху збоїв: резолвер клієнта, корпоративний DNS, VPC резолвер.
- Заміряйте залишок TTL на тому резолвері: якщо TTL високий — чекати правильно.
- Обрати дію:
- Якщо ви володієте резолвером: цільове очищення для цього імені.
- Якщо ні: чекати; розглянути тимчасові заходи (тримаючи старий endpoint живим).
- Лише потім: очищайте stub кеш ОС на тестових клієнтах, щоб зменшити плутанину.
- Підтвердіть реальність: перевірте, куди йдуть зʼєднання (remote IP), а не лише що повертає DNS.
Чекліст B: Ви створили нове ім’я і воно повертає NXDOMAIN
- Запитайте авторитетний напряму: чи існує запис там уже?
- Якщо авторитетні правильні — запитайте резолвер, що падає, і перевірте NXDOMAIN + SOA у authority.
- Рішення: чекати вичерпання негативного TTL або очистити резолвер, якщо ви його контролюєте.
- Щоб уникнути повторення: створюйте записи завчасно перед go‑live.
Чекліст C: Ви змінили NS записи (зона ризику)
- Підтвердіть делегацію батьківської зони (те, що сервить реєстр/батько).
- Підтвердіть, що нові неймсервери сервять зону правильно і консистентно.
- Тримайте старі неймсервери в роботі і сервінгу зони принаймні стільки, скільки максимальний релевантний TTL.
- Очікуйте змішаної поведінки під час переходу; не тлумачте це як «випадковість». Це кешована делегація.
Чекліст D: Вирішіть, що очищати (мінімальний радіус ураження)
- Очистити локальний stub, якщо лише ваша робоча станція неправильна:
resolvectl flush-caches. - Очистити одне ім’я на резолвері, яким ви володієте, якщо є реальний бізнес‑імпакт:
rndc flushname. - Не очищайте кеші глобальних резолверів, якщо у вас немає плану по потужності і інцидент‑командир не любить страждань.
- Не перезапускайте DNS‑сервіси замість розуміння проблеми.
FAQ
1) Чому в UI мого DNS‑провайдера показано нове значення, але користувачі все ще отримують старе?
UI провайдера показує авторитетні дані. Користувачі зазвичай запитують рекурсивні резолвери, які закешували стару відповідь до вичерпання TTL.
Підтвердіть, запитавши авторитетні напряму, а потім резолвер користувача.
2) Якщо я зараз зменшу TTL, чи пришвидшить це поточну зміну?
В основному ні. Резолвери, які вже тримають стару відповідь, збережуть її до вичерпання їхнього власного кешу.
Зниження TTL допомагає лише для наступного заповнення кешу.
3) Що насправді означає «поширення DNS»?
Це не один синхронізований потік. Це незалежні кеші, що закінчуються в різний час по всіх рекурсивних резолверах,
форвардерах, stub‑ах ОС, браузерах і додатках.
4) Який кеш мені очищати спочатку?
Жоден. Спочатку підтвердьте авторитетність. Потім визначте резолвер у шляху збоїв. Очищайте лише шар,
що доведено застарілим — і лише якщо ви ним володієте і радіус ураження прийнятний.
5) Чому я бачу NXDOMAIN для запису, який зараз існує?
Негативне кешування. Резолвер може кешувати «не існує», коли запис раніше не існував. Цей кеш діє згідно SOA/negative TTL.
Очистіть резолвер, якщо можете; інакше зачекайте.
6) Чому dig показує новий IP, а мій додаток все ще використовує старий?
Бо ваш додаток може не виконувати повторного резолвінгу. Він може повторно використовувати пулю зʼєднань, кешувати DNS в процесі,
або маршрутизувати через проксі, який має власні upstream‑відображення.
7) Чи варто запускати node‑local DNS кеш у Kubernetes?
Це може підвищити продуктивність і стійкість, але додає ще один шар для відлагодження. Якщо ви це робите, стандартизуйте і задокументуйте:
де відбувається кешування, очікувані TTL і як тестувати з pod/node. Уникайте накопичення кількох кешів без підстав.
8) Чи корисно очищувати кеш DNS у браузері?
Іноді — для одиничного випадку «мій ноутбук дивний». Це не виправить проблеми для продакшн‑користувачів. Використовуйте це як останню милю,
а не як стратегію поширення.
9) Який найнадійніший спосіб виконувати планові DNS‑cutover?
Попередньо підготуйте, знизьте TTL заздалегідь, валідуйте авторитетні відповіді, тримайте старі endpoint живими принаймні протягом TTL‑вікна,
і моніторте реальні напрямки зʼєднань. Використовуйте цільове очищення резолверів тільки якщо потрібно.
10) Чому різні публічні резолвери показують різні відповіді?
Вони могли кешувати в різний час, бути в різних регіонах, застосовувати різні політики або отримувати різні відповіді через EDNS Client Subnet чи гео‑маршрутизацію. Така різноманітність нормальна.
Наступні кроки, які можна зробити сьогодні
- Додайте «авторитетне першочергово» до вашого runbook: завжди перевіряйте NS напряму перед тим, як чіпати кеші.
- Документуйте реальний шлях резолвінгу: які резолвери використовує продакшн, де є кеші і хто ними володіє.
- Стандартизуйте інструменти: віддавайте перевагу
dig+getent+ «перевірка remote IP» замість здогадок. - Плануйте зміни TTL: знижуйте TTL заздалегідь для запланованих міграцій; не чекайте, що правка в останню хвилину виручить вас.
- Впровадьте цільове очищення: якщо ви оперуєте резолверами, підтримуйте очищення по імені. Глобальне очищення має бути дійсно погодженою дією.
DNS‑зміни «не видно» рідко містять містичну природу. Зазвичай це кешування, що робить саме те, для чого його створили,
у найневдаліший для вас момент. Ваше завдання — знайти той єдиний кеш, який має значення, і не чіпати весь решту світу.