Делегування доменів Пояснено: Повний посібник з DNS Authority та управління піддоменами

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

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

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

Делегування домену — це процес передачі авторитетного контролю над конкретним доменом або поддоменом до визначеного набору серверів імен. На практиці це означає повідомлення інтернету: *"Щодо запитань про цей домен або поддомен, запитайте ці сервери імен — вони відповідають."*

Коли виконується DNS запит для домену, резолвери слідують ланцюгу авторитету. Делегування домену визначає цей ланцюг. Без нього система DNS — яка обробляє мільярди запитів щодня — не мала б структурованого способу розподілити відповідальність між мільйонами доменів.

Делегування домену — це не просто технічна формальність. Це безпосередньо впливає на:

• Доступність веб-сайту — неправильне делегування призводить до збоїв розв’язання DNS
• Доставляємість електронної пошти — записи MX мають бути досяжні через правильно делеговані сервери імен
• Безпеку — неправильно налаштоване делегування може піддати домени перехопленню або спуфінгу
• Продуктивність — добре структуроване делегування зменшує затримку пошуку DNS

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

Ключові компоненти делегування домену

Розуміння делегування домену вимагає знайомства з його основними будівельними блоками. Кожен компонент відіграє певну роль в ієрархії DNS.

1. Батьківський домен

Батьківський домен — це домен, який знаходиться над делегованим доменом в ієрархії DNS. Він містить NS (Name Server) записи, які спрямовують резолвери до авторитетних серверів імен для дочірнього домену.

Приклад: Якщо ви делегуєте sub.example.com, батьківський домен — це example.com. DNS зона для example.com містить NS записи, які делегують авторитет для sub.example.com іншому набору серверів імен.

На вершині ієрархії знаходяться кореневі сервери імен, які делегують авторитет реєстрам доменів верхнього рівня (TLD) (таким як .com, .net або .org). Ці реєстри TLD, у свою чергу, делегують авторитет серверам імен вашого реєстратора доменів.

2. Дочірній домен

Дочірній домен — це домен або поддомен, який делегується — сутність, що отримує авторитет. У наведеному вище прикладі sub.example.com — це дочірній домен.

Дочірні домени можуть бути:

• Поддоменами (наприклад, api.example.com, mail.example.com, shop.example.com)
• Цілими доменами другого рівня (наприклад, example.com делегований від реєстру .com TLD)

3. NS записи (записи серверів імен)

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

; NS records in the example.com zone delegating sub.example.com
sub.example.com.    IN    NS    ns1.childnameserver.com.
sub.example.com.    IN    NS    ns2.childnameserver.com.

Найкраща практика передбачає наявність щонайменше двох NS записів (первинного та вторинного) для забезпечення надмірності. Якщо один сервер імен стає недоступним, інший продовжує обслуговувати DNS відповіді.

4. Glue записи

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

• Ви хочете делегувати sub.example.com до ns1.sub.example.com
• Але щоб знайти ns1.sub.example.com, резолвер повинен спочатку запитати sub.example.com
• Це створює нескінченний цикл

Glue записи вирішують це, включаючи IP адресу сервера імен безпосередньо в батьківську зону, обходячи циркулярний пошук.

; Glue records in the example.com zone
ns1.sub.example.com.    IN    A    203.0.113.10
ns2.sub.example.com.    IN    A    203.0.113.11

Glue записи обов’язкові, коли сервери імен для дочірнього домену самі є поддоменами цього дочірнього домену. Вони зберігаються на рівні реєстратора домену та обслуговуються реєстром TLD.

5. SOA запис (Start of Authority)

Кожна делегована зона повинна мати SOA запис, який визначає адміністративну інформацію про зону, включаючи:

• Первинний сервер імен
• Адресу електронної пошти відповідальної особи
• Серійний номер (використовується для версіонування передачі зони)
• Значення Refresh, retry, expire та мінімальний TTL

SOA запис сигналізує, що зона правильно налаштована та авторитетна.

Як працює делегування доменів: покроковий DNS-розпорядок

Коли користувач вводить sub.example.com у свій браузер, за лаштунками розгортається складний процес розпорядку. Ось що саме відбувається:

Крок 1: запит рекурсивного розпорядника

