DNS «Тимчасова помилка при розв’язуванні імен»: 5 кореневих причин та порядок виправлення

Що насправді означає помилка (і чого вона не означає)

«Temporary failure in name resolution» зазвичай означає, що userland-резолвер каже: «Я не отримав відповіді зараз».
На Linux із glibc це часто відповідає EAI_AGAIN з getaddrinfo() — тимчасова відмова при запиті.
Це відрізняється від «ім’я не існує».

Якщо хочете мислити як SRE, перекладіть повідомлення у один із цих кошиків:

• Я не можу дістатися до резолвера (шлях мережі, фаєрвол, неправильна IP-адреса, резолвер вимкнений).
• Я дійшов до резолвера, але він не відповідає (тайм-аути, UDP заблоковано, проблеми з EDNS, ліміти запитів).
• Я отримав відповідь, але клієнт її відкинув (валидація DNSSEC, усікання, блокування TCP-фолбеку, пошкоджений кеш).
• Я задав неправильне питання (search domains, ndots, сюрпризи split-horizon).

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

Одна цитата, яка варта місця на стіні:
Надія — не стратегія. — генерал Гордон Р. Салліван

5 кореневих причин (у порядку, в якому їх варто виправляти)

Швидкий план діагностики (першочергово/другорядно/третє)

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

Перше: підтвердьте, локальна це конфігурація, локальний демон чи мережа

• Перевірте, який резолвер ви використовуєте (resolv.conf, стан systemd-resolved).
• Спробуйте запитати безпосередньо на налаштований IP резолвера за допомогою dig.
• Якщо це не вдається — перевірте базову досяжність резолвера (ping — не все, але початок).

Друге: встановіть контрольний резолвер і порівняйте

• Запитайте те саме ім’я через відомо робочий резолвер (публічний або інший внутрішній).
• Якщо контроль працює — ймовірно проблема у вашому резолвері або в шляху до нього.
• Якщо контроль теж не працює — підозрюйте авторитетний DNS або ширші мережеві обмеження.

Третє: вирішіть, тайм-аути це, SERVFAIL чи поведінка клієнта

• Тайм-аути натякають на шлях мережі/фаєрвол або на перевантажений резолвер, що втрачає пакети.
• SERVFAIL натякає на провал рекурсії, проблеми DNSSEC або зламану делегацію апстріму.
• Повільно, а потім відмова натякає на розгортання search domains, ndots або блокування TCP-фолбеку.

Жарт №1: DNS — як телефонний довідник, який іноді вирішує бути збіркою поезій. Технічно — ще «текст», емоційно — марно.

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

Нижче — реальні завдання, які можна виконати на Linux-хості. Кожне містить, що означає вивід і яке рішення прийняти.
Виконуйте їх послідовно, поки не знайдете суперечності. Саме в суперечностях ховається правда.

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

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan  2 10:11 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Цей хост використовує stub-слухач systemd-resolved (127.0.0.53). Якщо systemd-resolved зупинений — DNS не працює.

Рішення: Перевірте стан systemd-resolved наступним кроком. Якщо resolv.conf — звичайний файл, перевірте його рядки nameserver безпосередньо.

Завдання 2: Перевірте nameserver-и та search domains

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

Значення: Запити можуть розширюватися через search. Короткі імена можуть спричиняти кілька запитів і затримки.

Рішення: Під час тестування завжди пробуйте FQDN і уникайте неоднозначності. Майте на увазі search domains при «повільно, а потім відмова».

Завдання 3: Перевірте стан systemd-resolved і які upstream DNS воно використовує

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

Значення: systemd-resolved активний і має upstream резолвери (10.20.30.53/54).

Рішення: Запитайте ці upstream резолвери напряму за допомогою dig @10.20.30.53. Якщо статус відсутній або пустий — спочатку виправляйте локальну конфігурацію.

Завдання 4: Переконайтеся, що локальний stub-слухач справді слухає

cr0x@server:~$ ss -ulpn | grep ':53 '
UNCONN 0      0         127.0.0.53%lo:53        0.0.0.0:*    users:(("systemd-resolve",pid=812,fd=14))

Значення: Stub-резолвер слухає на UDP 53 на loopback.

Рішення: Якщо ви цього не бачите — перезапустіть/відновіть systemd-resolved (або припиніть використовувати stub і вкажіть resolv.conf на реальні резолвери).

