BIND9: неконтрольовані передачі зон — як захистити їх, не зламавши вторинні DNS

Як передачі зон ламаються в реальному житті

Передавання зон (AXFR — повне, IXFR — інкрементальне) мають бути нудною фоновою реплікацією. Ви публікуєте зону на одному чи кількох первинних серверах, вторинні тягнуть оновлення, резолвери запитують в будь‑якого авторитетного сервера, і всі довіряють TTL як дорослі.

Потім з’являється один із класичних прискорювачів проблем:

• Надто дозволяючі ACL для передач («allow-transfer { any; };» — DNS‑аналог залишити зчитувач бейджів у «демо‑режимі»).
• NAT або фаєрволи з асиметричними правилами (NOTIFY проходить, а TCP‑передача — ні; або навпаки).
• Неврівноважене керування серіалами (ручні правки без підняття серіалу; або динамічний DNS з прихованим майстром, що не відповідає припущенням).
• Хвилі передач (багато вторинних, агресивні інтервали оновлення, нестабільні майстри або конфігурація, що змушує робити повний повторний перенос).
• Невідповідність views (split‑horizon зони, але облікові дані/ACL для передач не співпадають, через що вторинні реплікують невірний вигляд або ж взагалі нічого).
• Дрейф TSIG (невірний ключ, алгоритм, асоціація з оператором «server», або зсув годин, що призводить до відмови підписаних повідомлень).

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

• Ризик доступності: вторинні сервери подають застарілі дані під час інцидентів, що спричиняє часткові відмови, які складно діагностувати.
• Ризик конфіденційності: AXFR витікає внутрішні імена хостів, топологію сервісів і правила найменувань. Атакам це подобається.
• Ризик ємності: повторні спроби передач можуть стати самовикликаним DDoS, особливо при великій кількості зон або великих зонах (наприклад: автозгенеровані записи).
• Ризик контролю змін: «тимчасовий» правка ACL може тихо зламати реплікацію і виявитися лише після завершення TTL і часу кешування.

Жарт №1: DNS — єдина система, де «керування серіалами» одночасно стратегія надійності й сюжетний хід.

Цікаві факти та контекст (чому ми дійшли до цього)

Короткий, конкретний контекст важливий, бо поведінка BIND сформована десятиліттями операційного досвіду та помилок.

1. AXFR передує сучасним підходам «мінімальних привілеїв». Ранній DNS розраховував на співпрацю серверів; ідея ворожого сканування передач з’явилася пізніше.
2. Передачі зон використовують TCP. Звичайні DNS‑запити зазвичай UDP, але AXFR/IXFR за дизайном використовують TCP для надійної передачі великого обсягу даних.
3. NOTIFY був додатком. Спочатку вторинні чекали за таймерами refresh; NOTIFY (RFC 1996) прискорив поширення, але додав нові режими відмов, коли UDP/53 фільтрують інакше, ніж TCP/53.
4. IXFR існує, щоб уникнути повних передач. Інкрементальні передачі (RFC 1995) зменшують пропускну здатність і навантаження, але залежать від наявності журналів/дифів і коректного прогресування серіалів.
5. TSIG старіший, ніж думають багато хто. Transaction SIGnature (RFC 2845) став робочим механізмом аутентифікації передач без ускладнення DNSSEC.
6. «views» у BIND розроблені для split‑horizon. Потужний інструмент, легко неправильно застосувати: ваші ACL для передач мають узгоджуватися з потрібним view, інакше ви реплікуєте невірний набір відповідей.
7. Дизайн з прихованим майстром став поширеним для зменшення поверхні атаки. Публікувати лише вторинні — добре, поки ви не забудете, що вторинні все одно повинні дістатися до майстра по TCP/53.
8. Формат передач і семантика SOA досі центральні. Незважаючи на сучасну автоматизацію, SOA serial, refresh, retry, expire і negative TTL залишаються регуляторами поведінки.

Корисна ментальна модель: AXFR/IXFR/NOTIFY і хто що ініціює

Primary vs secondary: напрямок передач

У класичній архітектурі primary/secondary саме вторинний ініціює передачу. Він підключається до первинного (TCP 53), просить IXFR або AXFR і зберігає локальну копію. Тому ваша безпекова політика має бути такою: первинний дозволяє передачі лише від відомих вторинних, а вторинні підключаються лише до відомих первинних.

NOTIFY — це «дзвінок у двері», а не вантажівка для доставки

