DNS: NXDOMAIN vs SERVFAIL — швидкий спосіб визначити, що не працює (і виправити це)

December 28, 2025 • February 3, 2026 • Читання: 8 хв • Views: 7

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

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

Найшвидший спосіб повернути свій час — припинити трактувати кожну помилку DNS як невизначений настрій. NXDOMAIN і SERVFAIL — це різні типи відмов. Вони вказують на різні зламані компоненти, якими відповідають різні команди, і їх виправляють різними діями.

NXDOMAIN vs SERVFAIL: two codes, two failure worlds

NXDOMAIN в одному реченні

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

SERVFAIL в одному реченні

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

Прискорена інтерпретація для продакшну: що зазвичай означає кожен код

NXDOMAIN: найчастіше проблема з даними/конфігом (неправильне ім’я, відсутній запис, невірна зона, невідповідність у split-horizon, застарілий негативний кеш). Система працює; вона каже вам «ні».
SERVFAIL: найчастіше проблема шляху/валідації/доступності (резолвер не може дістатися до авторитету, авторитет некоректно поводиться, ланцюг DNSSEC пошкоджений, рекурсія блокується, MTU/фрагментація, проблеми з EDNS). Система не дає успішної відповіді.

Ось і вся суть. NXDOMAIN спрямовує вас до питання «чи існує це ім’я там, де я думаю, що воно існує?» SERVFAIL — до питання «чому резолвер не може коректно завершити розв’язування?»

Жарт №1: DNS — як телефонна книга, яка може відповісти «такої людини нема» або «я сьогодні не в гуморі» — і обидва варіанти однаково псують ваші вихідні.

Що робити негайно при кожному з випадків

Якщо це NXDOMAIN:

Підтвердіть правопис і повне доменне ім’я (FQDN). Не смійтеся; зробіть це.
Перевірте, чи існує запис в авторитетній зоні (а не лише в вашому IaC-репозиторії).
Перевірте, чи ви запитуєте правильний вигляд (публічний vs внутрішній / split-horizon).
Перевірте негативний кеш (поле SOA minimum / negative TTL), якщо ви щойно створили запис.

Якщо це SERVFAIL:

Перевірте, чи резолвер дає помилку для всіх або лише для вас (локальний stub vs корпоративний recursive vs публічні резолвери).
Перевірте валідацію DNSSEC: спробуйте з валідацією і без, щоб відокремити проблему.
Перевірте стан делегації: записи NS, glue, доступність і чи не «lame» авторитети.
Перевірте транспортні аномалії: UDP-фрагментація, розмір EDNS, правила брандмауера, rate limiting.

Fast diagnosis playbook (what to check first)

Це «у мене п’ять хвилин до того, як канал інцидентів перетвориться на перформанс». Дотримуйтесь порядку. Зупиніться, коли знайдете вузьке місце.

Крок 1: Відтворіть через `dig` і зафіксуйте точну помилку

Використайте dig з +norecurse і з увімкненою рекурсією, і зафіксуйте status:, flags: та SERVER:.
Рішення: якщо статус — NXDOMAIN, переходьте до «дані і зона». Якщо SERVFAIL, переходьте до «шлях і валідація».

Крок 2: Змініть резолвер, щоб локалізувати місце збою

Запитайте ваш звичний резолвер, потім відомий хороший публічний резолвер, потім безпосередньо авторитетний сервер.
Рішення: якщо публічний працює, а корпоративний — ні, це ваша рекурсія/egress/DNSSEC-політика. Якщо авторитетний не відповідає — проблема в зоні/авторитеті.

Крок 3: Визначте авторитетні сервери і протестуйте їх індивідуально

Використайте dig NS і запитайте кожний NS за конкретним записом.
Рішення: якщо один NS відрізняється — у вас проблема з propagation або hidden-master/transfer. Якщо всі відмовляють — проблема глобальна для зони.

Крок 4: Якщо SERVFAIL — зробіть DNSSEC split тест

