Як налаштувати вторинний DNS-сервер
Що таке вторинний DNS-сервер?
Вторинний DNS-сервер (його ще називають slave-сервером) зберігає копію даних вашої DNS-зони лише для читання. Він отримує оновлення з первинного (master) сервера через трансфер зони — повний AXFR або інкрементний IXFR.
Коли резолвер робить запит до вашого домену, відповідь може надати як первинний сервер, так і будь-який вторинний, указаний у ваших NS-записах. Це дає резервування: якщо первинний сервер вийде з ладу, вторинні продовжать віддавати останні коректні записи, і ваш домен залишиться доступним. Ролі первинного та вторинного серверів визначає RFC 1034.
Ви редагуєте записи в одному місці — на первинному сервері — а кожен вторинний автоматично віддзеркалює ці зміни через трансфер зони. Після налаштування нема чого підтримувати щодня, тож вторинний сервер — це найпростіший і визнаний реєстраторами спосіб додати стійкість вашому DNS.
Навіщо потрібен вторинний DNS-сервер
Більшість реєстраторів доменів вимагають щонайменше два неймсервери, перш ніж делегувати зону. Та окрім цього мінімуму, вторинний DNS-сервер дає вам:
– Стійкість до збоїв і технічних робіт на первинному сервері – Менші затримки відповіді завдяки розміщенню неймсерверів у різних географічних регіонах і мережах – Захист від DDoS-атак, спрямованих на один сервер чи одну мережу – Відповідність RFC 2182, який рекомендує щонайменше три неймсервери в окремих мережах для кожної зони
Якщо хочете повне обґрунтування того, навіщо тримати кілька неймсерверів, перегляньте наш посібник про резервування та відмовостійкість DNS.
Автоматична синхронізація зон DNS
Синхронізацію визначають SOA-запис зони та повідомлення NOTIFY:
– Після першого AXFR вторинний сервер перевіряє зону через кожен інтервал refresh (другий таймер у SOA-записі). – Якщо первинний сервер надсилає NOTIFY (RFC 1996) за кожної зміни, вторинні підтягують оновлення за секунди, не чекаючи на таймер refresh. – Збільшений серійний номер SOA — це сигнал, який повідомляє вторинному серверу, що з’явилися нові дані. Завжди збільшуйте його після редагування зони, інакше вторинний сервер не побачить ваших змін.
Механіку AXFR, IXFR, таймери SOA та підписування TSIG докладно розібрано в посібнику Як працюють трансфери зон AXFR.
Вимоги до налаштування вторинного DNS
Перш ніж почати, переконайтеся, що у вас є:
1. Первинний DNS-сервер на BIND, PowerDNS, Knot, NSD або іншому ПЗ із підтримкою AXFR 2. Публічна IP-адреса цього первинного сервера 3. Дозволений AXFR (трансфер зони) на первинному для IP-адреси вторинного сервера 4. Доступ до реєстратора домену для редагування NS-записів
TCP-порт 53 має бути доступним на первинному сервері — AXFR працює через TCP, а не UDP. Фаєрвол, який пропускає лише UDP/53, відповідатиме на звичайні запити, але мовчки ламатиме трансфери зон.
Дозвольте трансфери зон на первинному DNS
На первинному сервері дозвольте AXFR для IP-адреси вторинного сервера.
Для 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 дозвольте AXFR і ввімкніть NOTIFY у pdns.conf:
allow-axfr-ips=192.0.2.1/32
also-notify=192.0.2.1Для Knot DNS чи NSD дозвольте вторинний сервер у налаштуваннях трансферу й notify зони — Knot використовує правила acl (action: transfer і notify), NSD — provide-xfr і notify. Точний синтаксис дивіться в документації Knot DNS та NSD.
Замініть 192.0.2.1 на справжню IP-адресу вашого вторинного DNS-сервісу. Для робочих зон додатково обмежте трансфери ключем TSIG — про це в розділі безпеки посібника з AXFR.
Додайте домен на вторинний DNS
Якщо ви користуєтеся керованим вторинним DNS-сервісом, додайте свій домен через панель або API. Укажіть назву зони та IP-адресу первинного сервера — решту зробить вторинний сервер.
Вторинний сервер одразу спробує AXFR, щоб підтягнути повну зону. Після цього першого трансферу він тримає синхронізацію за інтервалом refresh із SOA або миттєво через NOTIFY, якщо первинний налаштований його надсилати. Якщо вашого вторинного сервера немає в NS-записах зони (stealth- або прихований варіант), додайте його IP до also-notify, щоб він і далі отримував сповіщення про зміни.
У SecondDNS можна додати першу зону безкоштовно — у межах 3-місячного пробного періоду, без банківської картки, і переконатися, що трансфери працюють ще до того, як прописувати вторинний сервер у NS-записах. Створіть акаунт, щоб отримати IP вторинного сервера — саме цю адресу потрібно дозволити в Дозвольте трансфери зон на первинному DNS.
Оновіть NS-записи у реєстратора
Щойно вторинний сервер почне синхронізуватися, додайте його як неймсервер у свого реєстратора домену.
Якщо ваш первинний сервер — ns1.example.com, а вторинний — ns1.seconddns.com, делегування має містити обидва:
example.com. NS ns1.example.com.
example.com. NS ns1.seconddns.com.Залиште NS-запис первинного сервера на місці — обидва сервери відповідатимуть на запити. Якщо хост вторинного сервера живе у вашому власному домені (наприклад, ns2.example.com), вам також потрібно зареєструвати glue records у реєстратора, щоб резолвери могли знайти його IP. Використання хоста провайдера на кшталт ns1.seconddns.com повністю усуває крок із glue records; якщо хочете власні (vanity) NS-імена у своєму домені, перегляньте персональні неймсервери.
Перевірте роботу вторинного DNS
Перевірте, що обидва неймсервери віддають однакові дані:
dig @ns1.example.com example.com SOA
dig @ns1.seconddns.com example.com SOAОбидва мають повернути однаковий серійний номер SOA. Якщо серійний номер на вторинному менший — трансфер зони ще не завершився; перевірте правила фаєрвола та налаштування allow-transfer із Дозвольте трансфери зон на первинному DNS.
Переконайтеся, що делегування містить обидва сервери:
dig example.com NSЗапросіть у вторинного сервера повну зону — так ви переконаєтесь, що AXFR для нього дозволено. З вашої авторизованої IP-адреси запит має спрацювати, а з будь-якої іншої — отримати відмову:
dig @ns1.seconddns.com example.com AXFRСкільки триває поширення (propagation)?
Зміни NS-записів визначаються TTL делегування в батьківській зоні, а не TTL усередині вашої власної зони. На практиці закладайте 24–48 годин на те, щоб новий неймсервер став видимим для всіх резолверів у світі, хоча більшість резолверів підхоплять його значно швидше.
Протягом цього періоду чинними лишаються і старе, і нове делегування, тож простою не буде — за умови, що кожен сервер із ваших NS-записів відповідає коректно. Саме тому ви перевіряєте вторинний сервер у Перевірте роботу вторинного DNS до зміни делегування в реєстратора.
Усунення несправностей налаштування вторинного DNS
Поширені проблеми та як їх виправити:
Трансфер зони відхилено — первинний сервер не дозволяє AXFR з IP вторинного. Перевірте allow-transfer (BIND) чи allow-axfr-ips (PowerDNS) і правила фаєрвола на TCP-порту 53.
Застарілі записи на вторинному — NOTIFY не доходить до вторинного, або інтервал refresh у SOA задовгий. Увімкніть also-notify на первинному або зменште таймер refresh.
Серійний номер не зростає — якщо ви редагуєте зону вручну, але забуваєте збільшити серійний номер SOA, вторинний сервер ніколи не підтягне зміну. Завжди збільшуйте серійний номер; багато адміністраторів використовують формат YYYYMMDDnn.
Вторинного немає в DNS — зміни NS-записів можуть поширюватися 24–48 годин. Перевіряйте через dig на конкретних резолверах (наприклад, dig @8.8.8.8 example.com NS).
Тайм-аут з’єднання — TCP-порт 53 заблоковано між первинним і вторинним. AXFR використовує TCP; фаєрвол, який дозволяє лише UDP/53, пропускатиме запити, але ламатиме трансфери.
Налаштовуєте це в панелі керування хостингом? Скористайтеся покроковими посібниками для cPanel/WHM, Plesk, DirectAdmin чи CyberPanel.
Пов’язані посібники
– Як працюють трансфери зон AXFR – Резервування DNS: чому це важливо і як його забезпечити – Персональні неймсервери: налаштування, glue records і підводні камені – Як додати вторинний DNS до панелі керування хостингом cPanel/WHM – Як додати вторинний DNS до панелі хостингу Plesk – Як додати вторинний DNS до хостинг-панелі DirectAdmin – Як додати вторинний DNS до хостинг-панелі CyberPanel