Завдання 5: Запитайте ім’я через системний резолвер (базово)

cr0x@server:~$ getent ahosts example.com
93.184.216.34   STREAM example.com
93.184.216.34   DGRAM  example.com
93.184.216.34   RAW    example.com

Значення: Шлях libc резолвера працює (NSS + DNS). Це ближче до того, як працюють додатки, ніж dig.

Рішення: Якщо getent не вдається, але dig працює — підозрюйте NSS-конфіг, nscd або специфічну поведінку додатку.

Завдання 6: Запитайте налаштований upstream резолвер напряму (обхід локального stub)

cr0x@server:~$ dig @10.20.30.53 example.com +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 example.com +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50612
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

;; Query time: 14 msec
;; SERVER: 10.20.30.53#53(10.20.30.53) (UDP)
;; WHEN: Tue Jan 02 10:22:48 UTC 2026
;; MSG SIZE  rcvd: 56

Значення: Upstream резолвер доступний і відповідає швидко.

Рішення: Якщо це працює, а системний резолвер падає — зосередьтеся на локальному daemon-і, NSS або поведінці search/ndots. Якщо тайм-аут — переходьте до перевірки мережевого шляху.

Завдання 7: Розрізнити тайм-аут, SERVFAIL і NXDOMAIN

cr0x@server:~$ dig @10.20.30.53 does-not-exist.example.com +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 does-not-exist.example.com +time=2 +tries=1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1243
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Значення: NXDOMAIN — це визначена відповідь «ім’я не існує». Це не «тимчасова помилка».

Рішення: Якщо ваш додаток показує «тимчасову помилку», а dig показує NXDOMAIN — підозрюйте search domains і те, що додаток запитує інше ім’я, ніж ви думаєте.

Завдання 8: Перевірте сирий шлях до IP резолвера та вибір маршруту

cr0x@server:~$ ip route get 10.20.30.53
10.20.30.53 via 10.20.10.1 dev eth0 src 10.20.10.44 uid 1000
    cache

Значення: Ядро знає, як дістатися резолвера і який інтерфейс воно використовує.

Рішення: Якщо цей маршрут неправильний (наприклад, йде через VPN-інтерфейс), ви знайшли свою «тимчасову помилку». Виправте маршрутизацію/split tunneling VPN.

Завдання 9: Доведіть, що UDP 53 працює (не лише ICMP)

cr0x@server:~$ nc -u -vz 10.20.30.53 53
Connection to 10.20.30.53 53 port [udp/domain] succeeded!

Значення: Ви можете відправити UDP на порт 53. Це не доводить, що відповіді повертаються, але дає швидкий сигнал.

Рішення: Якщо це не вдається — припиніть сперечатися про записи DNS. У вас фаєрвол, security group або проблема маршрутизації.

Завдання 10: Доведіть, що TCP 53 працює (потрібно для усічених/DNSSEC/великих відповідей)

cr0x@server:~$ nc -vz 10.20.30.53 53
Connection to 10.20.30.53 53 port [tcp/domain] succeeded!

Значення: TCP-фолбек можливий. Якщо UDP працює, але TCP ні — деякі запити «випадково» провалюватимуться, особливо з DNSSEC або великою кількістю записів.

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

Завдання 11: Виявити усікання і поведінку TCP-фолбеку

cr0x@server:~$ dig @10.20.30.53 dnssec-failed.org +dnssec +bufsize=4096

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 dnssec-failed.org +dnssec +bufsize=4096
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32801
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Значення: SERVFAIL на відомому домені з помилками DNSSEC вказує, що резолвер проводить валідацію DNSSEC.

Рішення: Якщо ваші внутрішні домени повертають SERVFAIL через DNSSEC — виправте підписування/DS-записи. Не вимикайте DNSSEC повністю, якщо не розумієте зону ураження.

Завдання 12: Прослідкуйте делегацію, щоб перевірити, чи авторитетні сервери працюють

cr0x@server:~$ dig +trace app.corp.example

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> +trace app.corp.example
.                       518400  IN      NS      a.root-servers.net.
...
example.                172800  IN      NS      ns1.example.
example.                172800  IN      NS      ns2.example.
corp.example.           86400   IN      NS      ns1.corp.example.
corp.example.           86400   IN      NS      ns2.corp.example.
app.corp.example.       60      IN      A       10.50.0.25

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