NOTIFY — коротке повідомлення від первинного до вторинного: «мій серіал змінився; перевірь». Він зазвичай UDP. Сама передача — важка робота і відбувається по TCP. Тому ваш фаєрвол має дозволяти обидва напрямки відповідно, а конфіг BIND має уникати приймання NOTIFY від випадкових хостів.

IXFR — не магія

IXFR працює лише коли первинний може надати інкрементальні зміни. У BIND це зазвичай залежить від журналу зони. Втрата журналу (або його відключення) змусить вторинний часто перейти на AXFR. Якщо зона велика, такий відкат буде дорогим.

Цитата, щоб не забувати про реальність

Надія — це не стратегія. — Джин Кранц

Модель загроз: від чого ви захищаєтеся

Обмежувати передачі — це не параноя; це гігієна. Ось реалістичний набір проблем:

• Неавторизовані спроби AXFR/IXFR для переліку внутрішніх імен і сервісів.
• Неправильно налаштовані внутрішні хости, що випадково поводяться як вторинні й «дубасать» первинний нескінченними повторними спробами.
• Скомпрометований вторинний, якому все ще довіряє первинний ACL, і який використовують як точку повороту.
• Відображення операційних помилок: хтось відкрив передачі «тимчасово», щоб виправити вторинний, а потім забув.
• Вичерпання ресурсів: конкуренція передач, TCP‑сокетів, записів на диск для зон, журналів змін і перевантаження логами.

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

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

Коли вторинні не оновлюються або передачі розвалюють ваші сервери, вам потрібен безжальний порядок дій. Не починайте з панічного редагування named.conf. Почніть з пошуку вузького місця.

Спочатку: доведіть базову досяжність і протокол (TCP vs UDP)

• Чи може вторинний дістатися до первинного по TCP 53?
• Чи приходить NOTIFY (UDP 53)?
• Чи є якийсь middlebox, що робить «корисну» інспекцію DNS?

Далі: доведіть авторизацію та ідентичність

• Чи дозволяє первинний передачі на IP(и) вторинного?
• Чи налаштований TSIG на обох кінцях, і чи дійсно ви його використовуєте для передач?
• Чи маєте справу з правильним view?

Третє: перевірте стан і рух серіалу

• Чи відповідає SOA serial на первинному вашим очікуванням?
• Чи застряг вторинний, бо не може зробити IXFR і постійно падає на AXFR?
• Чи подає вторинний застаріле, бо не завершив передачу?

Четверте: ізолюйте обмеження ємності

• CPU завантажено? Ймовірно DNSSEC‑підписування, буря логів або занадто багато одночасних передач.
• Диск завантажений? Записи зон/журнали або патологічна кількість дрібних оновлень.
• Мережа насичена? Повні передачі, повтори й надто багато вторинних, що оновлюються одночасно.

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

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

Завдання 1: Підтвердити, який сервер є первинним для зони (з будь‑якого місця)

cr0x@server:~$ dig +norecurse SOA example.com @ns1.example.net
;; ANSWER SECTION:
example.com.     3600  IN  SOA  ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300

Що це означає: SOA MNAME — ns1.example.net. Серіал — 2026020401.

Рішення: Це авторитет, з якого слід робити передачі (якщо ви не використовуєте приховані майстри). Якщо ваш «первинний» не вказаний, у вас multi‑master або hidden‑master — підтвердьте список очікуваних майстрів.

Завдання 2: Перевірити, чи AXFR випадково відкритий у світі

cr0x@server:~$ dig AXFR example.com @ns1.example.net
; Transfer failed.

Що це означає: Хороший знак. Сервер відмовив або вам не дозволено.

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

Завдання 3: Протестувати передачу з відомого вторинного і перевірити TSIG

cr0x@server:~$ dig AXFR example.com @ns1.example.net -y transfer-key:7b3Nq9hR7oR6Zp3kVvQb8w==
; (1 server found)
example.com.     3600 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300
example.com.     3600 IN NS  ns1.example.net.
example.com.     3600 IN NS  ns2.example.net.
www.example.com. 300  IN A   203.0.113.10
example.com.     3600 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300
;; Query time: 45 msec
;; XFR size: 28 records (messages 1, bytes 2150)

Що це означає: Передача вдала з TSIG‑ключем. Ви бачили початковий і кінцевий SOA та кількість записів.

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

Завдання 4: Перевірити досяжність TCP 53 (бо AXFR/IXFR — TCP)

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

