BIND9: Конфігурація, що виглядає правильно, але спричиняє періодичні NXDOMAIN

February 14, 2026 • February 14, 2026 • Читання: 7 хв • Views: 0

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

Періодичний NXDOMAIN — це тип інциденту, через який досвідчені оператори починають серйозно говорити «воно наче злякане» під час нарад. Одна мить — ім’я резольвиться; наступна — той самий запит від того самого клієнта повертає NXDOMAIN, а моніторинг виглядає як сейсмограф.

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

Що насправді означає періодичний NXDOMAIN

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

Коли BIND повертає NXDOMAIN, зазвичай це належить до однієї з цих категорій:

Авторитетний NXDOMAIN: BIND є авторитетним для зони і ім’я дійсно не існує (або ваш файл зони каже, що не існує).
Кешована негативна відповідь: BIND раніше дізнався NXDOMAIN (або NODATA) і закешував це. Тепер він повторює.
NXDOMAIN, згенерований політикою: Response Policy Zones (RPZ), views, ACL або спеціальна логіка дають результат, схожий на NXDOMAIN.
NXDOMAIN від форвардера: ваш форвардер каже NXDOMAIN, і BIND довіряє йому (іноді надто сильно).
Кутове поводження DNSSEC: зазвичай помилки DNSSEC дають SERVFAIL, але неправильні інтерпретації та поведінка апстріму можуть виглядати як NXDOMAIN, особливо при змішаних налаштуваннях валідації і форвардерів.

Частина «періодичний» зазвичай походить із зміни стану під вашими ногами:

Негативні записи кешу, що закінчуються у різний час (SOA MINIMUM / negative TTL, поведінка RFC 2308).
Кілька резолверів або anycast-вузлів з різним вмістом кешу.
Views, що обирають різні дані залежно від IP-джерела, EDNS Client Subnet або TSIG-ключа.
Форвардери повертають непослідовні відповіді (або один форвардер зламаний і обраний час від часу).
Розповсюдження DNS або затримки передачі зони.
Різниця в розмірі пакета/фрагментації, що впливає лише на DNSSEC-підписані відповіді, змушуючи деякі клієнти використовувати TCP, а інші — ні.

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

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

Робіть ці кроки в порядку. Не імпровізуйте. Мета — швидко локалізувати походження NXDOMAIN: авторитетний, кеш, політика або апстрім.

1) Підтвердіть, що ви реально отримуєте (і звідки)

Запитуйте підозрілий резолвер напряму (не через системний stub).
Зафіксуйте прапори відповіді: aa, ra, ad, і SOA в секції authority.
Порівняйте з відомим робочим резолвером (інший рекурсивний резолвер або інший екземпляр BIND).

2) Визначте: авторитетний чи рекурсивний?

Якщо сервер відповідає з aa, ви в авторитетній зоні: перевірте вміст зони, трансфери та views.
Якщо відповідає без aa але з ra, ви в рекурсивній зоні: кеш, форвардери, DNSSEC-валідація і політика.

3) Перевірте негативний кеш і політику перед тим, як лізти в DNSSEC

Негативний кеш — головна причина «то приходить, то зникає».
Невідповідність RPZ/view може виглядати випадковою, коли клієнти приходять з різних NAT-пулів або IPv6-адрес.

4) Перевірте шлях до апстріму

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

5) Лише потім розбирайтесь з DNSSEC/EDNS/MTU дивностями

Якщо збої корелюють з DNSSEC-підписаними зонами і розміром UDP, підозрюйте фрагментацію або пошкоджені middlebox.

Перефразована ідея від Werner Vogels (CTO Amazon): «Ти побудував — ти експлуатуєш». Якщо DNS — «чужий», ви постійно успадкуєте таємничі збої.

Конфігурація, що виглядає правильно (і чому вона бреше)

Ось пастка: у BIND достатньо регуляторів, що дві різні ментальні моделі можуть «підходити» під одну й ту саму конфігурацію. Хтось думає, що створив чистий рекурсивний резолвер. Інший вважає, що це «форвардуючий кеш». Ще один думає, що views — лише для split-horizon внутрішніх зон. І хтось таємно додав RPZ для «безпеки».

Все може працювати — поки кілька імен не почнуть хитатися.

Класична «виглядає правильно» конфігурація, що породжує періодичний NXDOMAIN, містить такі інгредієнти:

Форвардери з різною поведінкою: один форвардер — корпоративний DNS-аплайанс, який робить перезапис, інший — простий резолвер. BIND чергує або переходить на резерв.
Views: внутрішні клієнти отримують одну view, VPN-клієнти — іншу, а IPv6-клієнти випадково потрапляють у «дефолтну» view.
Увімкнене негативне кешування (за замовчуванням) з довгим negative TTL через SOA MINIMUM зони або помилкове тлумачення RFC 2308.
Налаштування кешу, що застаріли (або їх відсутність), які змушують відповіді відрізнятися під час апстрім-ослаблень.
RPZ або «блок-списки», що дають NXDOMAIN для частини запитів на підставі QNAME, client subnet або view.
Кілька екземплярів named за VIP/anycast з неузгодженим кешем і часом оновлення.

BIND детерміністичний. Ваше середовище — ні.

Жарт 1: DNS — це єдина система, де «неіснуюче» можна кешувати як фічу продуктивності. Реальність, але з TTL.

Режими відмов, що продукують періодичний NXDOMAIN

1) Негативне кешування: NXDOMAIN, що зберігається після того, як ви виправили запис

Негативне кешування не є багом реалізації; це частина DNS. Коли резолвер дізнається, що foo.example.com не існує, він може закешувати цей факт. Як довго? Залежить від SOA зони і правил негативного кешування RFC 2308. На практиці оператори обпікаються, коли:

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

Періодичність походить від того, до якого інстансу резолвера або кешу ви звертаєтесь, або від того, що negative TTL закінчується в різний час у флоті.

2) Views: правильні дані зони, неправильні клієнти

Views потужні й гострі. Вони обирають різні дані зони і опції залежно від ідентичності клієнта (джерело IP, TSIG, співпадіння ACL). Одна тонка помилка: IPv6-клієнти не збігаються з передбаченими ACL і потрапляють у default view, яка не має внутрішньої зони. Вони отримують NXDOMAIN. IPv4 виглядає добре. Це може відчуватися як періодичність, коли dual-stack клієнти перемикаються між v4 і v6 або коли NAT-пули розподіляють клієнтів по різних діапазонах джерел.

3) Форвардери: «forward first» маскує дивність апстріма

Якщо ви використовуєте forward first;, BIND спробує форвардери і, якщо вони впадуть (таймаут/REFUSED), перейде до повної рекурсії. Це звучить стійко. Але це також джерело непослідовності:

Якщо форвардер повертає NXDOMAIN швидко (навіть неправильно), BIND приймає це і не рекурсить.
Якщо форвардер таймаутиться, BIND може виконати рекурсію і знайти правильну відповідь.
Отже, те саме ім’я може чергуватися між NXDOMAIN і NOERROR залежно від стану форвардера.

У регульованих середовищах форвардери також можуть застосовувати допоміжні search-suffix, split-horizon або блок-списки. Якщо політика зміниться, ваш BIND стає посередником і отримує звинувачення.

4) RPZ: політичний NXDOMAIN, який важко помітити

RPZ може переписувати відповіді в NXDOMAIN, NODATA, CNAME-to-walled-garden або щось інше. Якщо RPZ застосовується лише в одній view, лише деякі клієнти бачать NXDOMAIN. Якщо оновлення RPZ підтягуються асинхронно, частина ваших резолверів може мати політику, а інші — ні. Вітаємо: періодичний NXDOMAIN.

5) Авторитетна непослідовність: часткова пропагація, зламані трансфери або припущення “hidden master”

Якщо BIND є авторитетним (або у вас є авторитетні сервери десь), періодичний NXDOMAIN часто означає, що не всі авторитетні сервери погоджуються. Звичайні причини:

Один secondary не отримує оновлення трансфером (TSIG mismatch, firewall, проблеми з notify).
Номери серіалів не інкрементуються надійно.
Динамічні оновлення (DDNS) записуються на один сервер, але secondaries не підхоплюють їх, або views розділяють шлях оновлення.

Резолвери обирають різні авторитетні сервери залежно від RTT і кешу. Ви бачите «іноді NXDOMAIN». Насправді це «з того одного сервера».

6) Search domains + ndots: проблема «я цього імені не питав»