Рішення: Якщо trace падає на вашому авторитетному шарі — зосередьтеся там: фаєрвол до авторитетних серверів, зламані NS-записи, застарілі glue чи вимкнені майстери.

Завдання 13: Підтвердіть вигляд резолвера на конкретному інтерфейсі (systemd-resolved)

cr0x@server:~$ resolvectl dns eth0
Link 2 (eth0): 10.20.30.53 10.20.30.54

Значення: DNS-сервери призначаються для кожного лінку; VPN-інтерфейси можуть перевизначати це.

Рішення: Якщо невірний лінк має активні DNS-сервери — виправте налаштування NetworkManager/VPN або налаштуйте DNS routing domains коректно.

Завдання 14: Спостерігайте реальний DNS-трафік (доведіть, що пакети йдуть і відповіді повертаються)

cr0x@server:~$ sudo tcpdump -ni eth0 '(udp port 53 or tcp port 53)' -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.122334 IP 10.20.10.44.41321 > 10.20.30.53.53: 47924+ A? example.com. (29)
10:25:11.136702 IP 10.20.30.53.53 > 10.20.10.44.41321: 47924 1/0/1 A 93.184.216.34 (45)

Значення: Ви маєте двобічний трафік. Якщо бачите лише вихідні запити і жодних відповідей — проблема апстрім або шлях (ACL/security).

Рішення: Використовуйте це, щоби припинити суперечки. Пакети не брешуть; люди іноді — так.

Завдання 15: Перевірте порядок NSS (він може зробити DNS виглядом зламаним)

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

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

Рішення: Для серверів тримайте нудність: зазвичай files dns (плюс те, що реально потрібно у вашому середовищі).

Завдання 16: Знайдіть «ndots» та опції резолвера, що змінюють поведінку

cr0x@server:~$ grep '^options' /etc/resolv.conf
options edns0 trust-ad

Значення: Опції змінюють розмір пакета, поведінку trust і політику повторних спроб.

Рішення: Якщо задіяний Kubernetes — перевірте його ndots (часто 5). Великий ndots + багато search domains може створити шторм запитів і «тимчасові помилки».

Жарт №2: Єдина річ більш тимчасова, ніж «Temporary failure in name resolution», — це обіцянка «ми виправимо DNS пізніше».

Три міні-історії з корпоративного життя (анонімізовані)

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

Середня SaaS-компанія тримала пару внутрішніх рекурсивних резолверів у двох дата-центрах. Навколишні середовища девелопу також на них дивилися.
Одної п’ятниці команда розгорнула новий профіль VPN-клієнта «щоби спростити віддалений доступ». Його протестували. Він працював. Люди могли дістатися внутрішніх додатків.
Потім збірки почали падати, потім продакшн-деплої тайм-аутити при завантаженні пакетів, потім моніторинг засвітився класичним повідомленням.

Неправильне припущення: «DNS внутрішній, отже завжди правильно надсилати DNS через VPN».
Профіль прописав DNS-сервер, який доступний лише зсередини VPN — добре для ноутбуків — а потім випадково застосували той же профіль до CI-ренерів.
Ці ранери не мали VPN-інтерфейсу піднятого. Вони просто отримали новий /etc/resolv.conf, що вказував на IP, до якого ніколи не дістатися.

Інженери перші 45 хвилин дивилися на файли авторитетних зон, бо хтось побачив «name resolution» і відразу звинуватив записи.
Прорив стався, коли одна людина виконала ip route get до IP резолвера і помітила, що маршрут вів через інтерфейс, якого не існувало на цьому хості.

Виправлення було нудним: відокремити DHCP/VPN DNS-конфіг від серверної інфраструктури, заблокувати, хто може змінювати налаштування резолвера на CI,
і додати канаркову задачу, що виконує getent hosts для кількох критичних імен із пулу ранерів.
DNS не «впав». Він просто ніколи не був досяжний з потрібних машин.

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

Велике підприємство мало проблеми з продуктивністю: внутрішні резолвери обробляли величезний обсяг запитів від Kubernetes-кластерів.
Хтось зробив начебто сенсову річ: агресивно налаштував кешування і збільшив EDNS UDP-бемп (buffer) «щоби зменшити TCP-фолбеки».
Вони також увімкнули валідацію DNSSEC «бо безпека того хотіла», без уважного інвентарю внутрішніх зон.