Що це означає: TCP‑шлях існує.

Рішення: Якщо це падає, але UDP‑запити працюють — виправте фаєрвол/групи безпеки. NOTIFY може ввести в оману, мовляв «DNS відкритий», коли передачі не доступні.

Завдання 5: На первинному перевірити, що BIND думає про зону

cr0x@server:~$ sudo rndc zonestatus example.com
name: example.com
type: master
files: /var/cache/bind/db.example.com
serial: 2026020401
nodes: 1421
last loaded: Tue, 04 Feb 2026 08:12:22 GMT
secure: no
dynamic: no

Що це означає: Майстер має серіал 2026020401, завантажений з конкретного файлу. Це не динамічна зона.

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

Завдання 6: На вторинному перевірити, чи він дійсно слейвить від правильного майстра

cr0x@server:~$ sudo rndc zonestatus example.com
name: example.com
type: slave
masters: 203.0.113.11 port 53
serial: 2026020309
last loaded: Mon, 03 Feb 2026 19:41:03 GMT
next refresh: Tue, 04 Feb 2026 08:01:03 GMT

Що це означає: Вторинний відстає (серіал 2026020309 проти первинного 2026020401). Він вважає майстром 203.0.113.11.

Рішення: Підтвердіть, що IP правильний (патерни прихованих майстрів часто плутають людей). Якщо невірний — виправте список masters. Якщо правильний — діагностуйте авторизацію/досяжність/помилки передачі.

Завдання 7: Примусити вторинний перевірити і стягнути (контрольний поштовх)

cr0x@server:~$ sudo rndc refresh example.com
zone refresh queued

Що це означає: BIND спробує оновити зону; це не гарантія успіху.

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

Завдання 8: Слідкувати за логами саме для повідомлень про передачі

cr0x@server:~$ sudo journalctl -u bind9 -n 50 --no-pager
Feb 04 08:22:10 ns2 named[2143]: zone example.com/IN: refresh: retry limit reached
Feb 04 08:22:10 ns2 named[2143]: zone example.com/IN: Transfer started.
Feb 04 08:22:10 ns2 named[2143]: transfer of 'example.com/IN' from 203.0.113.11#53: connected using 203.0.113.22#47922
Feb 04 08:22:10 ns2 named[2143]: transfer of 'example.com/IN' from 203.0.113.11#53: failed while receiving responses: REFUSED

Що це означає: Первинний відмовляє в передачі. Майже завжди це allow-transfer, невідповідність TSIG або mismatch view на майстрі.

Рішення: Виправте авторизацію на первинному (і будьте явними). Не робіть «тимчасово allow any;» і не забувайте про це.

Завдання 9: Підтвердити позицію allow-transfer на майстрі, переглянувши конфіг

cr0x@server:~$ sudo named-checkconf -p | sed -n '/zone "example.com"/,/};/p'
zone "example.com" {
	type master;
	file "/var/cache/bind/db.example.com";
	allow-transfer { key transfer-key; 203.0.113.22; };
	also-notify { 203.0.113.22; };
};

Що це означає: Ця зона дозволяє передачі або від клієнта з TSIG‑ключем transfer-key, або з IP 203.0.113.22.

Рішення: Надавайте перевагу «лише ключу» для передач, якщо немає конкретної причини дозволяти по IP. Якщо зберігаєте IP‑дозволи — тримайте ACL вузькими і документованими.

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

cr0x@server:~$ sudo named-checkzone example.com /var/cache/bind/db.example.com
zone example.com/IN: loaded serial 2026020401
OK

Що це означає: Зона парситься і серіал такий, як ви очікуєте.

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

Завдання 11: Перевірити одночасність передач і чи не задушуєте ви себе

cr0x@server:~$ sudo rndc status
version: BIND 9.18.24-1ubuntu1.4-Ubuntu (Extended Support Version) <id:...>
running on ns1: Linux x86_64 5.15.0-97-generic
boot time: Tue, 04 Feb 2026 07:45:10 GMT
last configured: Tue, 04 Feb 2026 08:10:03 GMT
current serial: 2026020401
xfrouts running: 12
xfers running: 0

Що це означає: xfrouts running показує вихідні передачі (майстер відсилає). Якщо це число велике, ви можете бути в хвилі передач або під скануванням.