Багато NXDOMAIN — самоіндуковані клієнтами. З search domains і ndots запит на api може перетворитися на api.corp.example, api.prod.corp.example і нарешті api. Резолвер може кешувати негативні відповіді для цих розширень. Якщо ваш додаток логує лише коротке ім’я, ваші DNS-логи показують інше ім’я. Звіт про інцидент набуває сюрреалістичного відтінку.

7) DNSSEC/EDNS/MTU: не прямий генератор NXDOMAIN, але підсилювач хаосу

Помилки DNSSEC зазвичай проявляються як SERVFAIL на валідаційних резолверах. Але DNSSEC впливає на розміри payload і поведінку транспорту. Деякі клієнти повторюють запит по TCP; деякі — ні. Деякі middlebox’и ріжуть фрагменти. Форвардер може деградувати до повернення поведінки, схожої на NXDOMAIN для певних імен, якщо його власна валідація або політика сплутуються. Періодичність часто корелює з:

Тільки деякі мережі мають зламану PMTUD або проблеми з збиранням фрагментів.
Тільки деякі імена DNSSEC-підписані або мають великі відповіді (багато записів, довгі RRSIG-ланцюги).
Anycast або мульти-різні резолвери, де лише частина вузлів має зламаний шлях.

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

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

Завдання 1: Запитайте резолвер напряму і прочитайте прапори

cr0x@server:~$ dig @127.0.0.1 www.example.com A +noall +answer +authority +comments
;; Got answer:
;; ->>>HEADER<<<- opcode: QUERY, status: NXDOMAIN, id: 53188
;; 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. 2026020401 3600 600 1209600 300

Значення: Статус NXDOMAIN, доступна рекурсія (ra), не авторитетний (aa відсутній). Це рекурсивна відповідь (або форвардована), і SOA підказує, яка зона стверджувала неіснування.

Рішення: Спочатку розглядайте як проблему кешу/форвардера/політики. Якби був aa, перемикайтесь на перевірку авторитетних даних і трансферів.

Завдання 2: Порівняйте з відомим робочим резолвером

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

www.example.com.	60	IN	A	203.0.113.10

Значення: Публічний резолвер дає NOERROR з A-записом. Ваш BIND, що повертає NXDOMAIN, — це не «інтернет». Це ваш стек.

Рішення: Розслідуйте негативний кеш, views, RPZ і форвардери. Поки не чіпайте авторитетну зону.

Завдання 3: Дізнайтесь, чи форвардить ваш BIND і до кого

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,160p'
options {
	directory "/var/cache/bind";
	recursion yes;
	allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };
	forwarders { 10.10.10.10; 10.10.10.11; };
	forward first;
	dnssec-validation auto;
};

zone "corp.example" IN {
	type master;
	file "/etc/bind/zones/db.corp.example";
};

Значення: Ви форвардите перш за все до двох внутрішніх форвардерів. Саме це може створювати періодичні відмінності, якщо форвардери не погоджуються або один нездоровий.

Рішення: Тестуйте кожен форвардер напряму для проблемного імені (див. наступне завдання). Якщо форвардери повертають NXDOMAIN, BIND — лише кур’єр.

Завдання 4: Запитайте форвардери індивідуально

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

example.com.	600	IN	SOA	ns1.example.net. hostmaster.example.com. 2026020401 3600 600 1209600 600

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

www.example.com.	60	IN	A	203.0.113.10

Значення: Ваші форвардери не погоджуються. З forward first ваш BIND іноді приймає NXDOMAIN від одного форвардера і іноді отримує правильну відповідь від іншого.

Рішення: Виправте або видаліть проблемний форвардер. Якщо не можна, розгляньте forward only; (для суворої політики) або припиніть форвардити та рекурсіть самостійно (для коректності), але не змішуйте «часом політику» з «часом реальністю».

Завдання 5: Перевірте, чи кешується NXDOMAIN (негативний кеш)

cr0x@server:~$ sudo rndc dumpdb -cache
Dumping caches.

cr0x@server:~$ sudo grep -n "www.example.com" /var/cache/bind/named_dump.db | head
21483;www.example.com.	300	negative
21484;www.example.com.	300	IN	SOA	example.com. hostmaster.example.com. 2026020401 3600 600 1209600 300

Значення: BIND має закешований негативний запис для www.example.com з 300 секундами до закінчення.

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

Завдання 6: Очистіть одне ім’я (точково, не «очищати все»)

