Що таке делегування піддомену
Делегування піддомену — це передавання керування окремою гілкою зони на інші 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 записів усередині піддомену, щоб зміни застосовувалися швидко.