Рішення: Якщо вихідних передач несподівано багато — перевірте, хто підключається і чи не занадто відкриті ваші ACL. Також розгляньте тонку настройку transfers-out та споріднених параметрів (обережно).

Завдання 12: Визначити, хто підключається до TCP/53 на первинному

cr0x@server:~$ sudo ss -tnp 'sport = :53' | head
State  Recv-Q Send-Q Local Address:Port Peer Address:Port  Process
ESTAB  0      0      203.0.113.11:53  203.0.113.22:47922 users:(("named",pid=2143,fd=42))
ESTAB  0      0      203.0.113.11:53  198.51.100.77:51244 users:(("named",pid=2143,fd=51))
ESTAB  0      0      203.0.113.11:53  198.51.100.88:51310 users:(("named",pid=2143,fd=63))

Що це означає: Є встановлені TCP‑з’єднання до порту 53 від кількох пірів. Лише один із них — ваш відомий вторинний.

Рішення: Якщо бачите випадкові інтернет‑IP — вас сканують або ви залишили передачі відкритими. Жорсткіше налаштуйте allow-transfer і розгляньте фаєрвол на TCP/53 лише для довірених вторинних (якщо архітектура дозволяє).

Завдання 13: Довести, що NOTIFY приймається лише від правильних хостів

cr0x@server:~$ sudo named-checkconf -p | sed -n '/options {/,/};/p' | sed -n '1,80p'
options {
	directory "/var/cache/bind";
	allow-notify { 203.0.113.11; };
	notify yes;
};

Що це означає: Сервер обмежує джерела, які можуть надсилати NOTIFY.

Рішення: Якщо allow-notify відсутній на вторинному, розгляньте додавання. Інакше будь‑хто може подзвонити у «дзвінок у двері» і змусити витрачати CPU і логувати перевірки.

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

cr0x@server:~$ dig +norecurse SOA example.com @ns2.example.net
;; ANSWER SECTION:
example.com.     3600  IN  SOA  ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300

Що це означає: Вторинний тепер подає новий серіал.

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

Укріплення BIND9 передач без порушення вторинних

Правило 1: Явно визначайте, хто може передавати, для кожної зони

Почніть із позиції, що передавання заборонені за замовчуванням. Потім робіть точні винятки. У BIND це зазвичай allow-transfer в кожній зоні (або через спільний ACL). Якщо робити це глобально в options, рано чи пізно ви забудете зону, яку треба обробляти інакше.

Правило 2: Віддавайте перевагу TSIG для передач (і регулярно міняйте ключі)

IP‑ACL необхідні, але недостатні. IP змінюються. NAT брешуть. І «але це в приватній мережі» — саме так ви експортуєте зону скомпрометованому хосту всередині периметра.

З TSIG ви отримуєте автентифікацію повідомлень. IP‑політика все ще потрібна, але TSIG дає ідентичність на рівні DNS. Використовуйте сучасні алгоритми (наприклад hmac-sha256) і контролюйте розповсюдження ключів.

Правило 3: Не забудьте політику NOTIFY (це важіль навантаження)

NOTIFY — це не витік даних, але це тригер навантаження. Якщо його може надсилати будь‑хто, будь‑хто може змусити ваші вторинні запускати логіку оновлення і намагатися передавати. Це простий спосіб витратити CPU і простір у логах.

Правило 4: Проєктуйте для доменів відмов, а не тільки «щоб працювало»

Дві практичні архітектури:

• Прихований майстер: внутрішній майстер(и), лише публічні вторинні. Чудова безпекова позиція, але потребує чистої TCP/53 зв’язності від вторинних до майстрів і акуратних ACL.
• Публічний первинний: один із публічних серверів — майстер. Простіше маршрутизація, більша поверхня атаки, більше причин жорстко налаштувати передачі.

Правило 5: Слідкуйте за обсягом передач як за SLO

Якщо ви ніколи не графите швидкість передач і відмови, ви дізнаєтесь про проблему лише тоді, коли користувачі її відчують. Рахуйте:

• співвідношення успішних IXFR до AXFR (раптовий сплеск AXFR — сигнал тривоги)
• помилки передач (REFUSED, NOTAUTH, помилки TSIG, таймаути)
• часи завантаження зон і I/O wait

Правило 6: Використовуйте обмеження — але як хірург, а не як азартний гравець

BIND має параметри, наприклад transfers-out, transfers-in і serial-query-rate. Вони можуть запобігти катастрофі або повільно позбавити ваших вторинних можливості оновлюватися, тож застосовуйте обмеження після того, як зрозумієте нормальну поведінку і матимете видимість.