cr0x@server:~$ sudo rndc flushname www.example.com
flushed

Значення: Видаляє кеш для цього імені (включно з негативним кешем), примушуючи повторне розв’язування.

Рішення: Перезапитайте запит негайно. Якщо знову повернувся NXDOMAIN, це не «застарілий кеш» — це апстрім або політика.

Завдання 7: Перевірте, чи RPZ переписує відповідь

cr0x@server:~$ sudo named-checkconf -p | grep -n "response-policy" -n
42:	response-policy { zone "rpz-block"; };

cr0x@server:~$ dig @127.0.0.1 www.example.com A +noall +answer +authority
example.com.	300	IN	SOA	ns.rpz.local. hostmaster.rpz.local. 2026020401 3600 600 1209600 300

Значення: SOA в секції authority походить з RPZ-пов’язаної зони, а не з example.com. Це димовий сигнал: політика згенерувала цей «NXDOMAIN».

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

Завдання 8: Перевірте, чи views обирають різні дані зони

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,220p' | grep -n "view\|match-clients\|zone \"corp.example\""
61:view "internal" {
62:	match-clients { 10.0.0.0/8; 192.168.0.0/16; };
80:	zone "corp.example" { type master; file "/etc/bind/zones/db.corp.example"; };
95:};
97:view "external" {
98:	match-clients { any; };
112:	zone "corp.example" { type master; file "/etc/bind/zones/db.corp.example.external"; };
130:};

Значення: Різні клієнти можуть отримувати різні версії однієї й тієї самої зони. Це не автоматично помилка. Це автоматично ризик.

Рішення: Підтвердіть, які клієнти відповідають якій view (наступні завдання) і чи «зовнішній» файл зони навмисно не містить записів, потрібних VPN/хмарним клієнтам.

Завдання 9: Запитайте з різних адрес джерел, щоб відтворити вибір view

cr0x@server:~$ dig @10.0.0.53 app.corp.example A +noall +answer +comments
;; Got answer:
;; ->>>HEADER<<<- opcode: QUERY, status: NOERROR, id: 15054
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

app.corp.example.	30	IN	A	10.20.30.40

cr0x@server:~$ dig @198.51.100.53 app.corp.example A +noall +answer +comments
;; Got answer:
;; ->>>HEADER<<<- opcode: QUERY, status: NXDOMAIN, id: 4490
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Значення: Та сама програмна складова, різні адреси/шляхи, різна відповідь. Це зазвичай views або політика, а не «рандом DNS».

Рішення: Вирішіть, чи повинно app.corp.example бути доступним зовні. Якщо так — виправте зовнішню view або правила match-clients.

Завдання 10: Перевірте авторитетну послідовність з +trace

cr0x@server:~$ dig +trace www.example.com A
; <<>> DiG 9.18.24 <<>> +trace www.example.com A
;; Received 811 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

example.com.	172800	IN	NS	ns1.example.net.
example.com.	172800	IN	NS	ns2.example.net.
;; Received 525 bytes from 192.0.2.53#53(a.root-servers.net) in 19 ms

www.example.com.	60	IN	A	203.0.113.10
;; Received 116 bytes from 203.0.113.53#53(ns1.example.net) in 24 ms

Значення: Авторитетний шлях повертає NOERROR. Якщо ваш резолвер повертає NXDOMAIN, проблема між вашим резолвером і авторитетом: форвардери, кеш, політика або зламаний шлях резолвінгу.

Рішення: Якщо залучені форвардери — виправте їх. Якщо ні — інспектуйте логи резолвера і поведінку кешу.

Завдання 11: Увімкніть цілеспрямований лог запитів (тимчасово), щоб побачити джерело NXDOMAIN

cr0x@server:~$ sudo rndc querylog
query logging is now on

cr0x@server:~$ sudo journalctl -u bind9 -n 20 --no-pager
Feb 04 11:12:01 dns1 named[1234]: client @0x7f2a1c0 10.1.2.3#55214 (www.example.com): query: www.example.com IN A +E(0)K (10.10.10.10)
Feb 04 11:12:01 dns1 named[1234]: client @0x7f2a1c0 10.1.2.3#55214 (www.example.com): forwarding failed, response NXDOMAIN from 10.10.10.10

Значення: Лог явно показує форвардинг і апстрім, що повернув NXDOMAIN.