Тиждень усе було нормально. Потім почалися періодичні відмови резолюції. Не скрізь. Лише для набору додатків, що залежали від домену партнера.
Помилка була «тимчасова помилка». Метрики резолвера показували зростання SERVFAIL для того партнерського домену, але затримки були в нормі.

Відкат: авторитетні сервера партнера неправильно обробляли великі EDNS-відповіді й іноді надсилали пошкоджені відповіді.
Раніше резолвери частіше падали на TCP-фолбек і успішно отримували відповідь. Тепер, з більшими UDP і валідацією DNSSEC, частота відмов зросла й перетворилася на SERVFAIL.
Тим часом повторні спроби Kubernetes підсилювали навантаження і робили резолвер «нестабільним».

Виправлення: зменшити EDNS buffer size до безпечнішого значення, тримати TCP 53 відкритим у всіх місцях і впровадити винятки пересилки по зоні для проблемного домену.
Урок не в «не оптимізуйте». Урок — «ставтесь до DNS як до розподіленої системи з багатьма зламаними краями».
Якщо ваша оптимізація залежить від того, що всі інші ідеальні — це не оптимізація, а новий режим відмови.

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

Фінансова організація тримала внутрішні резолвери в трьох сайтах. Нічого складного. Два інстанси на сайт. Простий health check.
Нудна частина: вони підтримували маленьку «DNS sanity» панель, яка тестувала резолюцію з кожної великої підмережі проти кожного резолвера кожну хвилину,
використовуючи UDP і TCP. Це те, чого ніхто не святкує — отже це добре інженерно.

Одного дня зміна в політиці фаєрвола заблокувала TCP 53 для підмножини підмереж додатків «бо ми ж використовуємо тільки UDP для DNS».
Більшість імен все ще резолвилися. Потім кілька критичних почали падати — саме ті з більшими відповідями і підписами DNSSEC.
Додатки повідомляли «тимчасова помилка». Команди панікували, бо відмови були спорадичні й залежали від імені.

DNS sanity панель відразу показала: UDP успішний, TCP не працює, локалізовано до набору підмереж.
Це звузило простір проблем з «може резолвер вмирає» до «певне правило фаєрвола зламало TCP 53».

Політику швидко відкотили. Без героїчних маневрів. Без захоплюючих tcpdump під час war room.
Нудна практика — тестування обох протоколів і кількох точок — перетворила післяобідню аврію на коротку незручність.

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

1) «Працює на одному сервері, але не на іншому»

Симптом: Той самий додаток, та сама підмережа, різний результат. Один хост резолвить; інший повертає «temporary failure».

Коренева причина: Різні джерела конфігурації DNS (systemd-resolved vs статичний resolv.conf, перезапис VPN, DNS на рівні лінку).

Виправлення: Порівняйте ls -l /etc/resolv.conf і resolvectl status між хостами; стандартизуйте власність і забороніть випадковим агентам переписувати конфіг резолвера.

2) «dig працює, додаток падає»

Симптом: dig повертає відповіді, але логи додатку показують тимчасові відмови.

Коренева причина: Додаток використовує шлях libc/NSS; dig — ні. Порядок NSS, nscd або розширення search/ndots можуть ламати або сповільнювати процес.

Виправлення: Тестуйте з getent ahosts; перевірте /etc/nsswitch.conf; відтворіть з FQDN; зменшіть search domains; перевірте ndots у контейнерах.

3) «Переривчасті відмови, особливо для деяких доменів»

Симптом: Деякі імена резолвляться, інші тайм-аутять; відмови залежно від домену.

Коренева причина: Блокування TCP-фолбеку, проблеми EDNS/фрагментації або нестабільність авторитетного DNS для певних зон.

Виправлення: Перевірте TCP 53 наскрізь; запустіть dig +trace; подумайте про зменшення EDNS buffer size на резолверах; підтвердіть, що фаєрвол дозволяє фрагменти UDP або дозвольте TCP.

4) «Все падає відразу після перезавантаження / деплою»

Симптом: Після рестарту багато тайм-аутів; пізніше стабілізується.

Коренева причина: Шторм кеш-промахів проти невеликого пулу резолверів; вичерпання CPU/сокетів резолвера.

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

5) «Лише всередині контейнерів / лише в подах Kubernetes»

Симптом: Нода резолвить; под — падає з тимчасовою помилкою.

Коренева причина: Cluster DNS (CoreDNS) впав, upstream forwarding зламався, ndots + search domains генерують шторм запитів або мережеві політики блокують DNS.