Жарт №2: Ліміт передач, встановлений занадто низько — як календар на кімнату для нарад: технічно впорядковано, фактично — відмова в обслуговуванні.

Три короткі корпоративні історії з копалень передач зон

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

Середня компанія використовувала hidden‑master: внутрішній майстер і два публічні вторинні. Мережна команда припустила «DNS — це UDP 53», бо більшість користувачів бачить DNS як швидкі UDP‑запити. Їхні фаєрвол‑правила дозволяли вхідний UDP/53 до вторинних і дозволяли вторинним опитувати майстер по UDP/53 «для DNS».

NOTIFY працював. Частково. Майстер надсилав NOTIFY, вторинні отримували його і відразу намагалися тягнути IXFR. Через TCP. Який був заблокований. BIND логував таймаути передач, потім повтори, потім ще спроби. Нічого не оновлювалося.

Це було непомітно деякий час, бо TTL були довгі і кешовані відповіді маскували застарілість. Згодом рутинне оновлення сертифіката додало новий запис для валідації. Деякі резолвери отримали новий запис з внутрішнього view майстра під час розслідування, але публічні вторинні його ніколи не подали. Зовнішні валідації час від часу падали. Команда інцидентного реагування насолоджувалася особливим стресом «в мене все працює» у DNS.

Вони виправили це, дозволивши TCP/53 від вторинних до майстра і ввівши моніторинг дрейфу SOA серіалів вторинних. Висновок постмортему був болісно простий: вони припустили, що DNS означає UDP, і це припущення керувало продакшном — аж поки ні.

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

Велика організація мала сотні зон. Передачі були шумні, тому інженер вирішив «оптимізувати навантаження» шляхом подовження таймерів refresh і зменшення чаттеру NOTIFY. Ідея: менше оновлень — менше передач — менше навантаження.

В steady state це працювало. Графіки стали спокійніші. Потім баг у розгортанні запустив неправильний файл зони: бракувало NS‑запису, на який покладалися деякі резолвери. Вони швидко відкотили. Але ось підступ: багато вторинних ще не оновилися через подовжені інтервали refresh. Частина інфраструктури довго подавала пошкоджену версію.

Клієнти отримували рулетку відповідей залежно від того, до якого авторитетного сервера потрапляли. Підтримка бачила «спорадичні DNS‑збої». Інженери бачили «все виправлено». Обидва твердження були правдиві. Це та правда, що псує післяобідній час.

Відновлення полягало в поверненні sane‑задач refresh/retry, утриманні NOTIFY ввімкненим і виправленні справжньої причини — надто багатьох повних AXFR через відсутність журналів IXFR і недбалі reload‑шаблони. Також ввели playbook відкату, що примусово змушував вторинні оновлюватися після критичних змін DNS.

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

Фінансова компанія мала суворий контроль змін і багато split‑horizon DNS із BIND views. Не захопливо. Цікавість була в їхній дисципліні: кожна зона мала пер‑зонний ACL для передач, TSIG був обов’язковий, кожна зміна проходила через named-checkconf і named-checkzone перед розгортанням. Вони також мали дашборд для «дрейфу серіалів» між майстром і кожним вторинним.

Одного дня вторинний VM відновили зі старого снапшоту після збою гіпервізора. Він піднявся зі застарілим файлом TSIG (старий секрет) і трохи невірним часом через поламаний NTP. Передачі не вдавалися. Вторинний продовжував подавати застаріле.

Моніторинг швидко це виявив: алерт про дрейф серіалу плюс повідомлення про помилки передач. На чергуванні не довелося гадати. Замінити ключ TSIG, виправити NTP і примусово оновити. Інцидент був коротким, локалізованим і—найголовніше—нудним у поясненні.

Це стандарт, якого варто прагнути. Не героїзм. А суворий контроль, попередні перевірки і видимість, що показує точно, який саме вторинний бреше.

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

1) Симптом: вторинний ніколи не оновлюється; у логах REFUSED

Корінь: allow-transfer первинного не включає IP вторинного або TSIG‑ключ, або вторинний потрапляє у неправильний view на первинному.

Виправлення: На первинному явно вкажіть allow-transfer для тієї зони (надавайте перевагу TSIG). Підтвердьте узгодженість view, перевіривши, з якої адреси/в якому view заходить запит.