Використайте +dnssec і також спробуйте вимкнути валідацію на валідаційному резолвері (або використайте невалідаційний резолвер, яким керуєте).
Рішення: якщо при вимкненій валідації все працює — у вас проблема ланцюга DNSSEC (DS mismatch, прострочені підписи, відсутній DNSKEY, проблеми з NSEC/NSEC3 тощо).

Крок 5: Перевірте кешування і поведінку TTL

Якщо ви щойно виправили — і все ще не працює, скиньте кеші, де можете (локальний stub, recursive resolver) або дочекайтеся закінчення негативного TTL.
Рішення: якщо авторитет правильно відповідає, а клієнти все одно бачать NXDOMAIN/SERVFAIL — ви в зоні кешування.

Крок 6: Шукайте мережеві обмеження, які виглядають як «DNS впав»

Тестуйте доступність UDP/53 і TCP/53. Слідкуйте за ICMP frag-needed. Перевірте логі брандмауера, NAT timeouts і egress allowlists.
Рішення: якщо TCP працює, а UDP — ні (або навпаки), виправляйте мережу. DNS тут лише кур’єр.

How DNS gets to NXDOMAIN or SERVFAIL (without the fairy tale)

Розв’язування DNS — це ланцюг відповідальностей. Ваш застосунок зазвичай питає stub resolver (часто на хості), який питає recursive resolver (корпоративний DNS, ISP або публічний резолвер), який опитує authoritative servers по ієрархії.

NXDOMAIN: авторитетне «ні» (або переконливе «ні»)

NXDOMAIN повертається, коли відповідач вважає, що імені не існує. У правильному світі це надходить від авторитетного сервера для зони, підкріплене доказами (SOA в розділі AUTHORITY, можливо NSEC/NSEC3 з DNSSEC).

Але в продакшні NXDOMAIN також може бути:

Split-horizon mismatch: внутрішній вигляд каже «немає такого імені», а публічний має його (або навпаки).
Помилки через search suffix: клієнт запитав api, а резолвер пробував api.corp.example, отримав NXDOMAIN, і ваш лог показав «api не існує».
Негативне кешування: резолвер закешував NXDOMAIN; ви створили запис; всі бачать NXDOMAIN до закінчення negative TTL.
Взаємодія з wildcard: ви думали, що wildcard покриває це; він не покриває всі типи або всі етикетки так, як ви припускали.

SERVFAIL: резолвер відмовляється брехати

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

Поширені шляхи до SERVFAIL:

DNSSEC validation failure: резолвер отримав відповідь, але підписи не пройшли валідацію. Він повертає SERVFAIL клієнту.
Timeouts і недоступні авторитети: рекурсія не може зв’язатися з авторитетними серверами через правила брандмауера, DDoS-захист, зламані anycast-маршрути або просто мертві nameserver-и.
Lame delegation: записи NS вказують на сервери, що фактично не є авторитетними для зони. Резолвери витрачають час; деякі повертають SERVFAIL.
Truncation і проблеми з TCP: великі DNS-відповіді (DNSSEC їх збільшує) обрізаються по UDP, потім TCP/53 блокується — і виникають відмови.
EDNS/фрагментація: розміри буфера EDNS, PMTU blackhole або middlebox-и, що «допомагають», відкидаючи фрагментовані UDP-пакети.

Жарт №2: SERVFAIL — це DNS, що каже «Я міг би розповісти, але тоді мені б довелося тебе валідувати».

Корисна ментальна модель: «Де зберігається істина і хто не може її дістати?»

Авторитетні сервери зберігають істину. Рекурсивні резолвери дістають, валідують і кешують цю істину. NXDOMAIN — зазвичай проблема істини. SERVFAIL — зазвичай проблема її отримання/валідації.

Facts and history that actually help during incidents

Це не факти для вікторини. Вони змінюють підхід до налагодження.