Рішення: Припиніть суперечки. Виправте 10.10.10.10 або видаліть його. Потім вимкніть лог запитів; він дуже шумний в продакшні.

Завдання 12: Перевірте SERVFAIL, замасковані повторними спробами клієнта (і питання транспорту)

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

Значення: ad вказує на валідовані дані (коли клієнт запитував і резолвер валідував). Якщо ви не бачите ad, де очікуєте — валідація може бути вимкнена або падати.

Рішення: Якщо DNSSEC задіяний і збої корелюють з певними мережами, інспектуйте EDNS-розмір і TCP-fallback (наступні завдання). Навіть якщо це не дає прямого NXDOMAIN, воно може спричинити різну поведінку повторних спроб, що виглядає «періодично».

Завдання 13: Перевірте EDNS UDP-розмір і примусіть TCP для тестування гіпотези фрагментації

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

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

www.example.com.	60	IN	A	203.0.113.10

Значення: Якщо UDP іноді падає, а TCP завжди працює, ймовірно у вас проблема з PMTUD/фрагментацією між клієнтами і резолвером або між резолвером і апстрімом.

Рішення: Зменшіть анонсований UDP-розмір на резолвері (або виправте мережу). Не «вирішуйте» це відключенням DNSSEC повсюдно, якщо вам подобаються майбутні інциденти.

Завдання 14: Проінспектуйте статистику BIND на піки NXDOMAIN/негативних відповідей

cr0x@server:~$ sudo rndc stats
Statistics dump file written to /var/cache/bind/named.stats

cr0x@server:~$ sudo sed -n '1,120p' /var/cache/bind/named.stats
+++ Statistics Dump +++
++ Incoming Requests ++
               18452 QUERY
++ Outgoing Requests ++
               10211 QUERY
++ Name Server Statistics ++
                1423 NXDOMAIN
                 211 SERVFAIL

Значення: Високі лічильники NXDOMAIN можуть бути нормою (опечатки, search domains), або це ваш інцидент. З’єднайте це з логами запитів або фільтром qname, щоб побачити, які імена домінують.

Рішення: Якщо сплески NXDOMAIN прив’язані до конкретного домену/сервісу — фокусуйтесь там. Якщо вони широкі — підозрюйте форвардер/політику/вибір view.

Завдання 15: Перевірте правильність файлу зони, якщо ви авторитетні

cr0x@server:~$ sudo named-checkzone corp.example /etc/bind/zones/db.corp.example
zone corp.example/IN: loaded serial 2026020401
OK

Значення: Зона парситься і завантажується; серіал видно.

Рішення: Якщо періодичний NXDOMAIN відбувається і ви авторитетні — порівняйте серіали на всіх авторитетних серверах. Застарілий secondary — звичайний винуватець.

Завдання 16: Підтвердіть, що secondaries мають той самий серіал (авторитетна узгодженість)

cr0x@server:~$ dig @ns1.corp.example corp.example SOA +noall +answer
corp.example.	300	IN	SOA	ns1.corp.example. hostmaster.corp.example. 2026020401 3600 600 1209600 300

cr0x@server:~$ dig @ns2.corp.example corp.example SOA +noall +answer
corp.example.	300	IN	SOA	ns1.corp.example. hostmaster.corp.example. 2026020317 3600 600 1209600 300

Значення: ns2 відстає (старіший серіал). Резолвери, що потрапляють на ns2, можуть отримувати NXDOMAIN для щойно доданих імен.

Рішення: Виправте трансфери зон (TSIG, allow-transfer, notify, firewall). Не замилюйте це низькими TTL; це лише пришвидшить появу болю наступного разу.

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

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

1) «У мене резольвиться, а користувачам ні»

Симптом: ІТ-персонал у корпоративній мережі отримує NOERROR; віддалені користувачі/VPN/мобільні — NXDOMAIN.

Корінь: Views або split-horizon. Віддалені користувачі потрапляють в іншу view (часто через IPv6-джерела або різні NAT-пули), яка не має запису або має застосовану RPZ.

Виправлення: Аудит ACL match-clients для обох стеків v4 і v6 і впевніться, що потрібні зони/політики є у всіх необхідних view. Тестуйте із репрезентативних мереж джерел, а не лише з DNS-сервера.

2) «Додали запис, але іноді все ще NXDOMAIN»

