Як працюють трансфери зон AXFR

Що таке AXFR?

Сервіс вторинного DNS — AXFR zone transfer і автоматична синхронізація зон

AXFR (повний трансфер зони) — це механізм протоколу DNS, який реплікує цілу зону з первинного сервера імен на вторинний. Коли вторинному серверу потрібна копія зони, він надсилає запит AXFR до первинного, а той у відповідь надсилає кожен запис зони одним TCP-потоком.

AXFR описано в RFC 5936, і працює він через TCP на порту 53 — не через UDP, бо повна зона зазвичай більша за одну UDP-датаграму. Трансфер охоплює кожен запис зони: SOA, NS, A, AAAA, MX, CNAME, TXT і решту. Коротко: AXFR — це те, завдяки чому вторинний сервер DNS отримує авторитетну копію ваших даних DNS і лишається з нею синхронізованим.

Повна та інкрементальна передача зон DNS

Є два типи трансферу зони:

AXFR (повний трансфер): щоразу передає цілу зону. Просто й надійно, але на великих зонах витрачає більше трафіку.

IXFR (інкрементний трансфер, RFC 1995): передає лише ті записи, що змінилися від останнього серійного номера на вторинному. Набагато ощадливіший для великих зон, де часто бувають дрібні правки.

Більшість програм DNS підтримує обидва типи. Вторинний сервер зазвичай спершу пробує IXFR і вдається до AXFR, якщо первинний не підтримує інкрементні трансфери, якщо запитаний серійний номер надто старий, щоб обчислити різницю, або якщо журнал IXFR на первинному обрізаний. Тож AXFR — це надійна основа, що працює завжди, а IXFR — оптимізація поверх неї.

Як працює трансфер зони DNS

Трансфер зони проходить такі кроки:

1. Вторинний сервер перевіряє запис SOA на первинному — або за таймером оновлення, або коли отримає повідомлення NOTIFY. 2. Якщо серійний номер SOA на первинному більший, ніж у локальній копії вторинного, потрібен трансфер. 3. Вторинний надсилає запит AXFR (чи IXFR) до первинного на TCP-порт 53. 4. Первинний перевіряє, чи вторинному дозволено трансфер (за IP-ACL та/або TSIG), і якщо так — надсилає дані зони. 5. Вторинний замінює (AXFR) або вносить зміни (IXFR) у свою локальну копію і починає відповідати вже новими даними.

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

Інтервали оновлення та повтору зони DNS

Запис SOA містить чотири параметри часу, що керують поведінкою трансферу зони:

Refresh (оновлення): як часто вторинний перевіряє первинний на наявність змін (наприклад, 3600 = щогодини).

Retry (повтор): як часто вторинний повторює спробу, коли первинний недоступний (наприклад, 900 = кожні 15 хвилин).

Expire (завершення терміну): скільки часу вторинний продовжує відповідати за зону, поки не може дістатися первинного (наприклад, 604800 = 7 днів). Коли термін збігає, вторинний перестає відповідати за зону — тому довгий expire рятує вас під час тривалого простою первинного.

Minimum TTL: TTL негативного кешування — як довго резолвери зберігають у кеші відповідь NXDOMAIN — береться як менше з цього поля та власного TTL запису SOA, згідно з RFC 2308.

Для зон, що часто змінюються, ставте нижчий refresh — але якщо налаштовано NOTIFY, refresh важить значно менше, бо зміни доходять майже миттєво. Для стабільних зон вищі значення зменшують зайвий трафік.

Синхронізація зони DNS в реальному часі через NOTIFY

Замість того щоб чекати на таймер оновлення, первинний надсилає своїм вторинним повідомлення NOTIFY (RFC 1996) одразу після того, як зона змінилася. NOTIFY каже вторинному «негайно звір свій серійний номер», і це запускає перевірку SOA та трансфер, якщо він потрібен.

NOTIFY скорочує затримку між зміною на первинному та її появою на вторинних із хвилин (інтервал refresh) до секунд.

Більшість програм DNS надсилає NOTIFY автоматично кожному серверу, що внесений до записів NS зони. Якщо вторинного немає в наборі NS — а так буває, коли ви користуєтеся прихованим (stealth) вторинним сервером провайдера, — додайте його окремою ціллю also-notify, щоб оновлення доходили й до нього.