Виправлення: Запитайте IP сервісу CoreDNS напряму з пода; перевірте мережеві політики для UDP/TCP 53; за необхідності зменште ndots; переконайтеся, що node-local кеш (якщо є) здоровий.

6) «VPN-користувачі у порядку, офісні користувачі зломані (або навпаки)»

Симптом: Розв’язування залежить від того, чи ви в VPN.

Коренева причина: Split-horizon DNS або неправильна конфігурація split tunneling; невірний резолвер для контексту мережі.

Виправлення: Використовуйте маршрутизацію за доменом (DNS routing domains) замість одного глобального резолвера; переконайтеся, що резолвери доступні з кожного сегмента мережі.

7) «SERVFAIL для внутрішніх доменів після увімкнення DNSSEC»

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

Коренева причина: Зламаний ланцюг DNSSEC (неправильний DS, прострочені підписи, невідповідність ключів) або внутрішні зони не готові до валідації.

Виправлення: Виправте підписування коректно або вимкніть валідацію тільки для конкретних внутрішніх зон через політику резолвера. Масове відключення — і безпековий, і надійності фолґан.

Чеклісти / покроковий план

Чекліст A: Одиночний хост з «тимчасовою помилкою»

1. Визначте, який резолвер використовують: ls -l /etc/resolv.conf і cat /etc/resolv.conf.
2. Якщо використовується systemd-resolved: resolvectl status і ss -ulpn | grep ':53 '.
3. Протестуйте шлях libc: getent ahosts example.com.
4. Протестуйте доступність резолвера напряму: dig @<resolver-ip> example.com +time=2 +tries=1.
5. Відрізніть тип відмови: тайм-аут, SERVFAIL чи NXDOMAIN?
6. Перевірте мережевий шлях: ip route get <resolver-ip>, потім перевірте UDP і TCP 53.
7. Доведення на рівні пакетів, якщо потрібно: tcpdump щоб побачити запити і відповіді.
8. Лише потім дивіться апстрім або авторитетний DNS за допомогою dig +trace.

Чекліст B: Багатохостовий інцидент / режим інциденту

1. Виберіть три точки огляду: один хост, що падає; один здоровий хост; один хост в іншій підмережі.
2. Порівняйте конфігурацію резолверів між ними.
3. Виберіть два тестові імені: одне внутрішнє критичне, одне зовнішнє стабільне.
4. Опитайте через налаштований резолвер і через контрольний резолвер.
5. Шукайте шаблони: лише AAAA відмовляє? лише великі відповіді? лише певні домени?
6. Перевірте метрики/логи резолвера, якщо ви ним володієте (qps, латентність, SERVFAIL rate, пам’ять, дескриптори файлів).
7. Підтвердіть зміни фаєрвола для UDP/TCP 53 та проблеми з MTU/фрагментацією.
8. Комунікуйте чітко: «Тайм-аути до IP резолвера з підмережі X» краще за «DNS здається нестабільним».

Резюме порядку виправлення (надрукуйте це в умі)

1. Власність і коректність конфіг клієнта (який резолвер я використовую?)
2. Шлях до резолвера (маршрути + фаєрвол, UDP і TCP)
3. Здоров’я резолвера та поведінка рекурсії/пересилки
4. Клієнтська поведінка: search/ndots/NSS, що викликає повтори та затримки
5. Авторитетний DNS і коректність делегації/DNSSEC

Цікаві факти та історичний контекст (в DNS є своя легенда)

• DNS замінив біль від HOSTS.TXT: ранні мережі використовували один файл hosts, розісланий усім; він не масштабувався з ростом мереж.
• Пол Моккапетріс спроєктував DNS у 1983, запровадивши розподілену ієрархічну систему імен, що використовується дотепер.
• UDP вибрали за швидкість, але TCP завжди був у протоколі для великих відповідей і передач зоун.
• Резолвери кешують і «ні»: негативне кешування існує, щоб зменшити навантаження від повторних промахів, що робить опечатки стійкими.
• TTL має рекомендаційний характер, але потужний: агресивні зміни TTL можуть посилити трафік і спричинити шторм кеш-промахів під час відмов або розгортань.
• EDNS (Extension mechanisms for DNS) прийшов, щоб розширити DNS без заміни, включаючи більші UDP-повідомлення — також джерело проблем з фрагментацією.
• DNSSEC додає автентичність, але також розмір і складність; помилки валідації часто проявляються як SERVFAIL, а не як чітке пояснення.
• «Lame delegation» — реальний термін: означає, що nameserver зазначено для зони, але він не може авторитетно відповісти за неї.
• Search domains створювалися для зручності в підприємствах, але в масштабі вони множать обсяг запитів і затримки драматично.