Симптом: Після provision деякі клієнти все ще отримують NXDOMAIN від хвилин до годин.

Корінь: Негативне кешування. NXDOMAIN було вивчене і закешоване перед тим, як запис з’явився, і negative TTL довший, ніж ви думали.

Виправлення: Для аварійних cutover-ів очищайте конкретні імена на рекурсивних резолверах (rndc flushname). У довгостроковій перспективі: свідомо проектуйте SOA MINIMUM/negative TTL, і уникайте попередніх перевірок, які питають імена до їхнього створення (або обмежте ці перевірки тестовими резолверами).

3) «Працює лише по понеділках (або випадково), і перезапуск BIND допомагає»

Симптом: Періодичний NXDOMAIN, який «зникає» після перезапуску.

Корінь: Скидання кешу приховує джерело непослідовності апстріма: форвардери не погоджуються, оновлення RPZ недонсинхронізовані або один авторитетний сервер не в синхроні.

Виправлення: Не перезапускайте як ліки. Визначте, який апстрім згенерував NXDOMAIN через логування запитів або тестування форвардерів. Виправте джерело; тоді скидання кешу стане рідкістю.

4) «Підзони в зоні — деякі записи не працюють, інші — так»

Симптом: Декілька імен хостів повертають NXDOMAIN; інші в тій же зоні резольвяться.

Корінь: Wildcards та empty non-terminals, або запис існує лише в одній view/на одному авторитетному сервері. Інша поширена причина: ви створили записи типу _service._tcp, але клієнти питають інший тип і виникає плутанина NODATA/NXDOMAIN.

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

5) «Працює на IPv4, ламається на IPv6»

Симптом: Dual-stack клієнти бачать періодичний NXDOMAIN залежно від стека.

Корінь: ACL views без IPv6, або відмінності в досяжності апстріму по IPv6, або відсутні AAAA/glue записи, що змінюють шляхи резолвінгу.

Виправлення: Зробіть ACL view явно двостековими. Забезпечте доступність форвардерів і root hints по IPv6, якщо ви обслуговуєте v6-клієнтів. Тестуйте з dig -6 і порівнюйте.

6) «Трапляється лише для деяких публічних доменів»

Симптом: Підмножина зовнішніх доменів повертає NXDOMAIN з вашого резолвера, але решта резольвиться.

Корінь: RPZ-блокування, фільтрація DNS у апстрімі або зламаний форвардер, що робить NXDOMAIN-ремапінг для «безпеки».

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

Три корпоративні міні-історії з поля бою

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

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

Потім запустили новий внутрішній сервіс з хостом, який не існував, поки пайплайн розгортання його не створив. Health-check — що запускали раніше — багаторазово запитував ім’я. Протягом короткого вікна резолвери дізналися NXDOMAIN і закешували це. Скоро після цього запис з’явився й почав іноді резольвитись. Деякі клієнти потрапляли на резолвер A (ще з негативним кешем NXDOMAIN), інші — на резолвер B (вже з протухлим кешем). On-call побачив це як флеймість при rollout.

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

Через тиждень це повторилося. Цього разу хто-небудь порівняв SOA MINIMUM для внутрішньої зони. Один резолвер мав старішу версію зони з довшим negative TTL через застарілий secondary transfer. Не ідентичні. Коли це важливо — вони швидко розходяться.

Виправлення було не героїчним. Відновили трансфери, уніфікували SOA/negative TTL і змінили health-check розгортання так, щоб запитувати ім’я лише після створення запису або звертатися до staging-резолвера. Неправильне припущення було «ідентичні вузли». DNS швидко показав, що це не так.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Інша організація пишалася «швидким DNS». Вони ввімкнули форвардери до внутрішнього кешуючого шару, що обіцяв низьку латентність і «фільтрацію безпеки». Вони також встановили forward first, щоб BIND міг рекурсити, якщо форвардери мали проблеми. Найкраще з обох світів, правда?

Працювало — поки вендор форвардера не викинув оновлення політики. Набір доменів став повертати NXDOMAIN через помилки категоризації. Тим часом кластер форвардера був трохи перевантажений; іноді він таймаутив. У таких випадках BIND переходив до рекурсії і повертав правильну відповідь. Користувачі бачили періодичний NXDOMAIN залежно від того, чи форвардер відповів швидко (неправильно) чи повільно (не відповів зовсім).