NXDOMAIN визначено як RCODE 3. Це не «немає даних». «Немає даних» — це зазвичай NOERROR з порожнім ANSWER (часто зване NODATA).
SERVFAIL — це RCODE 2. Він навмисно нечіткий: охоплює багато внутрішніх помилок, включно з таймаутами вище по ланцюгу і помилками валідації DNSSEC.
Негативне кешування стандартизовано. Резолвери кешують NXDOMAIN і NODATA відповідно до значень SOA зони (зазвичай поле SOA minimum / negative TTL), саме тому «я щойно додав запис» може ще виглядати як помилка.
DNS спочатку розроблявся для UDP. TCP існує для передач зон і обрізаних відповідей, але реальні мережі часто підозріло ставляться до TCP/53. Це рецепт для SERVFAIL, коли відповіді стають великими.
DNSSEC зробив відповіді більшими і налагодження гострішим. Помилки валідації часто проявляються як SERVFAIL на резолвері, навіть коли авторитетні сервери нормально віддають дані.
«Lame delegation» — класичний режим відмови. Делегування на DNS-сервери, які фактично не обслуговують зону, витрачає час резолверів і збільшує хвостову латентність — іноді до SERVFAIL.
EDNS(0) був доданий, щоб розширити DNS без ламання. Middlebox-и іноді ламають EDNS, що призводить до дивних явищ: таймаутів, циклів truncation або SERVFAIL залежно від логіки резолвера.
Інфраструктура кореня і TLD еволюціонувала для зменшення крихкості. Anycast і множинні NS покликані підвищувати доступність, але також можуть приховувати часткові збої, поки зміна маршруту їх не виявить.
Search domains (resolv.conf) — корпоративний ножик у спині. Вони створюють запити, яких ви не очікували. Для налагодження використовуйте повні доменні імена, щоб уникнути хибних NXDOMAIN.

Одна парафразована ідея, яку варто пам’ятати: якщо ви проектуєте систему так, ніби відмови — це норма, ви менше часу витрачатимете на те, щоб робити вигляд, що вони рідкісні — перефразовано з думки Вернера Вогельса (CTO Amazon).

Practical tasks: commands, outputs, decisions (12+)

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

Task 1: Get the basic status and confirm which resolver answered

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

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

;; QUESTION SECTION:
;api.example.com.            IN      A

;; AUTHORITY SECTION:
example.com.         300     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

;; Query time: 21 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Wed Dec 31 10:12:01 UTC 2025
;; MSG SIZE  rcvd: 115

Значення: Ваш рекурсивний резолвер на 10.10.0.53 повертає NXDOMAIN. Також видно SOA, що підказує — резолвер вважає, ніби має авторитетне або закешоване підтвердження відсутності.

Дії: Не поспішайте шукати мережеві причини. Перевірте, чи існує api.example.com в авторитетній зоні і чи ви запитуєте правильний DNS-view.

Task 2: Compare against a different recursive resolver

cr0x@server:~$ dig @1.1.1.1 api.example.com A

; <<>> DiG 9.18.24 <<>> @1.1.1.1 api.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.com.     60      IN      A       203.0.113.10

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; Query time: 18 msec

Значення: Публічна рекурсія повертає валідний A-запис; ваш корпоративний резолвер повертає NXDOMAIN. Це не «DNS впав». Це політика/вигляд/кеш на вашому боці.

Дії: Перевірте конфігурацію split-horizon, правила форвардингу, RPZ/блоклісти або застарілий негативний кеш на корпоративному резолвері.

Task 3: Force a fully qualified name to avoid search-domain lies

cr0x@server:~$ dig api A

; <<>> DiG 9.18.24 <<>> api A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1204
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;api.                          IN      A

;; AUTHORITY SECTION:
.                       86400   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2025123100 1800 900 604800 86400

Значення: Ви запитували api. (буквально верхній рівень), а не api.example.com. Додатки і люди помилково роблять такі запити через search suffix або відсутню крапку.

Дії: Використовуйте FQDN у конфігураціях. Під час налагодження завжди запитуйте повне ім’я з крапкою в кінці, якщо хочете бути педантичними: api.example.com.

Task 4: Check if it’s NXDOMAIN vs NODATA (NOERROR, empty answer)

cr0x@server:~$ dig www.example.com AAAA

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

;; AUTHORITY SECTION:
example.com.         300     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

Значення: Ім’я існує, але AAAA-запису немає. Це не NXDOMAIN, і спосіб виправлення інший.