Питання та відповіді (FAQ)

1) Чи означає «Тимчасова помилка при розв’язуванні імен» завжди відмову DNS-сервера?

Ні. Часто це локальна проблема: неправильний резолвер налаштовано, systemd-resolved впав або мережевий шлях/фаєрвол блокує.
Вважайте це «спроба резолюції провалилася», а не «DNS-записи неправильні».

2) Чому перезапуск сервісу іноді допомагає?

Бо ви можете очистити кеш, відновити сокети або змінити таймінги. Це не коренева причина; це підміна з кращим маркетингом.
Використовуйте рестарти лише як тимчасовий захід, доки збираєте докази (dig/getent/tcpdump).

3) У чому різниця між NXDOMAIN і цією помилкою?

NXDOMAIN означає, що ім’я не існує в DNS (авторитетна негативна відповідь). «Тимчасова помилка» зазвичай означає тайм-аути або SERVFAIL під час рекурсії.
Вони вимагають різних дій: NXDOMAIN — конфіг/опечатка; тимчасова помилка — це мережа/здоров’я/делегація.

4) Чому працює з dig, але не з curl або моїм додатком?

dig звертається напряму до DNS. Багато додатків використовують libc-резолвер через NSS, який може звертатися до files, mDNS, LDAP чи інших джерел спочатку,
і застосовувати search domains та політики повторів. Тестуйте з getent ahosts, щоб імітувати поведінку додатка.

5) Як дізнатися, чи проблема в UDP чи TCP?

Протестуйте обидва. Використайте nc -u -vz <resolver> 53 і nc -vz <resolver> 53, потім підтвердіть через tcpdump.
Якщо TCP 53 заблоковано — великі DNS-відповіді будуть падати непередбачувано.

6) Чи може MTU або фрагментація спричиняти «тимчасову помилку»?

Так. Великі UDP-відповіді DNS можуть фрагментуватися. Якщо фрагменти втрачаються (поширене в тунелях і деяких фаєрволах), ви отримаєте тайм-аути.
Це виглядає «тимчасово», бо малі відповіді все ще проходять. Дозвольте TCP 53 і подумайте про безпечніший EDNS UDP-розмір на резолверах.

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

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

8) Чому Kubernetes погіршує ситуацію?

Kubernetes часто використовує кілька search domains і високий ndots, що множить DNS-запити на один lookup.
Під час часткових проблем із DNS це множення підсилює навантаження. Виправляйте здоров’я CoreDNS, дозволяйте UDP/TCP 53
і свідомо налаштовуйте ndots/search.

9) Чи варто просто зашити IP-адреси, щоб уникнути відмов DNS?

Зашивання перетворює динамічну систему на крихку. Ви ухиляєте одну форму відмови і купуєте три нові: застарілі кінцеві точки, зламаний failover і складні ротації.
Якщо DNS ненадійний — виправте шар резолвера і моніторинг. Не вирізайте проблему в камінь.

10) Який моніторинг реально ловить це раніше?

Мультивидові перевірки DNS проти кожного резолвера, для UDP і TCP, для невеликого набору критичних імен (внутрішніх і зовнішніх).
Відстежуйте перцентилі латентності та частки SERVFAIL/timeout. Алертуйте за трендом, а не лише за тотальною відмовою.

Висновок: практичні наступні кроки

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

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

• Стандартизувати власність DNS на хостах (вирішіть: systemd-resolved, NetworkManager або статичний; не «усі разом»).
• Переконатися, що і UDP, і TCP 53 дозволені між клієнтами і резолверами, та між резолверами і апстрімами.
• Додати просту перевірку DNS sanity з ключових підмереж (UDP + TCP) і трактувати зростання SERVFAIL/тайм-аутів як раннє попередження.
• Аудитувати search domains і ndots у контейнерних платформах; зменшити множення запитів, перш ніж воно позбавить вас сну.
• Коли наступний інцидент трапиться — використовуйте план: доведіть, де пакети зупиняються, а потім виправте той шар — без DNS-сеансів.