Вендор наполягав, що «немає збою». Їхні системи були вгору. Правильно. А ось імена клієнтів були «вниз», періодично. Команда BIND стала «дорослою» в кімнаті і довела логами, що «швидкі помилкові відповіді» гірші за «повільні правильні».

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

Жарт 2: Єдине гірше за повільну DNS-відповідь — швидка, що впевнено неправильна.

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

Фінансова компанія обслуговувала авторитетні DNS для кількох внутрішніх зон і публічної зони для клієнтських кінцівок. У них була рутина: кожна зміна зони вимагала bump серіала, named-checkzone і швидкої перевірки SOA серіалів на всіх авторитетах. Без винятків. Це було непопулярно серед тих, хто думав, що DNS — «лише текстовий файл».

Одного дня додали запис для нового клієнтського endpoint. Праймер оновився коректно. Один secondary — ні. Але завдяки тому, що команда завжди перевіряла SOA серіали, вони помітили це за кілька хвилин. Вони ще не отримали жодної скарги від клієнтів.

Причина була буденною: вночі хтось «почистив» правила фаєрвола, і TCP/53 для трансферів зон було видалено між праймаром і тим secondary. Secondary продовжував обслуговувати стару зону. Якби це дійшло до клієнтів, вони б бачили періодичний NXDOMAIN залежно від того, який авторитет їх резолвер вибере.

Команда відновила правило фаєрвола, підтвердила трансфер, і запис став глобально узгодженим. Нудна практика — перевірка серіалів — запобігла інциденту для клієнтів. В опсах «нудне» часто означає «ефективне».

Цікаві факти та історичний контекст

NXDOMAIN стандартизований: це RCODE 3, що означає «Name Error», і відрізняється від «no data» (NOERROR з порожньою відповіддю).
Негативне кешування не завжди було повсюдним: RFC 2308 формалізував поведінку негативного кешування, щоб зменшити безпідставні повторні запити для неіснуючих імен.
SOA MINIMUM змінили значення: історично SOA MINIMUM використовувався як дефолтний TTL для записів; пізніше його пов’язали з negative caching TTL-семантикою.
BIND довго був референсною реалізацією: поведінка BIND вплинула на очікування операторів у галузі — іноді на краще, іноді на «чому це так працює?»
Split-horizon DNS старший за хмару: підприємства використовували views/split-horizon задовго до того, як Kubernetes ускладнив відкритий доступ до сервісів.
RPZ створено для політики в масштабі: воно дозволяє операторам інжектувати модифікації відповідей без зміни авторитетних зон — потужно й легко зловживати.
DNSSEC зробив відповіді більшими: валідація додає додаткові записи (RRSIG, DNSKEY, DS), що збільшує розмір відповіді і робить видимішими проблеми транспорту/шляху.
Резолвери віддають перевагу UDP поки можуть: DNS зазвичай починається на UDP/53; TCP fallback є, але стек клієнта та middlebox-і різняться.
«Авторитетний» — це по зоні, не по серверу: сервер може бути авторитетним для однієї зони і рекурсивним для інших, що класично заплутує триаж.

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

Чекліст A: Визначте, звідки йде NXDOMAIN

Запустіть dig @your-resolver name type +noall +answer +authority +comments.
Зафіксуйте: статус, наявність aa, наявність ra, і ім’я власника SOA в AUTHORITY.
Якщо SOA співпадає з реальною зоною: ймовірно справжній авторитетний NXDOMAIN або кешований від авторитету.
Якщо SOA виглядає як RPZ/політика — політичний NXDOMAIN.
Якщо використовуєте форвардери: опитайте кожного форвардера напряму і порівняйте.

Чекліст B: Виправляємо без побічного шкоди

Очищайте лише уражені імена на рекурсивних резолверах: rndc flushname.
Якщо авторитетна непослідовність: перевірте SOA серіали на всіх авторитетних серверах і відновіть трансфери.
Якщо views: переконайтеся, що запис існує у всіх призначених view і ACL охоплюють IPv4 та IPv6.
Якщо форвардери не погоджуються: видаліть поганий або виправте його політику/зону. Не тримайте «іноді неправильне» у ротації.
Якщо RPZ: підтвердьте, чи це справжній позитив для блокування; додайте виключення або виправте синхронізацію фідів.

Чекліст C: Забезпечте неможливість регресу