Дії: Якщо ваш застосунок вимагає IPv6 — додайте AAAA або змініть поведінку клієнта. Якщо ні — ігноруйте і не будіть себе дзвінком.

Task 5: Find the authoritative nameservers (and whether delegation looks sane)

cr0x@server:~$ dig example.com NS +noall +answer

example.com.     172800  IN  NS  ns1.example.net.
example.com.     172800  IN  NS  ns2.example.net.

Значення: Це сервери, до яких світ звертається за example.com.

Дії: Запитайте кожний NS безпосередньо за записом. Якщо відповіді різняться — ймовірно проблема синхронізації зони.

Task 6: Query the authoritative server directly to confirm reality

cr0x@server:~$ dig @ns1.example.net api.example.com A +norecurse

; <<>> DiG 9.18.24 <<>> @ns1.example.net api.example.com A +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33201
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.com.     60      IN      A       203.0.113.10

Значення: Авторитет стверджує, що запис існує і помічає відповідь як авторитетну (aa). Якщо ваш рекурсивний резолвер дає NXDOMAIN — проблема в кешуванні, фільтрації, split-horizon або зламаному ланцюгу форвардингу.

Дії: Розслідуйте рекурсивний резолвер: стан кешу, RPZ, views, forwarding та поведінку DNSSEC.

Task 7: Check for lame delegation

cr0x@server:~$ dig @ns2.example.net example.com SOA +norecurse

; <<>> DiG 9.18.24 <<>> @ns2.example.net example.com SOA +norecurse
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9012
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Значення: Сервер, вказаний як NS, відмовляється відповідати авторитетно. Це проблема делегації (або ACL), і резолвери можуть отримувати SERVFAIL під навантаженням або через невдалий вибір сервера.

Дії: Виправте записи NS, щоб вони вказували на реальні авторитетні сервери, або налаштуйте ACL на сервері так, щоб він відповідав за зону.

Task 8: Check DNSSEC at the resolver boundary

cr0x@server:~$ dig secure.example.com A +dnssec

; <<>> DiG 9.18.24 <<>> secure.example.com A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4411
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)

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

Дії: Порівняйте з резолвером, відомим як коректно валідуючий, і перегляньте ланцюг DS/DNSKEY/RRSIG для зони.

Task 9: Use `+trace` to watch delegation step-by-step

cr0x@server:~$ dig secure.example.com A +trace

; <<>> DiG 9.18.24 <<>> secure.example.com A +trace
.                       518400  IN  NS  a.root-servers.net.
...
com.                    172800  IN  NS  a.gtld-servers.net.
...
example.com.             172800  IN  NS  ns1.example.net.
example.com.             172800  IN  NS  ns2.example.net.
secure.example.com.      60      IN  A   203.0.113.20

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

Дії: Якщо trace ламається на делегації TLD — перевіряйте NS/DS у реєстратора. Якщо на ваших NS — виправляйте авторитетну інфраструктуру.

Task 10: Check TCP fallback (truncation problems)

cr0x@server:~$ dig dnssec-heavy.example.com DNSKEY +dnssec +ignore +bufsize=4096

; <<>> DiG 9.18.24 <<>> dnssec-heavy.example.com DNSKEY +dnssec +ignore +bufsize=4096
;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20031
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Значення: Відповідь не вмістилася в UDP, тому резолвер повторив через TCP. Якщо TCP/53 блокується десь по шляху — клієнти можуть бачити SERVFAIL або таймаути.

Дії: Переконайтеся, що TCP/53 дозволений між рекурсивними резолверами і авторитетними серверами (а іноді й між клієнтами і резолверами, залежно від архітектури).

Task 11: Confirm what your host is actually using for DNS

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: corp.example

Значення: Ваш systemd-resolved stub форвардить на корпоративні резолвери і додає corp.example як search domain.

Дії: Якщо бачите дивні запити — вимкніть або обмежте search domains для критичних сервісів. Також перевірте, чи обидва перелічені DNS-сервери поводяться однаково.

Task 12: Detect “one resolver is sick” by querying both explicitly