Пристрій користувача надсилає DNS-запит до рекурсивного розпорядника — зазвичай керованого його ISP або публічним постачальником DNS, як-от Google (8.8.8.8) або Cloudflare (1.1.1.1). Завдання розпорядника — знайти відповідь, запитуючи DNS-ієрархію.

Крок 2: пошук кореневого сервера імен

Якщо розпорядник не має відповіді в кеші, він запитує один з 13 кластерів кореневих серверів імен. Кореневі сервери не знають IP-адресу sub.example.com, але знають, які сервери імен є авторитетними для TLD .com.

Root Server Response:
.com is handled by:
a.gtld-servers.net.
b.gtld-servers.net.
[...etc]

Крок 3: пошук сервера імен TLD

Розпорядник запитує сервери імен TLD .com. Ці сервери знають, які сервери імен є авторитетними для example.com (як зареєстровано через вашого реєстратора доменів).

TLD Server Response:
example.com is handled by:
ns1.registrar.com.
ns2.registrar.com.

Крок 4: пошук сервера імен батьківського домену

Розпорядник запитує ns1.registrar.com (авторитетний сервер імен для example.com). Цей сервер містить NS-записи для делегування sub.example.com.

Parent Domain Response:
sub.example.com is delegated to:
ns1.childnameserver.com.
ns2.childnameserver.com.

Крок 5: пошук сервера імен дочірнього домену

Розпорядник тепер запитує ns1.childnameserver.com — авторитетний сервер імен для sub.example.com. Цей сервер повертає запитані DNS-записи, такі як A-запис (IP-адреса) або MX-запис (поштовий сервер).

Child Name Server Response:
sub.example.com.    IN    A    198.51.100.42

Крок 6: доставка відповіді

Рекурсивний розпорядник повертає IP-адресу браузеру користувача, який потім встановлює з’єднання з веб-сервером за цією адресою. Весь процес зазвичай завершується за мілісекунди.

Кожен крок у цьому ланцюзі представляє делегування авторитету — від кореня до TLD до реєстратора до серверів імен вашого хостинг-провайдера.

Як делегувати домен або поддомен: практичні кроки

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

Крок 1: визначте цільові сервери імен

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

• Вашим хостинг-провайдером (наприклад, ns1.alexhost.com, ns2.alexhost.com)
• Спеціалізованою службою управління DNS
• Вашою власною самостійно розміщеною DNS-інфраструктурою

Якщо ви керуєте власними серверами і потребуєте повного контролю над вашим DNS-середовищем, VPS Hosting від AlexHost надає root-доступ і надійність мережі, необхідні для роботи авторитетних серверів імен.

Крок 2: додайте NS-записи в батьківську зону

Увійдіть на панель керування вашого реєстратора доменів і перейдіть до розділу управління DNS для батьківського домену. Додайте NS-записи, які вказують на делеговані сервери імен.

Приклад — делегування shop.example.com окремому хостинг-середовищу:

shop.example.com.    3600    IN    NS    ns1.shophosting.com.
shop.example.com.    3600    IN    NS    ns2.shophosting.com.

Важливо: встановіть розумний TTL (Time to Live). TTL 3600 секунд (1 година) є звичайним. Нижчі TTL дозволяють швидше поширювати зміни, але збільшують навантаження на DNS-запити.

Крок 3: додайте записи Glue, якщо необхідно

Якщо сервери імен вашого дочірнього домену є поддоменами самого дочірнього домену, зв’яжіться з вашим реєстратором, щоб додати записи glue. Це робиться на рівні реєстратора, а не у вашому файлі зони DNS.

Крок 4: налаштуйте дочірню зону

На делегованих серверах імен створіть зону DNS для дочірнього домену і додайте всі необхідні записи:

; Zone file for shop.example.com
$ORIGIN shop.example.com.
$TTL 3600

@    IN    SOA    ns1.shophosting.com. admin.example.com. (
                  2024010101 ; Serial
                  3600       ; Refresh
                  900        ; Retry
                  604800     ; Expire
                  300 )      ; Minimum TTL

@    IN    NS     ns1.shophosting.com.
@    IN    NS     ns2.shophosting.com.
@    IN    A      198.51.100.42
www  IN    A      198.51.100.42
@    IN    MX  10 mail.shophosting.com.

Крок 5: перевірте поширення

Зміни DNS можуть поширюватися глобально від кількох хвилин до 48 годин, залежно від значень TTL і поведінки кешування. Використовуйте такі інструменти:

• dig (Linux/macOS): dig NS shop.example.com @8.8.8.8
• nslookup (Windows): nslookup -type=NS shop.example.com
• Онлайн-інструменти: dnschecker.org або whatsmydns.net

Делегування доменів проти DNS Hosting: Розуміння різниці

Ці два поняття тісно пов’язані, але відрізняються:

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

Для бізнесу, який потребує професійної електронної пошти поряд зі своєю веб-присутністю, Email Hosting від AlexHost органічно інтегрується з вашою конфігурацією DNS, забезпечуючи правильне налаштування MX записів та надійну доставку пошти.

Поширені сценарії делегування доменів

Сценарій 1: Перенесення домену до нового хостинг-провайдера

При міграції з одного хоста на інший ви оновлюєте NS записи у вашого реєстратора, щоб вони вказували на name servers нового провайдера. DNS сервери нового провайдера стають авторитетними для вашого домену.

Ключна порада: Налаштуйте всі DNS записи на нових name servers *перед* зміною NS записів у реєстратора. Це мінімізує простій під час переходу.

Сценарій 2: Делегування поддомену до SaaS платформи

Багато SaaS платформ (наприклад, платформи електронної комерції, CDN провайдери) вимагають делегування поддомену їхнім name servers. Наприклад, делегування shop.yourdomain.com до розміщеної платформи електронної комерції, зберігаючи www.yourdomain.com на вашому основному хостингу.

Сценарій 3: Розподіл інфраструктури між кількома провайдерами

Великі організації часто делегують різні поддомени різним провайдерам інфраструктури:

• api.example.com → Хмарний провайдер A
• cdn.example.com → CDN провайдер B
• mail.example.com → Виділена поштова інфраструктура

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

Сценарій 4: Внутрішнє делегування DNS

У корпоративних середовищах внутрішні домени (наприклад, corp.internal) часто делегуються внутрішнім DNS серверам, які не є публічно доступними. Це дозволяє організаціям керувати внутрішніми ресурсами (сайти інтранету, внутрішні API, принтери) через ту саму DNS інфраструктуру, що й їхні публічні домени.

Міркування безпеки при делегуванні доменів

Делегування доменів створює кілька ризиків безпеки, які адміністратори повинні активно пом’якшувати.

DNSSEC (DNS Security Extensions)

DNSSEC додає криптографічні підписи до записів DNS, дозволяючи резолверам перевірити, що відповіді є автентичними та не були змінені. При делегуванні домену DNSSEC вимагає:

1. Підписання дочірньої зони за допомогою Zone Signing Key (ZSK) та Key Signing Key (KSK)
2. Додавання DS (Delegation Signer) записів до батьківської зони
3. Встановлення ланцюга довіри від кореня до вашої зони

DNSSEC настійно рекомендується для будь-якого домену, який обробляє конфіденційні дані або фінансові операції. Поєднайте DNSSEC з SSL Certificate, щоб забезпечити безпеку на рівні DNS та рівні транспорту для вашого домену.

Перехоплення поддомену

Перехоплення поддомену відбувається, коли записи DNS поддомену вказують на ресурс (наприклад, хмарний сервіс, CDN endpoint), який більше не існує, дозволяючи зловмиснику претендувати на цей ресурс і подавати шкідливий вміст під вашим доменом.

Профілактика:

• Регулярно аудитуйте записи DNS та видаляйте застарілі делегування
• Моніторьте невикористані ресурси, пов’язані з вашими поддоменами
• Використовуйте інструменти моніторингу DNS, які сповіщають про несподівані зміни

Безпека облікового запису реєстратора

Оскільки делегування доменів контролюється на рівні реєстратора, ваш обліковий запис реєстратора є цінною мішенню. Захистіть його за допомогою:

• Надійних, унікальних паролів
• Двофакторної аутентифікації (2FA)
• Блокування реєстратора (також називається блокуванням домену або блокуванням передачі), щоб запобігти несанкціонованим передачам

Отруєння кешу DNS

Атаки отруєння кешу намагаються вводити фальшиві записи DNS у кеші резолверів, перенаправляючи користувачів на шкідливі сайти. DNSSEC є основним захистом від цього вектора атаки.

Найкращі практики делегування доменів

Застосування цих найкращих практик забезпечить безпеку, надійність та простоту обслуговування вашої DNS інфраструктури.

