Після реєстрації домену та купівлі хостингу потрібно «зв'язати» їх. Є два способи: змінити NS-сервери (рекомендується) або додати A-запис.

Спосіб 1: Зміна NS-серверів (рекомендований)

При цьому способі весь DNS домену керується з ZevsHost. Підходить, коли хочете керувати всіма DNS-записами в одному місці.

Кроки:

Увійдіть у панель реєстратора домену
Знайдіть розділ «NS-сервери» або «Nameservers»
Замініть поточні NS на сервери ZevsHost:
```
ns1.zevshost.net
ns2.zevshost.net
```
Збережіть зміни
У cPanel ZevsHost додайте домен: cPanel → Addon Domains

Спосіб 2: Зміна A-запису

Використовуйте цей спосіб, якщо хочете залишити DNS у реєстратора (наприклад, там налаштована пошта Google Workspace).

Дізнайтеся IP-адресу вашого хостингу ZevsHost — вона вказана в листі про реєстрацію або в cPanel → Загальна інформація
У DNS-панелі реєстратора знайдіть A-запис для @
Змініть IP на IP вашого хостингу ZevsHost

Також додайте/змініть A-запис для www:

@      IN    A    YOUR.HOSTING.IP
www    IN    A    YOUR.HOSTING.IP

Терміни оновлення

Дія	Мінімум	Максимум
Зміна NS-серверів	30 хв	48 годин
Зміна A-запису	5 хв	24 години (залежить від TTL)

💡 Перевірка: Використовуйте whatsmydns.net для моніторингу поширення DNS по всьому світу. Не потрібно чекати 48 годин наосліп — можна відстежувати прогрес.

Перевірка підключення

# Перевірити A-запис домену
nslookup example.com

# Перевірити NS-сервери
nslookup -type=NS example.com

# Пінг домену
ping example.com

⚠️ Поширена помилка: Домен доданий у cPanel, але NS у реєстратора ще старі. Або навпаки — NS оновлені, але домен не доданий у cPanel. Потрібно зробити ОБИДВА кроки.

Часті помилки під час прив'язки домену

Симптом	Причина	Рішення
Браузер показує сторінку-заглушку хостинг-провайдера замість сайту	Домен прив'язано по NS, але не додано як Addon Domain у cPanel — DNS вказує правильно, а вебсервер не знає про цей домен	Додати домен у cPanel → Addon Domains і дочекатися перегенерації конфігурації вебсервера
ERR_TOO_MANY_REDIRECTS під час відкриття сайту	A-запис domain і www ведуть на хостинг, але там же увімкнено форс-редирект на інший протокол/домен, який конфліктує з налаштуваннями CMS	Звірити налаштування force-HTTPS у cPanel і в CMS — увімкненим має бути лише один рівень редиректу
nslookup показує стару IP через 3 дні після зміни A-запису	TTL запису було виставлено на 86400 секунд (24 години) до зміни, а резолвер клієнта закешував відповідь до завершення TTL	Зачекати повного завершення старого TTL або скористатися очищенням DNS-кешу на боці клієнта для діагностики
Пошта перестала надходити одразу після зміни NS	MX-записи не було перенесено на новий DNS-провайдер разом зі зміною NS-серверів	Скопіювати MX, SPF, DKIM записи в панель керування DNS ДО зміни NS, а не після

TTL і чому прив'язка «не працює одразу»

TTL (Time To Live) — це час у секундах, протягом якого резолвер має право закешувати відповідь. Типові значення: 300 (5 хвилин) для записів, які скоро зміняться, і 3600–86400 для стабільних записів. Резолвер провайдера користувача може ігнорувати короткий TTL і тримати кеш довше — це не порушення стандарту, а особливість частини публічних DNS-серверів, які самі встановлюють мінімальний TTL кешування.

# Дізнатися TTL поточного A-запису
dig example.com A

;; ANSWER SECTION:
;example.com.  300  IN  A  192.0.2.10

Коли спосіб з A-записом не підходить

Потрібно керувати безліччю піддоменів і записів централізовано — тримати весь DNS у реєстратора незручно за частих змін
Планується підключення CDN або захисту від DDoS через зміну NS (наприклад, Cloudflare) — поєднувати це з ручними A-записами у реєстратора надлишково
У домену вже налаштовано DNSSEC у DNS-провайдера, відмінного від хостингу — зміна лише A-запису залишить підпис зони без змін, що безпечніше за зміну NS
Потрібне балансування навантаження між кількома IP через пріоритети і ваги записів — це робиться через DNS-панель провайдера, а не через один статичний A-запис

Якщо потрібно не просто змінити A-запис, а повністю змінити NS-сервери — покрокова інструкція в статті як змінити NS-сервери домену.

Перевірка після прив'язки — розширена діагностика

# Перевірити, що заголовки відповіді надходять саме з потрібного сервера
curl -I http://example.com

# Перевірити SSL-сертифікат одразу після прив'язки
curl -vI https://example.com 2>&1 | grep -i "subject:"

# Переконатися, що www і голий домен ведуть на ту саму IP
dig example.com +short
dig www.example.com +short

Якщо curl -I повертає заголовок Server від іншого провайдера, а не від ZevsHost — отже, поширення DNS ще не завершилося на використовуваному вами резолвері, навіть якщо в інших резолверів запис уже оновився.