cr0x@server:~$ dig @10.10.0.53 api.example.com A +time=1 +tries=1

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31990
;; Query time: 1001 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)

cr0x@server:~$ dig @10.10.0.54 api.example.com A +time=1 +tries=1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31991
;; ANSWER SECTION:
api.example.com. 60 IN A 203.0.113.10

Значення: Один рекурсивний резолвер дає збій; інший працює. Це частіше, ніж хотілося б: поганий кеш, застряглий upstream, CPU thrash, зламаний стан DNSSEC.

Дії: Виключіть поганий резолвер з ротації (через DHCP option, load balancer, Anycast withdrawal), потім відлагоджуйте його офлайн.

Task 13: Check BIND/unbound logs for validation and upstream errors

cr0x@server:~$ sudo journalctl -u unbound --since "10 minutes ago" | tail -n 10

Dec 31 10:05:22 resolver1 unbound[1321]: info: validation failure <secure.example.com. A>: signature expired
Dec 31 10:05:22 resolver1 unbound[1321]: info: resolving secure.example.com. A
Dec 31 10:05:22 resolver1 unbound[1321]: info: error: SERVFAIL secure.example.com. A IN

Значення: Резолвер явно повідомляє, що підпис DNSSEC прострочена. Це один із найчистіших кореневих причин SERVFAIL, який ви можете отримати.

Дії: Виправте підписування зони (re-sign, перевірте синхронізацію часу на підписувачі, забезпечте автоматичні ролловери). Тимчасова міра: спрямувати критичних клієнтів на резолвер, що не валідуює (обережно), але ставте це як аварійний пласт, а не постійне рішення.

Task 14: Confirm authoritative server health and zone loading

cr0x@server:~$ sudo rndc status

version: BIND 9.18.24 (Stable Release)
running on ns1: Linux x86_64 6.5.0
boot time: Wed, 31 Dec 2025 08:12:07 GMT
last configured: Wed, 31 Dec 2025 09:58:41 GMT
number of zones: 128
debug level: 0
xfers running: 0
up time: 1h 59m

Значення: BIND працює і явно не перевантажений. Це не доводить правильність зони, але викреслює «named упав» зі списку кандидатів.

Дії: Якщо підозрюєте помилки завантаження зони — перевірте логи і підтвердіть серіал та записи зони.

Task 15: Verify the zone serial and whether secondaries are in sync

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123009 7200 3600 1209600 300

Значення: Серіали відрізняються. Один nameserver віддає старішу зону. Це може проявлятися як періодичний NXDOMAIN (залежно від того, який NS вибере резолвер).

Дії: Виправте zone transfers (TSIG keys, allow-transfer ACLs, notify configuration, мережеву доступність). Не робіть «eventual consistency DNS», якщо не любите загадкові відмови.

Three corporate mini-stories (and what they teach)

Інцидент 1: Відмова через неправильне припущення (NXDOMAIN, замаскований під «мережу»)

У середній компанії з гібридним хмарним набором команда мігрувала внутрішній сервіс з api.int.corp на api.internal.corp. Вони зробили ввічливі речі: оновили service discovery, змінили кілька конфігів, змерджили PR і пішли далі.

Потім on-call отримав алерт: «Сервіс недоступний». Логи застосунку показували повторні NXDOMAIN для api.int.corp. On-call припустив, що з резолвером щось не так, бо «NXDOMAIN означає, що DNS не може знайти, отже DNS впав». Це припущення коштувало години.

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

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

Урок: NXDOMAIN часто — сигнал, що DNS робить свою роботу. Коли бачите NXDOMAIN — спочатку підозрюйте ваші входи: імена, зони, вигляди та кеші. Не «перезавантажуйте DNS», щоб виправити опечатку, вшиту в 200 вузлів.

Інцидент 2: Оптимізація, що обернулась проти (SERVFAIL через DNSSEC + «менші пакети»)

Команда хотіла швидший DNS. Вони підкрутили рекурсивні резолвери: зменшили UDP buffer size, агресивні timeouts і кілька «нам це не потрібно» EDNS-настроювань, знайдених на старому форумі. Графіки тішили місяць: латентність менша, дашборди зелені. Усі кивали визнано.