Тестування трансферу зон DNS за допомогою dig

Ви можете запросити AXFR вручну через dig, щоб переконатися, що трансфер працює, — або щоб перевірити, чи ваша зона небезпечно відкрита. Попросіть у конкретного сервера повну зону:

dig AXFR example.com @ns1.example.com

Якщо сервер дозволяє трансфер, dig виведе всі записи зони. Якщо доступ правильно обмежено, ви натомість отримаєте:

; Transfer failed.

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

З боку вторинного звірте, чи збігаються серійні номери після трансферу:

dig SOA example.com @primary-ip +short
dig SOA example.com @secondary-ip +short

Обидва мають повернути той самий серійний номер SOA. Якщо вторинний показує менший — трансфер не завершився, перевірте NOTIFY, ACL і TCP-порт 53.

Безпека трансферу зони DNS

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

ACL за IP: дозволяйте AXFR лише з відомих вам IP-адрес вторинних серверів. Це найпоширеніший і найпростіший засіб контролю.

TSIG (підписи транзакцій, RFC 8945): криптографічна автентифікація зі спільним секретом. Надійніша за ACL за IP, бо її не обійти підміною IP, і вона працює навіть тоді, коли IP вторинного змінюється.

Правила фаєрвола: лишайте TCP-порт 53 доступним лише з авторизованих вторинних серверів.

Ніколи не використовуйте allow-transfer { any; } (чи аналогічну директиву в PowerDNS). Перевірте власні домени командою dig AXFR, наведеною вище — якщо публічний запит повертає записи, ваша зона відкрита, і її варто закрити негайно.

Захист трансферів зон за допомогою TSIG

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

Згенеруйте ключ (інструментами BIND):

tsig-keygen -a hmac-sha256 transfer-key

Це виведе блок ключа. На первинному BIND опишіть ключ і зробіть його обов'язковим для трансферів:

key "transfer-key" {
    algorithm hmac-sha256;
    secret "BASE64_SECRET_HERE";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { key "transfer-key"; };
};

На вторинному задають ту саму назву ключа, алгоритм і секрет, і він подає їх, коли запитує трансфер. Використовуйте той самий ключ з обох боків — і ніколи не зберігайте секрет у системі контролю версій.

Приклади конфігурації трансферу зон

BIND (на первинному сервері):

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { 192.0.2.1; };
    also-notify { 192.0.2.1; };
};

PowerDNS (на первинному сервері):

allow-axfr-ips=192.0.2.1/32
also-notify=192.0.2.1
disable-axfr=no

Замініть 192.0.2.1 на справжню IP-адресу вашого вторинного сервера DNS.

Усунення несправностей трансферу зон

Трансфер відхилено: перевірте налаштування allow-transfer / ACL на первинному й переконайтеся, що IP вторинного (чи ключ TSIG) збігається. Перевірте через dig AXFR із мережі вторинного.

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

Серійний номер не зростає: первинний має піднімати серійний номер SOA за кожної зміни. У форматі YYYYMMDDNN стежте, щоб NN збільшувався при кількох правках за день, інакше вторинний не побачить змін.

Вторинний показує застарілі дані: переконайтеся, що NOTIFY налаштовано. Без нього вторинний оновлюється лише з інтервалом refresh у SOA.

Трансфер великої зони зривається: дуже великі зони (мільйони записів) можуть наразитися на обмеження часу очікування TCP посеред трансферу. Збільште налаштування трансферу/часу очікування з обох боків і віддавайте перевагу IXFR, щоб передавалися лише зміни.

Не хочете тримати й налагоджувати власний вторинний сервер? SecondDNS надає керований вторинний DNS з автоматичною AXFR-синхронізацією — почніть безкоштовно.

Пов'язані гайди

Щоб застосувати трансфери зон зі службою вторинного DNS чи панеллю хостингу, перегляньте:

- Як налаштувати вторинний DNS-сервер - Резервування DNS: чому це важливо і як його забезпечити - Персональні неймсервери: налаштування, glue records і підводні камені - Як додати вторинний DNS до cPanel/WHM - Як додати вторинний DNS до Plesk - Як додати вторинний DNS до DirectAdmin - Як додати вторинний DNS до CyberPanel