Вторинний DNS-сервер: що це і як працює

Що таке вторинний DNS-сервер?

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

Ззовні первинний і вторинний не відрізняються. Обидва є в NS-записах домену, обидва відповідають із прапорцем AA (authoritative answer), а резолвери обирають того, хто відповідає швидше. Різниця лише в тому, де редагуються дані: ви змінюєте записи на первинному, а вторинний іде за ним.

Старіша документація та багато конфігураційних файлів досі називають ці дві ролі master і slave. BIND, PowerDNS і більшість панелей приймають обидві назви; значення те саме.

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

Первинний і вторинний DNS

Первинний (master). Тримає редаговану копію зони — у файлах зон для BIND, у базі даних для PowerDNS, у сховищі панелі для cPanel, Plesk, DirectAdmin чи CyberPanel. Кожна зміна запису відбувається тут, і кожна зміна має збільшувати serial у SOA зони.

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

Що це означає на практиці:

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

Як вторинний отримує зону

Механізм — це передача зони, визначена самим протоколом DNS, тож будь-який вторинний може працювати з будь-яким первинним незалежно від програмного забезпечення.

1. Дозвіл. Первинний має дозволити передачі на IP-адресу вторинного (allow-transfer у BIND, allow-axfr-ips у PowerDNS) або приймати спільний ключ TSIG. Без цього вторинному відмовляють. 2. Перша передача. Вторинний запитує всю зону запитом AXFR через TCP-порт 53 і зберігає результат. Від цього моменту він авторитетний для зони. 3. Підтримання синхронізації. Вторинний перевіряє SOA-запис первинного за розкладом, заданим значенням refresh у SOA зони. Якщо serial первинного більший за його власний, він виконує передачу знову — усієї зони (AXFR) або лише змін (IXFR), коли обидві сторони це підтримують. 4. NOTIFY. Замість чекати таймера refresh, первинний може надіслати повідомлення NOTIFY тієї ж миті, коли зона змінюється; вторинний тоді перевіряє serial негайно. З налаштованим NOTIFY зміни доходять до вторинного за секунди. 5. Термін дії. Якщо первинний лишається недосяжним довше за значення expire у SOA, вторинний перестає відповідати за зону, аби не віддавати дані, які можуть бути дуже застарілими.

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

Чому вам потрібен вторинний DNS-сервер

Доступність. Єдиний авторитетний неймсервер — це єдина точка відмови для кожного домену на ньому. Перезавантаження для оновлення ядра, апаратний збій, DDoS на сервер — і домени не резолвляться взагалі: сайти, пошта й API зупиняються разом. Із вторинним в іншій мережі резолвери отримують відповіді від нього, а користувачі нічого не помічають.

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

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

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

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

Власний вторинний чи хостований

Власний другий сервер. Друга інсталяція BIND чи PowerDNS на іншій машині, в ідеалі в іншому дата-центрі, налаштована як вторинний для кожної зони. Це дає повний контроль і коштує лише сервера. Ціна — операційна: другий хост, який треба оновлювати й моніторити, правила фаєрвола з обох боків, і кожну нову зону треба реєструвати на вторинному вручну — або автоматизувати скриптами, які ви самі супроводжуєте. Багато конфігурацій з одним сервером саме через це до вторинного так і не доходять.

Хостований сервіс вторинного DNS. Провайдер тримає вторинні неймсервери; ви дозволяєте передачі зон з його IP і спрямовуєте свої NS-записи на його хостнейм (або на власний хостнейм із glue-записом — див. Що таке glue-записи DNS і коли вони потрібні). Ваш сервер лишається первинним, у способі редагування DNS ніщо не змінюється, а робота провайдера — бути доступним тоді, коли ваш сервер недоступний. Компроміс у тому, що половина вашого DNS залежить від третьої сторони, тож важать її доступність і відокремленість її мережі від вашої.

Панелі хостингу. У cPanel, Plesk, DirectAdmin і CyberPanel ручний шлях складніший, ніж здається: панель перегенеровує конфігурацію DNS-сервера, тож ручні правки перезаписуються, а кожен новий домен потрібно реєструвати на вторинному. Саме для цього існують інтеграції, що чіпляються до подій доменів у панелі; гайди з панелей нижче показують і ручний, і автоматизований шлях.

Що б ви не обрали, перелік перевірок той самий: передачі дозволені з адреси вторинного, NOTIFY увімкнено, TCP 53 відкритий, обидва неймсервери в делегуванні, а serial збільшується за кожної зміни.

Як перевірити, що вторинний працює

Запитайте у кожного авторитетного сервера SOA-запис зони напряму. Замініть example.com на свій домен, а два хостнейми — на свої неймсервери:

dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short

Обидва мають відповісти, а серійний номер (третє поле) має бути однаковим. Вторинний, що відповідає меншим serial, не підхопив останню зміну; той, що відповідає SERVFAIL або REFUSED, ніколи не завантажував зону або її термін дії збіг.

Перевірте делегування таким, яким його бачить світ:

dig NS example.com +short

Обидва неймсервери мають бути в списку. Вторинний, ідеально синхронізований, але відсутній у NS-записах, не отримує запитів і нічого не захищає.

Насамкінець переконайтеся, що сама передача зони можлива з мережі вторинного — з хоста вторинного або з будь-якого хоста, чий IP дозволяє первинний:

dig AXFR example.com @ns1.example.com

Повний лістинг зони означає, що передачі працюють; transfer failed або REFUSED означає, що правила allow-transfer первинного чи фаєрвол на TCP 53 блокують вторинний.

Поширені помилки

- Забути збільшити serial у SOA. Первинний відповідає новими даними, вторинний бачить той самий serial і ніколи не виконує передачу. Найпоширеніша причина ситуації «працює на ns1, не працює на ns2». - Відкрити UDP 53, але не TCP 53. Запити працюють, передачі — ні. Термін дії кожної зони на вторинному тихо збігає. - Не додати вторинний до NS-записів. Вторинний ідеально синхронізується, і його ніколи ні про що не запитують. - Обидва неймсервери на одному хості чи в одній мережі. Задовольняє форму реєстратора, але не ту відмову, яку має пережити. - Короткий expire у SOA. Один день — звичне значення в типових налаштуваннях панелей; простій первинного на вихідних тоді тягне за собою і вторинний. Звичне значення — два тижні. - Редагування записів на вторинному. Вони зникають за наступної передачі. - Забути про вторинний, додаючи новий домен. Кожну нову зону треба зареєструвати на вторинному, вручну чи автоматично; зона, що існує лише на первинному, не має жодного резервування.

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

Налаштування та механізми, що лежать в основі:

- Як налаштувати вторинний DNS-сервер - Як працюють трансфери зон AXFR - Що таке SOA-запис DNS і чому він важливий для вашого домену - Резервування DNS: чому це важливо і як його забезпечити - Що таке glue-записи DNS і коли вони потрібні

Панелі хостингу:

- Як додати вторинний DNS до панелі керування хостингом cPanel/WHM - Як додати вторинний DNS до панелі хостингу Plesk - Як додати вторинний DNS до хостинг-панелі DirectAdmin - Як додати вторинний DNS до хостинг-панелі CyberPanel