2) Симптом: передачі успішні інколи, інколи ні

Корінь: У вторинного вказано кілька майстрів; один доступний, але не авторизований, або NAT змінює вихідний IP непередбачувано, або є ускладнення з anycast.

Виправлення: Використовуйте TSIG, щоб автентифікація не залежала від вихідного IP. Обріжте список майстрів до потрібного набору. Якщо є anycast, переконайтеся, що цілі передач стабільні, а не «ближній вузол рулетка».

3) Симптом: раптовий сплеск обсягу AXFR; мережеве використання зростає

Корінь: IXFR недоступний (втрачені журнали, зміни inline‑signing, часті reload’и), або вторинні переведені на повні передачі після збоїв.

Виправлення: Дослідіть, чому IXFR падає. Переконайтеся, що журнали увімкнені/зберігаються. Уникайте непотрібних reload‑патернів. Розгляньте обмеження передач лише після зменшення повних трансферів.

4) Симптом: вторинні подають старі дані після відкату

Корінь: Інтервали refresh занадто великі, NOTIFY відключений або відкат не спричинив примусового оновлення.

Виправлення: Тримайте NOTIFY увімкненим для керованих вторинних. Для відкатів використовуйте rndc notify на майстрі і rndc refresh на вторинних, щоб швидко досягти збігу.

5) Симптом: помилки TSIG, наприклад «bad key» або «clock skew»

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

Виправлення: Переконайтеся, що визначення ключа точно збігається на обох кінцях. Забезпечте здоровий NTP. Обертаючи ключі, тримайте старий і новий паралельно під час міграції при потребі.

6) Симптом: передачі працюють для одного view, але не для іншого

Корінь: Зона існує в кількох view; allow-transfer встановлено лише в одному, або вихідна адреса вторинного потрапляє в інший view, ніж очікується.

Виправлення: Зробіть намір щодо view явним. Використовуйте match-clients і/або виділені інтерфейси для передач. Налаштуйте передачі для кожного view і тестуйте з реального вихідного IP вторинного.

7) Симптом: «connection reset» або таймаути під час передачі

Корінь: Middlebox обриває довгі TCP‑з’єднання, проблеми з MTU або ресурсне навантаження сервера (файловий ввід/вивід, черга TCP).

Виправлення: Зніміть tcpdump на обох сторонах, перевірте path MTU, збільшіть системні TCP‑ліміти при потребі і зменшіть частоту повних AXFR, виправивши IXFR/журнали.

8) Симптом: неавторизовані сторони можуть AXFR вашу зону

Корінь: allow-transfer { any; }; або відсутні обмеження на майстрі, разом з відкритим TCP/53.

Виправлення: Заблокуйте на рівні зони вузькими ACL/TSIG. Розгляньте фаєрвол на TCP/53 лише для відомих вторинних. Періодично проводьте аудит зовнішніми тестами.

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

Крок за кроком: заблокуйте передачі, не порушивши реплікацію

1. Проведіть інвентар зон і очікуваних вторинних. Складіть список: зона → майстер(и) → IP вторинних → чи потрібен TSIG.
2. Визначте політику за замовчуванням: TSIG обов’язковий для всіх передач, якщо немає задокументованого винятку.
3. Створіть окремі ACL для середовищ. Тримайте їх читабельними. «acl secondaries-prod { … }» краще, ніж купа IP у кожному блоці зони.
4. Реалізуйте per‑zone allow-transfer. Віддавайте перевагу лише ключу. Якщо треба включити IP, додавайте тільки вторинні.
5. Обмежте обробку NOTIFY на вторинних. Налаштуйте allow-notify приймати лише від майстрів.
6. Переконайтеся, що правила фаєрволу відповідають реальності протоколів. Дозвольте secondary → master TCP/53. Дозвольте master → secondary UDP/53 для NOTIFY (або погодьтеся на лише періодичні оновлення, якщо вимикаєте NOTIFY).
7. Увімкніть логування, яке може довести, що сталося. Потрібні чіткі логи успішних і неуспішних передач, без утоплення в шумі.
8. Розгортайте поступово. Почніть з однієї зони і одного вторинного. Перевірте, потім розширюйте.
9. Підтвердіть збіжність. Порівняйте SOA serial на всіх серверах після зміни.
10. Додайте моніторинг: дрейф серіалів, помилки передач і обсяг передач. Алертуйте на дрейф понад поріг і на тривалі відмови.
11. Тестуйте зовні. Спробуйте AXFR з ненадійної мережі і переконайтеся, що це не працює.
12. Описуйте процес винятків. Якщо комусь потрібен тимчасовий доступ — це має мати термін дії і тикет, а не пам’ять.

