Делегування доменів Пояснено: Повний посібник з 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 до іншого набору серверів імен.

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

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

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

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

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

3. Записи NS (Name Server Records)

Записи 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 Records

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

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

Glue Records вирішують це, включаючи 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 Records є обов’язковими, коли сервери імен для дочірнього домену самі є піддоменами цього дочірнього домену. Вони зберігаються на рівні реєстратора доменів і надаються реєстром TLD.

5. SOA Record (Start of Authority)

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

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

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

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

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

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

Пристрій користувача надсилає DNS-запит до рекурсивного резолвера — зазвичай керованого його провайдером інтернету або публічним постачальником 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

Резолвер запитує сервери імен .com TLD. Ці сервери знають, які сервери імен є авторитетними для 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 Records, якщо необхідно

Якщо сервери імен вашого дочірнього домену самі є піддоменами дочірнього домену, зв’яжіться з вашим реєстратором для додавання glue records. Це робиться на рівні реєстратора, а не у вашому файлі зони 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-хостингу: розуміння різниці

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

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

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

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

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

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

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

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

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

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

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

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

Ця архітектура вимагає ретельного управління DNS, але дозволяє вибирати найкращу інфраструктуру. Dedicated Server може служити надійною основою для вашої первинної зони 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), який більше не існує, дозволяючи зловмиснику претендувати на цей ресурс і надавати шкідливий вміст під вашим доменом.

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

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

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

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

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

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

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

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

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

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

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

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

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

✅ Документуйте вс