Потім партнер увімкнув DNSSEC на зоні, від якої залежала компанія. Раптом частина запитів почала повертати SERVFAIL. Не всі. Достатньо, щоб зламати логіни клієнтів у одній географії і поставити під сумнів реальність у інцидент-менеджера.

Причина була не в партнері, а в «оптимізації»: зменшений EDNS buffer спричинив більше truncation, що примусило fallback на TCP. Але вихід на TCP/53 з тих резолверів був непослідовно дозволений через NAT-шлюзи. Іноді це працювало; іноді ні. Резолвери, що не могли завершити валідацію, повертали SERVFAIL. DNSSEC-зміни партнера просто зробили пакети достатньо великими, щоб натрапити на пастку.

Виправлення було немодним: відкотити EDNS-правки, уніфікувати політику брандмауерів для дозволу TCP/53 від рекурсивних резолверів і встановити таймаути на основі реальних upstream-поведінок, а не ідеології. Додали канар-перевірку, яка спеціально запитує DNSSEC-важкий запис, щоб контролювати TCP-fallback.

Урок: «Оптимізації» DNS, що ігнорують весь протокол (UDP і TCP, EDNS, DNSSEC), — це просто часові бомби з кращою метрикою.

Інцидент 3: Нудна практика, яка врятувала день (послідовні перевірки делегації)

Велике підприємство підтримувало свій авторитетний DNS плюс керований secondary-провайдер. Кожна зміна проходила через чекліст: оновити зону, інкрементувати серіал, перевірити синтаксис, запушити на hidden master, підтвердити, що secondaries отримали новий серіал, а потім запустити зовнішню перевірку делегації з щонайменше двох мереж.

Одного дня під час проекту консолідації доменів реєстратор змінив NS. Зміна нормальна — але один із нових nameserver-ів ще не почав обслуговувати зону. Lame delegation: класика.

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

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

Common mistakes: symptom → root cause → fix

1) «NXDOMAIN для запису, який ми щойно створили»

Симптом: dig повертає NXDOMAIN для імені, яке ви додали кілька хвилин тому.

Корінь проблеми: негативне кешування на рекурсивних резолверах (закешований NXDOMAIN), або ви оновили тільки один view/зону (внутрішню vs публічну), або secondaries не синхронізовані.

Виправлення: Запитайте авторитет безпосередньо, щоб підтвердити існування запису. Перевірте SOA serial на кожному NS. Якщо авторитет правильний — дочекайтеся negative TTL або скиньте кеші там, де контролюєте.

2) «Періодичний NXDOMAIN»

Симптом: іноді резолвиться, іноді — NXDOMAIN.

Корінь проблеми: split-brain авторитетний набір (деякі NS мають запис, інші — ні), або anycast-нод-ки дають різні версії зони.

Виправлення: Запитайте кожний авторитетний NS напряму. Порівняйте SOA serial. Виправте transfer/notify і забезпечте атомарне розгортання по авторитетних нодах.

3) «SERVFAIL від корпоративного DNS, але публічні резолвери працюють»

Симптом: dig @10.10.0.53 повертає SERVFAIL; dig @1.1.1.1 працює.

Корінь проблеми: помилка валідації DNSSEC через застарілі trust anchors, зламану синхронізацію часу на резолверах, політики фільтрації (RPZ) або блокування TCP/53, що перешкоджає завершенню валідації.

Виправлення: Перевірте логи резолвера на помилки валідації. Переконайтеся, що NTP коректний. Перевірте egress для TCP/53. Перегляньте RPZ-хіти і виключення.

4) «SERVFAIL лише для доменів з DNSSEC»

Симптом: деякі зони завжди дають SERVFAIL, інші — ні.

Корінь проблеми: проблеми ланцюга DNSSEC (прострочені RRSIG, DS mismatch після ролловера ключів, неправильний DNSKEY).

Виправлення: Використайте dig +trace +dnssec і порівняйте DS у батька з DNSKEY у дочірньому. Перепідпишіть зону або виправте DS у реєстратора/батька.

