До основного вмісту

Делегування піддомену на чужі NS-сервери

Домени · 29.09.2026

Що таке делегування піддомену

Делегування піддомену — це передавання керування окремою гілкою зони на інші NS-сервери, без перенесення всього домену. Наприклад, shop.example.com може обслуговуватися DNS-серверами платформи інтернет-магазину, поки example.com залишається на серверах ZevsHost. Батьківська зона зберігає лише NS-записи, які вказують, хто відповідає за піддомен, а всі A, CNAME і TXT-записи піддомену живуть уже на чужих серверах.

Така схема потрібна, коли піддомен підключають до зовнішнього сервісу: CDN, платформи розсилок, окремої хмари чи партнерської системи, у якої свої вимоги до DNS-записів.

Як прописати делегування в батьківській зоні

Делегування задається NS-записами для імені піддомену. У зоні example.com додають:

shop     IN NS  ns1.partner-dns.com.
shop     IN NS  ns2.partner-dns.com.

Зверніть увагу на крапку в кінці імені сервера — вона означає повне доменне ім'я (FQDN) і є обов'язковою в зонних файлах BIND. Після додавання записів жодних A чи CNAME для shop.example.com в основній зоні бути не повинно: вони будуть ігноруватися, тому що за ім'я тепер відповідають зовнішні NS.

Партнер має підняти зону shop.example.com на вказаних серверах і додати туди власні A, MX та інші записи — інакше делегування вказуватиме в порожнечу.

Glue-записи: коли без них не обійтися

Якщо NS-сервери піддомену самі знаходяться всередині того самого домену — наприклад, ns1.shop.example.com — виникає циклічна залежність: щоб дізнатися IP сервера ns1, потрібно спитати його самого. Цю проблему вирішують glue-записи — A-записи для NS-сервера, які публікуються прямо в батьківській зоні поруч із делегуванням:

shop        IN NS  ns1.shop.example.com.
ns1.shop    IN A   203.0.113.10

Якщо NS-сервери піддомену знаходяться в чужому домені (як у прикладі з partner-dns.com), glue-записи не потрібні — резолвер і так може знайти їхній IP через звичайний DNS-запит.

Перевірка делегування після налаштування

Після публікації зони перевірте, що делегування справді працює:

dig shop.example.com NS +trace

У відповіді мають з'явитися NS-сервери партнера, а не старі сервери example.com. Детальний розбір команди dig і типових відповідей серверів — у статті про перевірку DNS-зони. Додатково опитайте самі делеговані сервери напряму:

dig shop.example.com A @ns1.partner-dns.com

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

Типові помилки делегування

ПроблемаПричина
Піддомен не резолвиться нідеЗабули створити зону на делегованих серверах
Працює у частини користувачівСтарий TTL NS-запису ще не сплив у кеші резолверів
SERVFAIL при запиті A-записуНемає glue-запису для NS усередині того самого домену
Делегування не підтверджується через dig +traceПомилка в імені NS-сервера чи зайва крапка

Чек-лист делегування піддомену

  • Уточніть у партнера точні імена NS-серверів і не використовуйте IP замість імен.
  • Додайте NS-записи в батьківську зону, без супутніх A і CNAME для того самого імені.
  • Налаштуйте glue-записи, якщо NS-сервер сам входить у делегований чи батьківський домен.
  • Перевірте делегування через dig +trace з двох різних резолверів.
  • Узгодьте з партнером TTL записів усередині піддомену, щоб зміни застосовувалися швидко.
← Назад до бази знань Поставити питання підтримці