✅ Використовуйте кілька серверів імен

Завжди налаштовуйте принаймні два сервери імен для резервування. В ідеалі вони повинні бути географічно розподілені та працювати на окремій мережевій інфраструктурі, щоб усунути єдині точки відмови.

✅ Встановіть відповідні значення TTL

• Високий TTL (86400 секунд / 24 години): Зменшує навантаження на DNS запити та покращує продуктивність. Використовуйте для стабільних записів.
• Низький TTL (300–900 секунд): Дозволяє швидше поширювати зміни. Використовуйте тимчасово перед запланованими міграціями.

✅ Документуйте всі зміни DNS

Ведіть журнал змін для кожної модифікації DNS, включаючи:

• Що було змінено
• Чому це було змінено
• Коли це було змінено
• Хто внесли зміну

Ця документація неоцінна під час реагування на інциденти та аудитів.

✅ Постійно моніторьте здоров’я DNS

Впровадьте моніторинг, який сповіщає вас про:

• Несподівані зміни NS записів
• Збої розпізнавання DNS
• Незвичайні шаблони запитів (потенційні DDoS або розвідка)
• Закінчення терміну дії сертифіката (актуально для DNSSEC та SSL)

✅ Тестуйте перед поширенням

Використовуйте dig або nslookup для прямого запиту до ваших нових серверів імен перед оновленням NS записів у реєстратора. Це підтверджує, що зона правильно налаштована перед тим, як делегування стане активним.

# Query the new name server directly before delegation
dig A sub.example.com @ns1.childnameserver.com

✅ Впровадьте DNSSEC

Увімкніть DNSSEC на всіх публічних доменах, особливо тих, які обробляють аутентифікацію, платежі або конфіденційні дані користувачів.

✅ Періодично аудитуйте делегування

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

Усунення типових проблем делегування доменів

Проблема: DNS не розв’язується після зміни делегування

Причина: Старі значення TTL призводять до збереження кешованих відповідей.

Рішення: Дочекайтеся закінчення попереднього TTL. У майбутньому зменшуйте значення TTL перед внесенням змін.

Проблема: Циклічна залежність / відсутній запис Glue

Причина: Сервери імен є поддоменами делегованого домену, але записи glue не були додані.

Рішення: Зв’яжіться з вашим реєстратором та запросіть записи glue для IP-адрес сервера імен.

Проблема: Часткове розв’язування (працює в деяких місцях, а в інших ні)

Причина: DNS-розповсюдження все ще в процесі, або деякі резолвери кешують старі записи.

Рішення: Дочекайтеся повного розповсюдження (до 48 годин). Використовуйте dnschecker.org для моніторингу глобального статусу розповсюдження.

Проблема: Електронна пошта перестає працювати після делегування

Причина: MX-записи не налаштовані в новій зоні, або нові сервери імен ще не є авторитетними.

Рішення: Перевірте наявність MX-записів у дочірній зоні. Підтвердіть завершення делегування NS перед вимиканням старого DNS.

Проблема: Помилки валідації DNSSEC

Причина: DS-записи в батьківській зоні не відповідають DNSKEY-записам у дочірній зоні, або ключі були ротовані без оновлення батьківської зони.

Рішення: Повторно створіть та опублікуйте DS-записи в батьківській зоні. Дотримуйтеся належних процедур ротації ключів.

Висновок

Делегування доменів є одним із фундаментальних механізмів, які роблять систему DNS Інтернету масштабованою, розподіленою та керованою. Розуміючи, як влада передається від кореневих серверів через реєстри TLD, реєстратори та хостинг-провайдерів до ваших конкретних серверів імен, ви отримуєте знання, необхідні для проектування надійної, безпечної та продуктивної інфраструктури доменів.

Незалежно від того, делегуєте ви один піддомен платформі SaaS, переносите весь домен до нового хостинг-провайдера чи будуєте складну архітектуру DNS з кількома провайдерами, принципи залишаються послідовними: правильно налаштуйте записи NS, додайте записи glue де потрібно, перевірте конфігурацію вашої зони перед запуском та постійно моніторте.

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

*Маєте запитання щодо налаштування делегування DNS для вашого домену, розміщеного на AlexHost? Зв’яжіться з нашою командою підтримки — ми тут, щоб допомогти вам зробити це правильно.*