5) «Все падає в Kubernetes, але ноди резолвлять»

Симптом: поди бачать SERVFAIL/NXDOMAIN; хост резолвить нормально.

Корінь проблеми: некоректний upstream у CoreDNS, проблеми з NodeLocal DNSCache, правила iptables або відмінності stub resolver-ів.

Виправлення: Запитайте зсередини пода на IP сервісу CoreDNS і upstream. Перевірте логи CoreDNS, configmap і мережеві політики для UDP/TCP 53.

6) «NOERROR але застосунок каже ‘host not found’»

Симптом: DNS повертає NOERROR без відповідей; застосунок падає.

Корінь проблеми: ви запитували тип запису, якого немає (AAAA vs A), або застосунок вимагає SRV/TXT, а ви перевіряли тільки A.

Виправлення: Запитуйте точні типи записів, які використовує застосунок. Для сучасного service discovery перевіряйте SRV/TXT і поведінку бібліотеки клієнта.

7) «Спайки SERVFAIL після включення DDoS-захисту»

Симптом: раптові SERVFAIL під навантаженням або після змін безпеки.

Корінь проблеми: rate limiting або правила брандмауера, що відкидають фрагменти, блокують TCP/53 або відкидають EDNS-трафік.

Виправлення: Перевірте шляхи UDP і TCP. Налаштуйте rate limits. Якщо потрібно фільтрувати — робіть це свідомо і тестуйте на DNSSEC-важких відповідях.

8) «NXDOMAIN для внутрішнього імені з ноутбуків по VPN»

Симптом: на VPN не працює; поза VPN працює (або навпаки).

Корінь проблеми: split DNS не коректно передається через VPN, або вигляди резолверів залежать від діапазонів IP-джерела.

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

Checklists / step-by-step plan

Чекліст A: Коли ви бачите NXDOMAIN

Підтвердіть точний FQDN, який запитується (включно з поведінкою trailing dot і search suffix).
Запитайте авторитетний сервер напряму для потрібного типу запису (A, AAAA, CNAME, SRV).
Перевірте split-horizon: опитайте зсередини і ззовні мереж; опитайте внутрішні і публічні авторитети.
Перевірте SOA serial на кожному авторитетному NS; підтвердіть їх збіг.
Якщо запис щойно створено/змінено — врахуйте негативне кешування: дочекайтеся або скиньте кеші, які контролюєте.
Переконайтеся, що ви не опублікували лише CNAME без його цілі, або не опублікували запис у невірній зоні.
Виправляйте у джерелі істини (zone file / DNS provider), а не в випадкових резолверах.

Чекліст B: Коли ви бачите SERVFAIL

Визначте, який резолвер повертає SERVFAIL (локальний stub, корпоративний recursive, публічний).
Опитайте те саме ім’я через кілька резолверів, щоб ізолювати область проблеми.
Запустіть dig +trace, щоб побачити, де ламається ланцюг.
Тестуйте авторитетні сервери індивідуально; шукайте таймаути, REFUSED або непослідовні відповіді.
Розслідуйте DNSSEC: порівняйте DS і DNSKEY, перевірте прострочені підписи, підтвердіть синхронізацію часу на підписувачах і резолверах.
Перевірте UDP і TCP поведінку (truncation і fallback). Переконайтеся, що TCP/53 не блокується.
Перегляньте логи резолвера на помилки валідації, upstream timeouts або попередження про «lame delegation».
Міграція: переключіть клієнтів на здорові резолвери, виведіть з ладу зламані anycast-ноди або тимчасово вимкніть валідацію лише там, де розумієте ризик.

Покроковий план: «відновити сервіс спочатку, потім виправити причину»

Стабілізація: якщо один резолвер падає — виведіть його з ротації. Якщо один авторитетний зламаний — тимчасово видаліть його з NS-набору (обережно) або швидко виправте.
Підтвердження істини: опитайте авторитетні джерела напряму. Визначте, чи запис існує і чи постійний стан на всіх NS.
Виправлення коректності: для NXDOMAIN — виправте дані зони. Для SERVFAIL — виправте доступність/валідацію/делегацію.
Виправлення пропагації: переконайтеся, що zone transfers завершуються, серіали інкрементуються, і кеші або витікають, або скидаються.
Запобігання повторенню: додайте перевірки делегації, моніторинг закінчення терміну DNSSEC, тести досяжності TCP/53 та канарки з різних мереж.