Операційний чеклист: при додаванні нового вторинного

• Підтвердьте вихідні IP вторинного (особливо при NAT/контейнерах).
• Згенеруйте і безпечно розподіліть TSIG‑ключ.
• Додайте ключ і асоціацію сервера на обох кінцях.
• Оновіть allow-transfer на майстер‑зонах.
• Оновіть also-notify на майстрі (необов’язково, але рекомендовано).
• Оновіть allow-notify на вторинному.
• Протестуйте TCP/53 досяжність обома шляхами, як потрібно.
• Примусово зробіть початкову передачу і підтвердіть, що SOA serial співпадає.

Операційний чеклист: коли сплеск передач

• Визначте, хто підключається до TCP/53.
• Перевірте логи на REFUSED проти TSIG проти таймаутів.
• Виміряйте співвідношення AXFR vs IXFR.
• Перевірте цикли перезавантаження зон (автоматизація інколи штовхає незмінені зони).
• Розгляньте тимчасові обмеження/ліміти передач тільки після підтвердження, що авторизація не надмірно відкрита.

FAQ

1) Чи варто взагалі вимикати передачі зон?

Лише якщо ви не використовуєте вторинний DNS. Якщо у вас є вторинні — вам потрібні передачі (або альтернативний механізм реплікації). Правильний підхід — сувора авторизація + TSIG.

2) Чи TSIG достатньо, чи все ж потрібні IP‑ACL?

Використовуйте обидва, де можливо. TSIG автентифікує на рівні DNS; IP‑ACL зменшують шум і експозицію. Захист у глибину, а не догма.

3) Чому мої вторинні повільно оновлюються, хоча NOTIFY увімкнений?

Бо NOTIFY лише тригерить перевірку. Якщо TCP/53 заблокований, TSIG не проходить або майстер відмовляє у передачі, вторинний все одно чекатиме і робитиме повтори. Перевірте логи на першу помилку після NOTIFY.

4) Який найшвидший спосіб зрозуміти, чи витікають мої зони?

З зовнішнього ненадійного хоста спробуйте dig AXFR zone @auth. Він має відмовити. Якщо ні — виправляйте негайно, не чекайте обіду.

5) AXFR працює з одного вторинного, але не з іншого. Чому?

Найпоширеніші причини: не додано IP того вторинного до allow-transfer, TSIG неправильно налаштований на тому вузлі, або трафік вторинного походить з іншої IP (контейнери/NAT).

6) Можна запускати передачі на нестандартному порту?

Можна, але зазвичай це завдає собі шкоди. Стандартизація на TCP/53 знижує складність правил фаєрволу і tribal knowledge. Якщо змінюєте порт — документуйте і тестуйте ретельно.

7) Чи впливають BIND views на передачі зон?

Так. Передачі відбуваються в контексті view. Якщо вторинний потрапляє в інший view, ніж очікується, він може отримати REFUSED або реплікувати невірний набір відповідей. Будьте явними з match-clients і тестуйте з реального вихідного IP вторинного.

8) Як безпечно обертати TSIG‑ключі без даунтайму?

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

9) Добре покладатися на «allow-transfer { none; }» глобально і перевизначати по зоні?

Так. Це розумний дефолт. Просто переконайтеся, що реально перевизначаєте для зон, яким потрібні вторинні, і моніторте, щоб помічати, коли щось забули.

10) Якщо я фаєрволю TCP/53 лише до вторинних, чи все ще потрібен allow-transfer?

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

Наступні кроки

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

1. Аудит експозиції: спробуйте AXFR з ненадійної мережі проти кожного авторитетного сервера, який ви експлуатуєте.
2. Зробіть передачі явними: per‑zone allow-transfer і per‑secondary TSIG.
3. Виправте транспортну реальність: забезпечте secondary → master TCP/53; узгодьте шляхи NOTIFY з вашою політикою фаєрволу.
4. Додайте моніторинг дрейфу серіалів: якщо вторинний відстає, ви маєте знати до користувачів.
5. Потренуйте одну контрольовану відмову: навмисно зломайте TSIG на стендовому вторинному і підтвердіть, що ваші алерти, логи і руктбук ведуть до правильного виправлення.

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