Додайте synthetic-моніторинг, що опитує кожен вузол резолвера напряму, а не лише VIP.
Алёртуйте на раптові збільшення NXDOMAIN для критичних імен (не за загальним обсягом NXDOMAIN).
Відстежуйте стан форвардерів окремо і приберіть їх автоматично, якщо вони повертають дурниці для canary-ім’я.
Для авторитетних зон автоматизуйте перевірки парності SOA серіалів по всіх авторитетах.
Тримайте визначення views мінімальними. Кожна view — це гілка інцидентного дерева.

FAQ

1) Чому NXDOMAIN періодичний, а не постійно неправильний?

Тому що DNS розподілений і кешований. Різні резолвери, різні стани кешу, різні апстріми, різні views. Система може бути «постійно непослідовною».

2) Як зрозуміти, чи BIND авторитетний для зони?

Запитайте і перевірте прапор aa у відповіді. Також перегляньте named-checkconf -p для визначення зони. Якщо це type master або type slave, то він авторитетний для цієї зони.

3) У чому різниця між NXDOMAIN і NODATA?

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

4) Чи може DNSSEC спричинити NXDOMAIN?

Збої валідації DNSSEC зазвичай дають SERVFAIL на валідаційних резолверах. Але DNSSEC збільшує розміри відповідей і складність, що може викликати проблеми транспорту або дивну поведінку форвардерів, які проявляються як періодичні неправильні відповіді, включно з NXDOMAIN від апстрім-політики.

5) Використовувати `forward first` чи `forward only`?

Якщо вам потрібна сувора політика від форвардерів — використовуйте forward only і прийміть, що політика — джерело правди. Якщо ви хочете коректність і незалежність — взагалі не форвардьте, рекурсіть напряму. forward first може створити непослідовну поведінку, коли форвардери ненадійні або помиляються.

6) Чи є очищення кешу валідним вирішенням?

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

7) Як довести, що це RPZ?

Подивіться на SOA в секції authority відповіді NXDOMAIN; політичний NXDOMAIN часто вказує на SOA, контрольований RPZ. Також перевірте наявність response-policy в ефективній конфігурації і перегляньте вміст RPZ-зони.

8) Чому лише деякі клієнти потрапляють у неправильну view?

Тому що match-clients ACL часто не включає всі реальні діапазони клієнтів (особливо IPv6), або трафік заходить через NAT, VPN-пули або split-tunneling. Клієнти, яких ви вважаєте «внутрішніми», можуть не виглядати такими для DNS-сервера.

9) Який найшвидший спосіб ізолювати зламом форвардер?

Опитайте кожного форвардера напряму для проблемного імені та для канаркового імені, одне за одним. Якщо один повертає NXDOMAIN, а інші — NOERROR, це підозрілий. Підтвердіть логуванням запитів на BIND.

10) Як запобігти повторенню цього класу інцидентів?

Моніторте поведінку по вузлах резолверів, контролюйте очікування negative TTL, тримайте views/політику явними і під аудитом, та тестуйте форвардери як залежності — бо вони такими є.

Висновок: наступні реальні кроки

Періодичний NXDOMAIN — не містичний настрій DNS. Майже завжди це одна з чотирьох речей: негативний кеш, views, форвардери або політика (RPZ). DNSSEC і проблеми транспорту часто супроводжують, але рідко є первісною причиною NXDOMAIN.

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

Виберіть одне проблемне ім’я і відтворіть з dig напряму проти вашого резолвера. Збережіть вивід з прапорами і SOA.
Опитайте кожного форвардера індивідуально. Якщо вони не погоджуються — ви знайшли «періодичність».
Здампуйте кеш і підтвердіть, чи є негативний запис. Очистьте конкретне ім’я для пом’якшення наслідків.
Перегляньте views і RPZ у відрендереній конфігурації (named-checkconf -p), а не в чиємусь наполовину запам’ятованому уявленні.
Якщо ви авторитетні — перевірте парність SOA серіалів по всіх авторитетах перед тим, як звинувачувати резолвери.
Після інциденту: додайте перевірки по вузлах DNS та canary-запит, що ніколи не має бути NXDOMAIN, і алерт при порушенні.

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

Схожі статті

DNS: split‑horizon, коли все йде не так — виправлення, яке зупиняє хаос «всередині/зовні»