FAQ

1) Чи NXDOMAIN завжди є авторитетною відповіддю?

Ні. Він має відображати авторитетну відсутність, але ви можете бачити NXDOMAIN від рекурсивних кешів, RPZ-політик або неправильного DNS view. Завжди перевіряйте через авторитетний NS напряму.

2) У чому різниця між NXDOMAIN і «no answer»?

NXDOMAIN означає, що ім’я не існує. «No answer» зазвичай — NOERROR з порожнім ANSWER (NODATA): ім’я існує, але потрібного типу запису немає.

3) Чому SERVFAIL трапляється, якщо авторитетний сервер виглядає нормально?

Бо резолвери валідують і застосовують політики. Помилки валідації DNSSEC, блокований TCP fallback або upstream timeouts можуть спричиняти SERVFAIL, навіть якщо авторитет віддає дані.

4) Чи може брандмауер спричинити NXDOMAIN?

Брандмауери частіше спричиняють таймаути або SERVFAIL, але можуть опосередковано призвести до NXDOMAIN, якщо ваш резолвер переключиться на інший view або ланцюг форвардингу, який повертає NXDOMAIN. Вважайте це «малоймовірним, але можливим» і ізолюйте проблему запитами до авторитету.

5) Чому SERVFAIL іноді періодичний?

Резолвери можуть обирати різні авторитетні сервери при кожному запиті. Якщо один NS недоступний, lame або віддає зламаний DNSSEC, деякі шляхи проходять, інші — ні. Ось чому прямих запитів до кожного NS — необхідність.

6) Як зрозуміти, що DNSSEC — проблема, не стаючи криптографом?

Зробіть тест порівняння: опитайте валідаційний резолвер і невалідаційний, яким керуєте, а потім використайте dig +trace +dnssec. Логи резолвера часто явно показують помилки (expired signatures, DS mismatch).

7) Чи варто відключати валідацію DNSSEC, щоб «вилікувати SERVFAIL»?

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

8) Чому перехід на TCP інколи виправляє DNS-проблеми?

Великі відповіді (особливо з DNSSEC) можуть не вміститися в UDP. DNS інформує про це truncation, пропонуючи retry через TCP. Якщо UDP-фрагментація або EDNS ламаються, TCP може бути надійнішим — за умови, що TCP/53 дозволений.

9) Який найшвидший спосіб довести, що це split-horizon DNS?

Опитайте той самий FQDN через внутрішні резолвери й зовнішні резолвери, і порівняйте. Якщо публічний дає NOERROR, а внутрішній — NXDOMAIN (або різні IP) — це split-horizon за дизайном або помилково.

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

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

Висновок: що робити наступного разу

NXDOMAIN і SERVFAIL — це не два відтінки «злого DNS». Це різні покажчики.

NXDOMAIN: вважайте, що система відповідає. Перевірте ім’я, зону, view і кеші.
SERVFAIL: вважайте, що резолвер не зміг безпечно завершити розв’язування. Розслідуйте DNSSEC, стан делегації, доступність і поведінку UDP/TCP.

Практичні кроки на цей тиждень:

Створіть невеликий runbook з початком «NXDOMAIN vs SERVFAIL» і включіть кроки 1–4 команд вище.
Додайте періодичну перевірку консистентності делегації/авторитету (опитування кожного NS і порівняння SOA serial).
Додайте канарку з DNSSEC-важким запитом, що перевіряє роботу TCP-fallback від краю до краю.
Навчіть інцидент-процес захоплювати вивід dig включно зі status, SERVER і flags. Скриншоти — не телеметрія.

DNS і далі ламатиметься. Але воно не витрачатиме ваш час, якщо ви навчитесь читати його подсказки.

Схожі статті

DNS SERVFAIL від постачальника: як довести, що проблема на їхньому боці